esa

I think my usecase of curl is entirely covered by hyper (I just use it for http/s with a small handful of flags); but I also have absolutely no idea what goes on inside curl or how my distro chooses to build it.

Rebuilding curl to use Rust here and there (it still supports rustls and quiche) seems like an interesting undertaking, but yeah, I suspect most curl users don’t build it themselves and have no idea what experimental features it could be built with. Guessing the curl survey has data for that.

Stenberg seems like a cool dude and this seems like an amicable split.

Idunno, that might be approaching “one day of patchy electricity can change how you view computers vs mechanical typewriters”. Here people would likely use their mobile internet, especially if the company is paying their phone bill.

I’ve been using Fantasque sans mono for a bunch of years now.

I generally agree, but

1. People who haven’t used a package before likely aren’t interested in release candidates.
2. Axum is one of the few pretty well-known Rust libraries. I’m willing to give that a pass on describing what it is for an RC, much like I’d do the same for FastAPI in a Python community. (But a little default blurb about what they are would be nice anyway to people who are new to the language and/or ecosystem.)

I think I wouldn’t find it particularly useful, as I’m used to the quasi-programming I can do in a terminal. The shell commands take some time & effort to learn, but once you’re over that hump, being able to extract and compose information is really good. The primary shell tools I’d miss in a gui are |, jq, awk, sed and grep/rg, as well as for, if, while, variables, and having everything in one lightweight window.

Ultimately clients pay good money for me to look after their systems, systemd or not, so I probably shouldn’t grumble, but I miss the days when Linux was a clean and elegant system, without this multi-tentacled thing sitting on top of it.

I also have a sysadmin/devops/sre type career, and my impression is rather the opposite: With systemd Linux became a lot cleaner and predictable, compared to the mess of shell scripts we had before. There’s never been anything clean or well-architected about shell scripts, they’ve always been a messy collection of not-quite-the-same languages that have all safeguards turned off by default, and it’s up to the programmer to turn them on and hope they actually work. Good for one-shots and exploration in the terminal, though.

I also don’t miss logrotate or finding out that some app places its logs somewhere mystical. Being able to read app logs just by knowing the service name is wonderful, as are the timestamp and boot arguments.

systemd didn’t appear as just one guy’s brain child, nor could it rise to the dominance it has if the way it works was as controversial or bad as it is in your opinion.

I haven’t been on-call for the past few years, but my impression is that there have been fewer and fewer on-call events over my career. That’s also largely on app developers and a shift to Kubernetes, but it’s a generally pleasant change. There’s nothing I hate more than being woken up.

I also find that calling systemd “SystemD” is a tell that someone is unfamiliar with or has a conspiratorial relationship to it. It’s named “systemd”, all lowercase (but I’m likely to capitalize it on sentence starts like a normal word). Using an ungrammatical uppercase D at the end of the word, that isn’t even something the creators claim is correct, is … a choice.

(And it’s a choice that reminds me of e.g. how rabid anti-cyclists in Norwegian can’t even spell “cyclist” correctly, but instead consistently use “bicycleist”.)

The name is constructed from two parts:

1. ls: list
2. usb: usb

It lists usb devices that your machine (/kernel) knows has been connected; they may not necessarily be usable.

E.g. I have some sound output device connected via USB to one machine. On most of my machines I’ve switched from pulseaudio to pipewire¹, and I figured I’d bring that machine closer to the others so there’s less variance. Unfortunately the sound output device didn’t want to work with pipewire. The problem manifested as no sound and pipewire not listing the device. lsusb helped me know that the machine at the very least recognized the device, but wasn’t currently able to use it. (It did actually also show up as an error in dmesg -H, but reinstating pulseaudio let the device work again as normally. So now I just have to live with a situation where some machines use pipewire because _bluetooth and others use pulseaudio because … usb?¹)

¹ There’s a memory of ALSA vs OSS I didn’t want to be reminded of

In addition to the other comment about the exit code, you might be interested in the exitcode crate, which offers up a BSD convention for those exit codes.

They are, essentially, just numbers on unixes and don’t really have as much standardization as e.g. HTTP codes afaik. Various programs may have their own local conventions as to what an exit code means.