However, I do love me some text including fairly unstructured output (which I am adept at structuring). Once one masters regular expressions, the flexibility is really unmatched in my experience.

I'm also adept at structuring unstructured output and regular expressions. However, both of those are a waste of my time most of the time, because the only reason why I have to do things is that the structure existed but was discarded and now I have to pointlessly recreate it.

A program had a structured view of the situation. A specific thing happened, on this date, to this path, for this client. This then gets written into a string into a log or stdout, and then I write a clever regex to put things back into separate fields. This is really, really stupid.

You know what's better? Not doing that. Having something like DBus where everything is in its separate fields to start with, or journald where you can log an IP address in a specific field, so then the admin can trivially match source_ip and destination_ip as necessary, without having to waste time on regex magic.

Now, the ability to parse stuff when needed anyway? Sure, that's cool. But it should be a very, very rare exception because the default shouldn't be to heap up pointless work on the admin. You don't write regexes to extract the source field from packets in wireshark. Wireshark already gives you all the fields parsed up, and then you only need to use a regex rarely, against a single field. That's how the entire system should be.

ALSA was complicated. ALSA is a kernel driver + userspace library. Kernel driver just talks to the hardware, and you'll have mixing only if the hardware supports it.

Trouble was that hardware mixing quickly went out of favor. ALSA implemented dmix, which turns out to be library based so it doesn't work for anything that's not talking to ALSA specifically, so old apps are out of luck. There were also troubles with old school apps trying to open /dev/dsp directly and blocking out everything else, ALSA configuration being inscrutable, and apps using /dev/dsp, ALSA, jack, artsd and esd all existing simultaneously. That era was just a terrible mess if you had anything other than say a 100% KDE or 100% Gnome system, and even then it was tricky. Sound just broke seemingly at random depending on what managed to grab the sound card.

Pulseaudio introduced sanity by gobbling everything up and supporting all that junk at once.

Well, we disagree, there. I see it as having gone through so many iterations and having so many players involved now it's lost much of it's ideological purity and, with that, some of it's power, reliability, and usefulness due to the resulting loss of cohesion. It's backsliding into trying to become Windows NT, completely with 'svchost.exe'.

Ideological purity is to me a flaw, especially if you mean holding on to old things invented in the 60s. Cohesiveness is good, paralysis is not.

Also, as a sysadmin my job is to solve problems, not to bask in ideological purity. So, eg, I really like that systemd makes it really easy to ask for the logs of 3 particular services last weekend at 3 AM, and have them properly interleaved with one command. On SysV systems, any time spent on figuring out where it logs, if the log was rotated, and whether it's in .1 or .5.gz, and assembling a combined report is wasted time.

I think shell scripts are awesome and they do tons of real work for my clients and my own company's infrastructure. They are indispensable to me. Why be annoyed that someone else is getting some mileage out of a technology you don't happen to use?

You misunderstand. I don't mean shell scripts, I mean bash. Bash is crap. I want something more like PowerShell in spirit, only that's not quite it either. I want a shell where: every command is 100% precise. All arguments are always exact. There's never confusion with spaces, quotes, newlines, or anything else. IFS doesn't exist. You never need to work around command line lengths by hand. "Do this to $list" always works, whether 10 or a million files. It should offer excellent process management, along the lines of "Launch up to 10 simultaneous instances of (command) on (list of files), call (this) on command fail and (that) on success" as a natively supported primitive.

All commands should output something Powershell-ish. Not plain text, but flexible objects with datatypes. I don't want to parse stuff with AWK, I just want to ask for $File.CreationDate.Year. The format should be perfectly delimited, no splitting by spaces or by ":", and allow adding additional data without breaking every script. Every datatype should be transmitted perfectly. A date is always the exact date the software knows of internally, not something truncated to seconds to look pretty on the console.

The Unix text stuff was a good start. Time to do better.

I teach several sysadmin classes, too. What I notice is that once novice folks learn shell script, they become disenchanted with unit files. However, beforehand, they are usually indifferent or show some bias toward using units. Also keep in mind nobody got rid of them, they just forced some major distros to do it. There are still plenty that didn't, including FreeBSD which I saw grow in popularity and catch a lot of disenchanted former Linux users.

Funny, I'm the complete opposite. I wrangled with SysV scripts a bunch. They're awful. Every distro has its own standards and tooling. Upgrades sometimes force you to look at a 3-way diff of some 150 line script. Some do weird and fishy things. Best case it's 50 lines of boilerplate and 3 unique lines.

Unit files do it right. Code isn't ever placed in /etc. The configuration format is maximally simple and boring. I can roll up to a systemd system and quickly see what the admin changed, because all the changes are in /etc, and the only thing to be found is the changes. Upgrades go much smoother. The boring boilerplate with start-stop-daemon doesn't exist. PID files don't exist. Services are tracked perfectly. Every possible knob can be applied to every possible unit without hacking up a shell script. Logging is done reliably for every single service.

I've grown quite disappointed with the state of Linux over the years.

Back when I started, I had DOS and Windows 3.1/9x. Linux was troublesome (remember writing modelines for X11?), but also like magic in comparison. You want a very minimalist setup? Can do that. Want ridiculously overdone themes with fake transparency on hardware that can barely bear the load? Sure, just install Enlightenment. Want to write complex scripts? Sure, bash is far superior to crappy .bat files, and then there's Perl. And you can even email the author of almost anything that runs on the system and actually talk to them. Freaking magic, man.

The difference I suspect is that I never got into the "unix philosophy" worship. I just liked that it was more functional than DOS/Windows. I see no reason to stop at it, and if somebody comes up with something better, then good riddance. Unfortunately Linux seems to have ended its wildly experimental phase and now gotten annoyingly conservative. How are we still using bash in 2024? Annoys the heck out of me. At least we got rid of SysV init scripts, that's a start.

Powershell has its weird quirks, but after writing a lot of bash, I can't stand it. Any time I write more than 5 lines of shell script I quickly stop and switch to Perl if for personal use, or Python for longer term use.

I don't get how after so long, Linux is still cursed with such a horrible scripting language.

Powershell once you get used to it is a lot more pleasant to work in than bash, and I say that as somebody who only uses Windows when absolutely necessary.

Funny, I like Fedora for pretty much the opposite reasons -- adoption of cool new features like systemd, and nice enterprise features like SELinux that are hard to find with good support almost anywhere else.

Pulseaudio was a very nice improvement over the horrors of getting ALSA configured properly. These days it's replaced with pipewire, by the way.

I don't really care about the history. Today, marriage is a civil, government-enforced contract. You can get all annoyed about that, but I don't care and celebrate this form of "appropriation".

The sooner we do away with this religious malarkey, the better.

I'm not sure who thought this would be a good idea.

Hydrogen, to the extent it makes sense at all seems a much better fit for trucks. Trucks have more room but weight requirements (and hydrogen is light but takes a lot of space), and have far more predictable routes like moving in between warehouses making it much easier to build a few hydrogen stations in the right places.

The problem I believe is that hydrogen is so far very expensive, and so even though that trucks make a good fit as far as infrastructure goes, the price probably discourages commercial operations.

So it sucks price-wise, and it sucks infrastructure-wise, and it's terrible if you run out of hydrogen. Very little reason to buy one of those only than risking a whole lot of money to be an early adopter.

There's no point in supporting Qt5. It's dead, and on maintenance only for commercial users for just another year.

Marriage is unrelated to any ceremonies. It's a contract with benefits regarding taxes, immigration, property, healthcare and other matters.

Whatever ceremonies you perform in any place to commemorate the occasion are legally meaningless.

Why? Search algorithms are enormously efficient and easily parallelizable, and what you can describe can be divided into stages and pipelined as well.

You also don't know all that many people, maybe a hundred, maybe a thousand tops. Even sequentially going through a list of all the external characteristics you know about a thousand people is sheer triviality for a modern computer. The dataset would be small because you're not trawling through petabytes of data but looking through already digested and organized information.

Everything works better when specifically designed for the application. A CPU can render in software, but a GPU does it better. A GPU may mine crypto well, but an ASIC designed for crypto and nothing else will do a much better job.

AI turns out to have some quite specific needs that GPUs don't ideally satisfy: https://www.youtube.com/watch?...

The Internet is less of a wild west than it used to be, but it's still pretty wild.

There's plenty big countries like Russia where the authorities won't care at all about any of your local rules. That may not be fun, but it's a fact. If somebody from Russia runs a scan on you, and then distributes information in Russian forums, there's pretty much nothing you can do about that.

Even less now with the Ukraine situation, where Russia is heavily sanctioned and even less inclined to be friendly to other countries.

You can't.

Even if you could obtain some compliance within a given country, the Internet is international and people from various less liked jurisdictions couldn't care less about what rules you might have.

Once the data is out there, it's out there. You can't ever have any confidence that nobody will notice that a given port is open or a given service is buggy, and that this fact won't spread through various parties, including things like underground forums most people don't know even exist.