If I’m gonna buy an authentic baguette, the baker could at least have the decency to wear a beret and a twirly moustache, regardless of their ethnicity.
If I’m gonna buy an authentic baguette, the baker could at least have the decency to wear a beret and a twirly moustache, regardless of their ethnicity.


Like I said: unless your ISP sucks. I don’t see the issue with dual stack and I don’t know why you’re bringing other transition mechanisms into this. Obviously they kinda suck. Dual stack really doesn’t have much of a downside or a performance hit unless your clients or DNS are doing something stupid. In which case you can still choose to configure a client to use one over the other. Many ISPs, especially outside the US, don’t have enough IPv4 address space and have to use CGNAT, in which case you’re much better off with a dual stack setup and a DNS config that prefers AAAA records, imho. IPv4 only leaves you with NAT, which sucks and IPv6 only isn’t feasible currently.


Which of the poor innocent people that meany pants Drew Devault insulted, do you take issue with? Lunduke? I’ve read this article before and while I don’t remember all of the callouts, I can’t recall seeing anyone I would particularly want to defend from insults.


Dual stack setups are not an issue unless your router doesn’t support it or your ISP sucks.


I didn’t know that Canada was basically Mordor…
The opinions of a christian youth pastor who loves claude code.
There are some good points in it, though I wouldn’t really consider go dependencies all that decentralized in practice and I don’t understand how checksum db will protect against supply chain attacks with stolen credentials, but I admit I haven’t looked into the details.
But why hasn’t JavaScript established a defacto stdlib to replace ask the left pads and is even type packages?
I’m guessing things were working out pretty alright, even with the insane amount of dependencies per project. The awareness and the increasing frequency of supply chain attacks is relatively recent for npm. But who knows, maybe the tech giants in control of the web standards are happy to keep using their own vendored registries.
Npm probably has the biggest attack surface and many of the libraries hosted there are in extremely widespread use. They’ve taken some steps to mitigate these supply chain attacks, but as we’ve seen with more recent examples, it’s unrealistic to think they can be prevented completely. Most of these attacks use stolen developer credentials, which invalidates almost all potential security measures on the registry side and the best you can hope for is catching a malicious package quickly. To be clear: I think the JS ecosystem is uniquely positioned to be the prime target of supply chain attacks and while that doesn’t excuse the slow implementation of security measures from the npm team, the people arguing that other package managers and registries aren’t vulnerable to this have to be huffing fumes.
Npm has gotten a few config options that prevent this behaviour. We can only hope that they will become the default eventually.
It does. Enforcing a minimum package age can be useful for some applications, but the average user isn’t one of them.
The good news is that there already is a gold standard for supply chain security: the Go programming language.
Lmfao


I was actually wondering if this was supposed to be about a specific problem someone has with rust (not like I haven’t gotten stuck on some weird corner with rust before), but looking at the meme, that seemed unlikely to me. Thanks for the context.


I get that it’s supposed to be a meme, but aside from the first one these aren’t even rust stereotypes. Is this a meme specifically for people who haven’t used rust, know nothing about rust but have maybe heard that it’s a programming language?


I see. It uses AI generated code, I just checked.


Is there a version of n8n without AI generated code?
Yes, the issue is the wording. The american version shrinks a bottle of certain volume, the metric version shrinks the unit of measurement.


No, though parts of systemd have a scope creep issue, that’s not what I’m describing. I’m talking about Poettering deciding to create a service layer for Linux after stealing some ideas from MacOS. Reducing that to “scope creep” is misleading at best and feeds into the “systemd is a monolithic application” concern trolling at worst.


Don’t like systemd-resolve? Fine. I get that plenty of implementation details are incomplete, suck or have caused friction with other software. On the other hand it’s a really useful tool for dynamic split dns handling, which is why I like using it. You can disable it, I’ve done so on some workstations and servers, because of poor choices in internal domain names leading to mDNS issues, knock yourself out.
Don’t think it should be part of an init system? It really isn’t. I wouldn’t call systemd just an init system to begin with, though that was the initial project goal. Most of its parts are reasonably well separated or at least highly configurable for a service layer. I genuinely think it’s completely insane to have DNS resolution in libc, but people have gotten used to that. Systemd-resolved is completely inoffensive in comparison imho.
Don’t like systemd as a whole? Use a distro without it. It really is that simple. Everything has been discussed - at length. Wars have been fought. At this point, change will only come if the complainers actually sit down, shut up and do some work towards their goals.
Sorry this turned into such a rant, most of this isn’t even directed at you, this situation just annoys me. Especially this poor guy getting death threats on GitHub because someone riled up all the asshats in the community who have no idea how any of this works. Maybe they should focus their energy on the political forces pushing the California legislation that started this whole mess? I’ve been tired of this stupid debate for years now. I feel like it’s mostly carried by people who have no idea what they are talking about these days.
Skip to 14:30 or something. It’s a very disjointed talk.