It’s not a knockoff. They have a friendly relationship with the original creator of sudo. And their work helps uncover bugs of the original sudo so they send fixes upstream.
Friendly relationship or not, the end user experience is that something that was working, no longer is, because it's not feature compatible. This is despite it being used to replace it under the same name. If it had been `runas` or anything else it'd be fine.
There's a strong principle in upstream Linux kernel about "You don't break userspace"[1], that I really wish more folks would get into their heads, but most especially a variant "You don't subtly break userspace".
If you're going to replace an existing binary, under the same name, you need to be like-for-like in commands, even if your guts are completely different. Very few people give a damn about how it's actually implemented, just does it do what they need it to do.
If you want to do things differently, do it under a different name and have it be an explicit break for an end user by not shipping with the original and let people choose to install it if they really don't want the new thing. Breaking things subtly is completely unacceptable.
Yeah "You don't break userspace" refers to the kernel <-> userspace interface (libc) because that's the smallest common denominator and the reason why stuff like snap works.
Besides that userspace has been incompatible between distros for at least 30 years because everyone has that one special patch the library needs on their distro that isn't accepted upstream and breaks things beyond repair.
This was already the case in the 1990s when Applixware shipped 30 different versions of their software on one CD-Rom because it should run on different distros and their versions.
And back then there weren't that many, mostly Red Hat, SuSE and Debian.
If you forget to do it in C, everything still looks superficially right.
If you forget to do it in rust (or zig, or typescript, or any of the hundreds of languages with option types), your code doesn't compile.
Nothing precludes "simply do not fall off" when working off heights, either, but there's a reason safety harnesses are mandatory when working at heights in most of the developed world.
Imagine every Rust program just calling unwrap on this result, and therefore the Rust library deciding to just never return an error. That’s analogous to what happened here.
If your goal is to convince people that you're right, describing things as "time wasted on navel-gazing" is not the type of thing that will win people over. It comes across as arrogant and entitled, as if the world would be better if everyone would just recognize you're smarter and therefore should do whatever you want.
If you're just pissed and trying to blow off steam, maybe this choice of words will help a bit, but because of the issues described above, it also might just cause a bunch of people to react negatively towards you and therefore make your mood worse.
If you're just commenting here as something to reference in the future for when you expect to say "I told you so!" to everyone, I guess this is a reasonable way of doing it. It still doesn't really seem like there's much need for phrasing it like that though; people still might look back and think that you're right but still sound arrogant and entitled.
I can’t stress this enough: there are—rightfully—a whole bunch of people that simply do not want to work on C codebases, because in the typical case, working wIth C sucks. Your outbursts are never going to change this, no matter how petulant or vitriolic. Amazing how a group of people has made “[aversion to{ languages with far fewer footguns” into some sort of culture war issue. Sorry that the industry is forcing you to read a book or whatever.
I think the difference people were warned about is that the server can infer the client, so there would be a difference between reading it in your regular browser and curling. As the other commenter says, I'm not sure how the server would be able to tell what curl does with the response.
Normally not a fan of appimages, but this group focuses on making higher quality versions that make very few assumptions about the host system and work almost anywhere. While also prioritizing speed, small sizes, and up-to-date dependencies.
I run WireGuard VPN on port 443 UDP. Many times I can connect to that from various public WiFi networks like coffee shops and public libraries. And then I ssh into my machines at home over my self-hosted VPN.
I’ve been hoping that HTTP3 adoption would make 443 UDP accessible from even more places. But maybe they already do the kind of thing you said for that too, looking at the traffic flow to determine that it is not HTTPS.
Weirdly sometimes there are WiFi networks where I am not able to connect to my WireGuard VPN on 443 UDP, but I can connect to servers over ssh on standard port 22 TCP. Perhaps they sometimes block all UDP traffic because they don’t want people to use BitTorrent etc, but one would think that with all the online meeting platforms that do video streaming there would be a lot of problems for people if all UDP traffic was blanket blocked.
I might eventually try out AmneziaWG instead of vanilla WireGuard, but at the moment I am fine not being able to Connect to my VPN sometimes. I only use it to connect to my other machines anyway, not as a VPN tunnel for my web browsing etc.
it's possible commercial routers such as the ones utilized by restaurants allow wireguard through these days? wireguard makes no effort to be stealthy when emitting.
some VPN apps bypass wireguard blocks automatically by using https tunnels and whatnot.
Does mosh help with it? Seems to be based on udp, and it looks good. I am not entirely sure if it helps the issue that you are talking about so hoping for someone more experienced to chime in
I can use Ghostty and use the same featureful terminal on Linux and macOS.
I also hate configuring Konsole, most KDE apps for that matter. Being able to have a plaintext configuration file I can keep in my dotfiles is way simpler.
> The design of the TPM makes much more sense for a closed-source operating system
I don't think that's the case. The great thing about TPMs is that they measure what's on your system. As long as you modify things properly, your changes get measured and stored in the TPM.
Secure Boot is the more closed-sourced way. By default it relies on Microsoft keys unless you enroll your own and sign your stuff.
Secure Boot also works with Linux, no self-enrolled keys required for poular distros.
TPM measured boot is supported, but it’s a bit fussy to set up using traditional Linux boot, because the firmware, kernel, kernel command line, initrd, grub executable, grub environment, and the complete sequence of grub commands all need to be measured, and some of these things can change for valid reasons other than the obvious case of system updates or reconfiguration (e.g., the Red Hat grub-boot-success mechanism which sets a grub environment variable 2 minutes after a successful boot, so a reboot during or shortly after boot is enough to make measurements taken with this variable set fail).
Also, as in any auto-unlock scenario, the boot process all the way to the login prompt needs to be secured against any interruption that may enable the user to get unauthenticated system access after the disk is unlocked.
GrapheneOS has repeatedly turned down this idea because it gives a wider area of attack (signed in vs in a locked state) and would be easily detectable.
reply