It's going to use a RTG.

One of the high technology parts of the French TGV trains is that they are capable of running on old track at non-TGV speeds. BrightLine really should do the same, the train slows down a lot, but does continue on to Union Station after stopping at Rancho Cucamunga. There should not be a need to change trains.

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.

The machine I had was a HeathKit H19. This had it's own OS called HDOS. Not sure what the quality of that was or how it compared to CP/M. However the hardware also had ROM mapped to the first 2K or so (to run the program controlling the front panel display) which made it incompatible with CP/M. I somewhat remember it was already clear that all the good software was only for CP/M and I had the wrong machine and HeathKit screwed up. Anybody else remember these, have any comments on them? It does sound like creating HDOS was not a trivial amout of work, was anything interesting lost with it?

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

No, ignoring the XY position of windows is a specific design decision by Wayland. They did it on purpose because they think it is a security problem. The idea that the desktop could just look at the requested positions and only ignore bad ones apparently is foreign to them. Instead they made it impossible for an application to store window positions.
They also purposely designed it so it is impossible to work with overlapping windows, by requiring that clicking in a window always raises it,a design that was removed from X10 to make x11. Their arrogance shows no bounds.

Have another AI that examines everything that the main AI attempts to write. All it has to do is identify that an output is objectionable. If true then it is never printed. The main AI can generate a new piece of text, repeating until it generates something non-objectionable. Or it can print "congatulations you got me to say something objectionable".

This is all irrelevant to whether censoring is good/bad, just that technologically it seems possible to fix any and all such bugs.

WTF? The left was hard against invading Iraq long before it happened. I know because I disagreed with them, Saddam seemed very dangerous and the left naive. They may well have been wrong, but they were against it.