Some of these are not obscure at all, but absolutely standard. Xterm was the shell, I’m not sure there were even alternatives in early X. Xbiff+Xload+Xclock used to be on everybody’s desktop. XV was the main image viewer on X for a long time.
Anybody remember xvacuum? I guess it’s truly obscure since it didn’t make the list. One of my favorite tricks to play on other people in the lab, before X security was a thing, was to run xvacuum on other people’s displays ... it slowly sucks everything on the screen into the mouse cursor.
If the page maintainer is reading, Xsnow has a calculator in the screenshot covering the snow. This one is a bit obscure, but I loved xsnow, so I think it deserves a calculator-less view! :)
For clarity, Lennart Poettering is an extremely prolific guy that people somehow love to hate. At the end of the day, his critics either use his software begrudgingly, or use somebody else's to their own detriment, just to spite him.
I take some time every year to thank Lennart for systemd and PulseAudio; I remember when the grass was parched brown on my side, green has been a welcome change!
Avahi is a fun whack-a-mole game where your computer hides the network connection. You win the game by remembering to kill processes and setting up stuff manually, like most games produced by LP studios.
edit:
Other popular games include:
SystemD: hack your way through a blob of intractability. Try it on Nightmare mode, where you're only given access to a empty bootscreen, for a real challenge.
Pulseaudio: Experience the sound of no hands clapping, in a forest where trees are falling with no one there to witness it. Also, the forest is on fire!
Lennart Poettering is a dev who has contributed massive amounts of code most people in this thread use every hour of every day. Code which, for most people, does work.
It's not like free software has a shortage of talented contributors that people hate for a variety of reasons. At some point you have to actually point out the issues productively, rather than the boring character assassination, or just randomly saying "the software's broken it sucks!" like this is the Best Buy tech support line.
I mean, seriously, if you're smart enough to "kill processes and [set] up stuff manually", you're smart enough to disable/remove software you don't like all on your own like a grown adult.
Working is not the problematic part. There are two interrelated problems: how much complexity is introduced, and how to proceed when something is not working, or is flaky.
You, me, and our fellow posters know very well that Lennart's solutions are complex - in fact, more complex than the problem domain. Accordingly, the ability to narrow down, fix, or work around problems suffers. Systemd and PulseAudio aren't UNIX applications [1]; they are entirely new, rather opaque, sub-systems unto themselves. Thus they require separate knowledge, separate intuition, and separate skills.
All so I can seamlessly play music on TWO bluetooth speakers while also browsing logs without learning regex.
>Lennart Poettering is a dev who has contributed MASSIVE AMOUNTS OF CODE
Massive amounts of code is a clear and present problem. Why is the solution more complex than the problem domain? Why is the success being measured by magnitude of effort, rather than by barriers removed, and standards adhered to?
--
[1] what makes an UNIX application? small POSIX applications tied together with shell scripts, communicating via pipes, exposing services as files, following the `Worse is better' and `Do one thing, and do it well' principles.
> Why is the solution more complex than the problem domain?
So, where's your solution? If it's so simple, where is your contribution?
The fact is, he did it. You haven't. I can't even begin to imagine how much crap Lennart gets everyday by people who think they know everything and yet never actually seem to write any code.
Have some respect for the guy even if you disagree with the way he works, because you know.. his code is being used.
I mean, if anything your list proves my point. They're not used at all. Also, I was asking parent for his implementation - I'm assuming he hasn't written any actual code though.
This is not a valid argument, invalidating discussion of merit of thing based on not having personally created incarnation of said thing would remove 99% of debate of FOSS to no ones benefit.
My only problem with Jack is that Firefox (and Chrome too, afaik) absolutely insists on using Pulse, so you have to make both play nice if you want to use Youtube while working on music (which is actually pretty common). This can be a bit of a pain (funny things happen after suspend/resume). Still it's so useful for music/sound production, I put up with it :-)
Jack does not overlap with PulseAudio. Pipewire does, but it came later and has the explicit purpose of unifying Jack and PulseAudio.
Upstart is decidedly inferior to systemd; the event-based architecture is much harder to understand and apply than the target/dependency architecture of systemd. And systemd is in use in distros ranging from embedded (LibreELEC) to enterprise server, it must be doing _something_ right...
Regarding the event driven architecture: it is far easier to understand than systemd's dependency system. But it is indeed more difficult to apply, particularly because it is a departure from how most systems work currently and in the sysvinit past.
I enjoy the architecture, and hope to continue developing Upstart/startup or at least work with a similar model.
And yet none of those init systems are really being used in any significant way. It doesn't detract from them, but then they don't detract from systemd.
> All so I can seamlessly play music on TWO bluetooth speakers while also browsing logs without learning regex.
Are you suggesting that the alternative is to choose to just not support these features at all? (Which isn't implausible as a suggestion; OpenBSD doesn't support Bluetooth at all, for example. But in an ecosystem where everyone is building software to scratch their own itch, and then adopting the software that gains traction...)
I do not know about the person you are responding to, but I particularly take issue with how PA abstracts the hardware and does not allow low latency applications or servers such as Ardour, JACK, or other professional audio recording software to access it in an efficient manner.
So you end up with this weird situation where pulseaudio reroutes itself when JACK appears and no longer takes control of the sound card.
Why do we need to support two sound servers to take care of all the necessary features? I really hope pipewire fixes this use case and allows pro audio applications to work directly on top of pipewire while still supporting consumer friendly use cases like bluetooth speakers.
Just how loudly do you think people would complain if PulseAudio decided to link in JACK and replace it, instead of getting out of the way (and becoming a JACK client itself, I believe).
If PA was actually capable of half of what JACK does, they would be fine with it. These people just needs to record music without latency. But PA does not do what they need, so they would indeed complain.
I think what zlynx is saying is that even if PulseAudio emulated JACK, and did 100% of what people use in JACK, exactly as well or better than JACK did it, people would find something to complain about. Maybe they'd complain that PulseAudio is "bloated", or that this is yet another Poettering monolith.
FWIW I've been able to get similar input latency with PulseAudio as with JACK, that's not so much the issue as synchronization. If PulseAudio introduced a timecode like JACK, that'd probably be close to enough.
If you were really just going for minimum latency, your recording application would use ALSA directly.
This is not too difficult in PulseAudio. Every output has a "monitor" which can be routed to any application that's recording. You can do this through a GUI called pavucontrol, though it's not as pretty or flexible-looking as patchage or many of the other JACK patchbays. PulseAudio is, of course, more geared toward consumer and basic professional scenarios in general. Synchronization becomes important once you're routing through a couple of different applications.
All major Linux distributions are doing very well with systemd and it makes sense to have some kind of supervizor service (or collection of tools) on top of `init`. You can still tie together your applications with shell scripts and not run systemd. Since systemd it is simpler to admin different linux boxes - at least that is my personal experience - before that every distribution shipped their own shell scripts.
Systemd is fine and if it is so inferior to simple POSIX applications glued together, people should provide a better alternative. The grieve that people have against Lennart is overblown - we should thank him for his contributions.
The problem is the fundamental shift away from the long accepted design philosophy of software doing one thing and doing it well.
This means "grown adults" can't uninstall the software components that they like, because they aren't individual components anymore.
Systemd would probably not be hated on as much if it was only a "better" init. But instead it is an opaque and centralized system that is replacing a growing list of tooling (
init, ntp, cron, syslog, network config, to name a few)
You mean the myth of the UNIX way, never followed upon commercial UNIXes and somehow became a cargo cult on FOSS community only thank to a book of UNIX idols?
Right, the only true Unix philosophy which ever described reality was "worse is better."
Just look at the GNU coding guidelines, it explicitly mentions that GNU tools are not to use static buffers and silently truncate long lines. Why? Because that's what proprietary Unix implementations were doing at the time! Silent truncation of long input lines! Is that "doing one thing and doing it well" (DOTADIW)? Hell no!
DOTADIW is an ahistorical description of Unix. A humble-brag with little basis in reality.
>"Avoid arbitrary limits on the length or number of any data structure, including file names, lines, files, and symbols, by allocating all data structures dynamically. In most Unix utilities, “long lines are silently truncated”. This is not acceptable in a GNU utility."
So perhaps DOTADIW is a GNU philosophy, because it's one of the reasons GNU became so popular. Proprietary unix tools often did one thing and did it poorly, making GNU tools a breath of fresh air.
I think you misinterpreted parent’s statement, though, and/or they mistyped. The GNU Coding Standards says to not use static buffers, nor should GNU programs silently truncate long lines.
Not to mention the mess with glibc and their war against anyone who wants to do static linking. There's a long history of user-hostile behavior on various commercial and open-source Unices, usually to serve some outside agenda.
This aspect of the community is one of the biggest turnoffs to me. There are a lot of people who formulate these really over the top narratives about everything, which lead to (for example) writing long seething angry personal rants about people like Lennart (Miguel de Icaza was another lightning rod back in the day). The sheer emotion expressed invalidates whatever point they're trying to make, but at the end of the day nobody forces anyone to use anyone's software, and nowhere is that more true than in the Linux world.
I hate to use the possibly overloaded term 'virtue signaling', but I definitely see a lot of this as a form of virtue signaling within the communities that posters sometime imagine exist, or imagine that they're part of. I've seen so much of it over the years that it almost has a smell to it. A very vocal and bitter personal hatred towards Lennart and Lennart-related projects is sometimes a leading indicator, especially when it's presented not in the context of meaningful discussion of technology, but simply as "init was perfect and never needed to change and people who think otherwise don't understand what makes Linux Linux", stated as a truism.
I think a lot of people really like the community aspect of Linux, reading and posting to forums all the time, and latch on to certain mindsets as being the mindsets of who they imagine the insiders to be- you're supposed to love this person unconditionally, you're supposed to hate this person unconditionally, this company is good, that company is evil, this software is good, that software is evil, and if you're a true insider in the community you'll parrot all the same lines as everyone else. But when I see it, no one involved appears to be an insider. It comes across more as teenagers arguing on Reddit about iOS vs. Android, where basically they've decided that whatever phone their mom got them is the best thing ever, and the other thing is terrible, and it's their duty to go online and spew vitriol about it. They think they're arguing stuff that's much much deeper and more technical than what they're actually arguing about, and no one involved has any actual understanding of the technology or industries or communities or histories of the things they're screaming at each other about. It's almost like vitriol for the sake of vitriol, and people just let it seep out as a demonstration of their in-groupness.
Which is not to say that there are plenty of valid reasons and places and ways to argue about the merits of Lennart and his software, as one example. I'm really not talking about Lennart in particular though. I'm not talking about people having valid arguments about valid issues. What I'm talking about the FLOSS equivalent of those teenagers and their "the phone my mom got me is better than the phone your mom got me, and that makes me a good person and you a bad person" sorts of arguments. It just all seems very petty and immature sometimes, and that is not a positive aspect of the community.
Well stated description of the culture around this. I find it hard to take technical critiques of systemd seriously because the well was poisoned from day 1 by personalizing this to such a great degree.
Miguel has given an interview somewhere where he states creating Xamarin felt like a breath of fresh air, finally targeting a community that welcomed his ideas.
Completely agree. I can't stand how many people have such a strong opinion on some open source software. I find it amazing that there's so many negative blogs about the guy but no one has actually written a good (their version of good, not mine) init system that distributions will use.
> At some point you have to actually point out the issues productively, rather than the boring character assassination, or just randomly saying "the software's broken it sucks!"
But that's not the real problem here! Free Software was always about the freedom of choice. With systemd millions of users worldwide were forced to switch just because the architecture was designed in this way. Among these users were sysadmins who have to deal with many different machines and hardware/software problems. Before the systemd era diagnosing and fixing them was easier. We had survived quite a few revolutions in the past and it's not like we are unable to learn new tools, but this time the change made certain things unnecessarily complicated and gave users no choice.
That doesn't mean other stuff couldn't have been better. Here's the problem the systemd argument: it's motte-and-bailey. Systemd is a huge collection of tools, not just an init system: it's got resolved, journald, logind, tmpfiles, bootctl, networkd, and more. However, whenever it's criticized, proponents fall back on "but it's a great init system!" I agree that the unit files are better than rc scripts in many ways. However, there's so much other baggage that comes with systemd. Many people who use systemd in serious production systems have to replace many of these parts: journald -> rsyslogd, tmpfiles -> scripts, bootctl -> grub, networkd -> networkmangaer (or other), systemd-timesyncd -> chrony. Systemd does the "PID 1" stuff fine, but isn't so good at the other stuff. The project has gotten to big for its britches, so to speak: there are ~70 total systemd binaries.
They also didn't do a great job of modularity, and don't use dbus like they should (dbus isn't built to be used with an init system; use a socket already). Rather, they have every thing depending on another. Suddenly, everything must re-tool to work with systemd or stop working. It basically unilaterally declared itself the standard.
Other stuff:
* I hate binary logs
* Lennart, Lennart, give me back my cgroups
* Stop stealing my cgroups to track processes
* Security is not great, nor is code quality. This comes less from being inherently flawed and more from *sheer volume of code*, which is why you don't put that much code in PID 1. More attack surface, more potential bugs.
Overall, init ought not to be it's own problem of this scope. Just make a stinkin' init.
Oh, and Lennart Poettering is also a jerk. Not an "I'm brash" kind of jerk (like Linus can be), but an "I'm an insecure person; don't critique my code" kind of way. Also, he thinks he's smarter than every one.
> Oh, and Lennart Poettering is also a jerk. Not an "I'm brash" kind of jerk (like Linus can be), but an "I'm an insecure person; don't critique my code" kind of way. Also, he thinks he's smarter than every one.
I think it's largely due to how the community has treated him. It's frankly disgusting.
He's been that way for a long time; before he ever touched systemd. Same situation around avahi, and later around pulseaudio. I agree some people have behaved unkindly as well, but that doesn't excuse what he does. He also has a nasty habit of forcing his work into places where it is not wanted (especially now that he works for red hat).
I have to admit that avahi has caused me more trouble -- 100% CPU spin loops -- than any other piece of system software, over many years. It does nothing I want done, does it badly, and is inexplicably hard to get rid of.
PulseAudio mostly works, now, but I will be happy to see its low-latency successor displace it.
Systemd's only great sin is using up 100MB in each VM to do what should takevno more than 4M. As memory gets bigger, I run more VMs, so systemd usage grows apace. Maybe I should be running containers instead, but Qubes doesn't work that way.
He should take a lead from Drew DeVault. Drew frequently says things people (including myself) disagree with and is working on software a lot of people (including myself) are very skeptical of. Yet if you try to interact with him (as I have), he's a totally reasonable and pleasant dude.
The "community" in this case is in fact not a community at all, merely a loose set of people who's only common characteristic is having an opinion on systemd. A reasonable user of SystemD, like myself, has no power to coerce a complete stranger who sees fit to email Lennart a death threat.
The "community" cannot stop this. Either Lennart should work on how he handles such criticism/abuse, or Red Hat/IBM should hire a communications professional to insulate him from the outside world. Or he can keep the course and suffer the inevitable...
It's not right that he receives death threats, but the response to that unfortunate state of affairs needs to be realistic.
I'm not talking strictly about death threats, calling him random slurs already is too much and has happened on HN, this "loose set of people" should not, and it'd already probably change his opinion about different communities. Lennart should absolutely sometimes choose his words, like Linus, but I don't think we should be excusing insults with saying "it's unenforceable" when most places haven't really tried to remain civil due to personal beliefs.
What do you expect "the community" to do, downvote anybody who speaks harshly about him? That won't stop it, and even if it did it still wouldn't stop 4channers with anime avatars on github from trolling him constantly. There is no community solution to Lennart getting his feelings hurt. That's not an excuse, it's a cold truth.
There is little in this thread which even gets close to approaching incivil. And every time the systemd guys talk about online abuse, they always mention the worst of it, the death threats and other abuse from 4chan. Even if HN outright banned anything other than glowing praise of SystemD, that would not make a difference.
I'll reiterate: the notion of 'community' in this discussion is borderline meaningless and any attempt to govern it will fail for exactly that reason, and therefore any solution to the problem of SystemD developers feeling besieged that is predicated on governing the 'community' is, frankly, worthless.
Wow, are we insulting people like we're twelve now?
Again, I have to ask. Why are you not writing a replacement for systemd? Again, another person in this thread seems to think they know everything yet don't seem to have any code to show for it.
Please be advised, I've downvoted your comments asking "if you know better, where's your code?", because I think that line of argument is absurd and has no legitimacy.
To use some analogy, imagine I, a non-cook, have been invited to a restaurant by friends. After the meal I say to the waiter "this food is way too salty!", and he replies, "Oh yeah, then go in the kitchen and replace our cook!".
What, you think we all don't have dayjobs and can just devote our time to...
1) learn to code C/C++
2) learn about the OS
3) architect, code and debug a replacement
? Please don't be an absolutist and think "everyone can contribute to open source!", in the real world, time is finite.
No, your analogy isn't correct though. You're broadcasting your opinion on an online message board, not just a waiter. Plus, you're paying for the food. It's nothing alike. The parent comment is basically implying that the cook has cooked the dish completely wrong and that he (a non-cook) could do a better job of cooking that dish.
Plus, isn't this the great thing about open source? If someone doesn't like systemd, they can write they're own. Of course, not one does..
> What, you think we all don't have dayjobs and can just devote our time to...
I'm only suggesting this to the people who comment online complaining how the most used implementation isn't up to their personal standards and that they know how it could be done better.
It's easy to complain and bitch online, that's the problem. Everyone seems to know the solution but no one seems to do it.
> Please be advised, I've downvoted your comments asking "if you know better, where's your code?"
Please don't comment about the voting on comments. It never does any good, and it makes boring reading.
I think most people on here prefer–and I often see people asking for–an explanation of why they were downvoted. It seems those explanations usually do good. "Please don't comment about the voting on comments" refers to complaining about other people's downvotes.
See your point, but depends on your interpretation. I don't care about downvotes personally, for me it's a sign that they can't form an argument against mine.
I try not to get personal so normally I'm not downvoted for that at least, just being wrong heh.
> The parent comment is basically implying that the cook has cooked the dish completely wrong and that he (a non-cook) could do a better job of cooking that dish.
I may not know how to cook (insert complicated dish here) but I can tell if it's too salty. Users of systemd / whatever software this man wrote may not have the time to do all the stuff I mentioned, but they know using/configuring the system is a nightmare.
> It's easy to complain and bitch online, that's the problem. Everyone seems to know the solution but no one seems to do it.
I repeat, they might not know the solution, just that the software tastes bad to them. Some of these complainers might be able to come up with a better solution, if they had the 3 things I mentioned before, but sadly, apparently, no one actually does. Otherwise a replacement would already exist. Of course it's another thing to get distros to adapt it.
Their lack of time/ability doesn't mean they're forbidden to say "this thing sucks!". IMO at least.
> Wow, are we insulting people like we're twelve now?
How is that insulting? It's pretty much true. It's not really nice, but it's not really mean either.
> Why are you not writing a replacement for systemd?
There are already replacements. I use them in several places, mostly openrc. I'm perfectly allowed to grumble that something's bad and pushed into most distros. Plus, I'm generally stuck using it at work.
Next time you complain about, say, your car breaking down, I'll be sure to advise you to go build your own car.
> How is that insulting? It's pretty much true. It's not really nice, but it's not really mean either.
That's the point. It's not insulting and it makes you sound like you're twelve.
> Next time you complain about, say, your car breaking down, I'll be sure to advise you to go build your own car.
No, again. I see you're struggling. When my car breaks down, I ring a mechanic or take it to the garage. I don't go to the mechanic claiming to know exactly why my car broke down and how the manufacturer should change the specification to make it so that it doesn't break again. If my car keeps breaking down, I know not to use that model of car and try something else.
What you're doing is most likely using a piece of software, finding it doesn't suit your particular use case and then going online to insult the creator, and claim that you know how it should have been engineered.
It's completely fine that you don't like systemd. The problem is that a majority of people prefer it and that's pretty obvious from the distributions picking it up.
Stop and think for a while, imagine that's you who's created the software. Do you really think he's an evil genius trying to fuck up your system or is he just a hacker doing what he loves to do?
You also say "They also didn't do a great job of modularity, and don't use dbus like they should (dbus isn't built to be used with an init system; use a socket already). Rather, they have every thing depending on another. Suddenly, everything must re-tool to work with systemd or stop working. It basically unilaterally declared itself the standard.", but don't really have anything to back it up.
For example, Arch Linux reasons for picking up systemd:
0) it is hotplug capable
1) we can know the state of the system
2) it is modular
3) it allows dbus/udev to go back to doing the task they are meant to do
4) we can reduce the number of explicit ordering dependencies between daemons
5) we get a lot of security/sandboxing features for free
6) systemd service files can be written and distributed upstream
7) systemd is a cross-distro project
8) logind will finally deliver on what consolekit was supposed to do
9) systemd is fast
Aaaand retreat to the bailey. Systemd - the init - is not that bad. I think it does some things well. Most of what you listed is part of all the other junk I described. The "systemctl chunk" - the init itself - is not the problem.
> That's the point. It's not insulting and it makes you sound like you're twelve.
> What you're doing is most likely using a piece of software, finding it doesn't suit your particular use case and then going online to insult the creator, and claim that you know how it should have been engineered.
It's not insulting, but I'm "insulting the creator"? What exactly are you contending?
> It's completely fine that you don't like systemd. The problem is that a majority of people prefer it and that's pretty obvious from the distributions picking it up.
No, "most people" don't necessarily like it. There are things it does better, and things it does worse. How is a piece of software to improve if every one comes out of the woodwork to white-knight for it when some one criticizes it?
> [you] don't really have anything to back it up.
Dbus stands for desktop bus [0]. It's stated purposes are communicating between desktop applications and between the desktop and OS [1]. It is not built to do low-level init stuff during bootstrapping or within the init itself, hence the name Desktop bus.
I stated that systemd has ~70 binaries; I was off by one. It's 69 binaries [2]. Though, that's a 2013 source; it's taken over other things since then, so I'm sure it's more.
With respect to incompatibility: you now have to use journald. You can forward, but that's additional hassle and more potential breakage. See [3] for more.
Over all, I'd appreciate systemd if I could do one thing: remove everything but the actual init stuff. As far as I'm concerned, there are better options for most of the other stuff.
> It's not insulting, but I'm "insulting the creator"? What exactly are you contending?
If you tried to insult me, but I didn't find it insulting, you would still have gone online to insult me even though I didn't find it insulting.
> No, "most people" don't necessarily like it.
False, you're not 'most people'. Every main distribution has picked it up. You're living in a bubble perhaps.
> woodwork to white-knight for it when some one criticizes it?
Oh god, now the white-knight defense? Come on, your argument starts okay and then you say absolute rubbish like this. I fail to see how calling some programmer a moron is going to help improve systemd.
> It is not built to do low-level init stuff during bootstrapping or within the init itself, hence the name Desktop bus.
It started that way, but that's no longer true. Some could argue that systemd allows dbus to go back to what it does best. Before dbus was being use to start long running daemons, etc.
> With respect to incompatibility: you now have to use journald.
Very valid reasons for this, this video[0] conviced me but perhaps you won't be
swayed.
I think at this level the complaint (which I share) of all the things systemd tries to do falls more on the distros for handing so many things to systemd by default than on the systemd team giving us options for ways to do so many things.
I like unit files. I like having an optional watchdog for any given daemon integrated with my init. I don't particularly mind hostnamectl. I dislike resolverd but I see how some people could like it. I like having both signed binary logs and plaintext logs.
I wish the distros just made it simpler to pick and choose which systemd components we use at installation time. It would be better IMO than having to manually undo lots of integrations of parts of systemd I don't want and replacing them. So far the distro solution has seemed to be whole hog systemd or baby and bathwater, depending on the distro. Yes, we can set up our own base image and then maintain that, but should it be necessary?
> I wish the distros just made it simpler to pick and choose which systemd components we use at installation time
I think they do a fine job. The only mandatory parts in most distros are pid1, udev, journald, logins and machined.
I have two Raspberry Pis running Debian, one of them uses connman, the other uses systemd-networkd. My desktops use NetworkManager + firewalld, and so on.
Avahi, in all my experience over many years, does nothing noticeable besides going into 100% CPU spin loops at random intervals. Looking it up online, it is reported and declared fixed every couple of years. I would like to know why it still happens, and the right way to get rid of it, or at least to know why I have to have it.
I don't have any other system daemons that like to drop into 100% CPU spin loops. Should I be happy it doesn't fork bomb? I guess I am.
PulseAudio and systemd and avahi and probably other things he's been involved in solve problems I don't have, in intrusive ways, poorly and with much churn. It's not unreasonable to loathe someone who makes me wonder what exciting thing is going to break next in an exciting new way if i dare to update my system.
"systemd is, to put it mildly, controversial. As a FreeBSD developer I decided I wanted to know why.
I delved into the history of bootstrap systems, and even the history of UNIX and other contemporary operating systems, to try and work out why something like systemd was seem as necessary, if not desirable. I also tried to work out why so many people found it so upsetting, annoying, or otherwise rage-inducing.
Join me on a journey through the bootstrap process, the history of init, the reasons why change can be scary, and the discovery of a part of your OS you may not even know existed."
I've been using SystemD with little complaint since around 2011 or so when Fedora switched. I don't count myself among the systems haters, but that talk is hot garbage. It's just a big ad hominem that boils down to "people just hate change."
But that lacks explanatory power. Lots of things change and don't receive backlash, even in the desktop Linux domain. Plenty of people are skeptical of Wayland for instance, but the conversations tend to stay relatively cool-headed.
I think there are two things going on; the first and most significant is that most Linux desktop users (not sys admins or packagers, just desktop users) never had to know what a sysv init system was and never fucked with it, but then their distro switched, something broke (maybe their packagers' fault, maybe not!), they googled the problem and at the end of that Google dive they found out the answer involved a component they were previously unaware of, making itself known to them in a way that caused them hassle. Any upsides were washed out by this initial first bad experience. For me, I was using Fedora at the time so I knew I was getting bleeding edge shit and might get cut. That was exciting for me. It was my hobby, so I liked systemd. But that didn't blind me to the wants and desires of more typical desktop users who wanted the "just werks" experience.
(The other factor is that Lennart has bad social skills and it seems to rub off on the people he works with. Some might argue that the critics started it, but I don't care who started it. Stop jabbing your little sister or I'm turning this car around!)
Well, I think Lennart misjudged how much trouble his projects caused. And especially Systemd was nothing you could easily avoid. So I can understand that there were quite a few people angry at him and the way he was doing things. In addition, he is someone who can dish out to others too (I remember a (badly prepared) talk he attended and completely sabotaged by asking questions and make the speaker look like a total idiot).
So yes, he is prolific, his software does great things and his critics were definitely going too far, but he isn't completely innocent in regard to what happened.
> Well, I think Lennart misjudged how much trouble his projects caused. And especially Systemd was nothing you could easily avoid.
Think about your second sentence a bit, and why it's true: major Linux distributions adopted systemd. Did they do that because it really caused a bunch of trouble or because a deliberative review process showed that it solved a number of hard problems?
A small percentage of people having very loud emotional reactions doesn't mean that it actually caused large numbers of problems and at least in the enterprise space it's been really useful for cleaning up long-running reliability and security problems by removing thousands of lines of SysV kludge and manual work recovering from problems.
I have thought about it and I did so for years. I know that those projects solved hard issues and I also know that there are many people who would not have been able to complete those projects successfully. In fact, in 2011 I considered holding a presentation about how great systemd is.
But my point is a different one: If you manage such a project, you have to manage the change. And when you know that there are people who disagree with you on a fundamental level, it doesn't help driving your followers away by releasing breaking changes on a regular basis.
As an end-user, I remember for PulseAudio and systemd at least one instance where I had built something with it and after an update, it didn't work anymore and I had to adapt it.
So I don't believe that there was just a 'small percentage of people having very loud emotional reactions'. Instead, I think it was more like everybody had some problems adapting to systemd, but some saw the benefits it came with and others fought it as hard as they could (for various reasons).
So the problem isn't what Lennart had done (which is great), but how he got there. And I think Lennart would be happier today if he didn't do it the way he did.
i think Lennart should be commended. Certain "projects" have such breadth in scope that they seem undermountable because they require an entire ecosystem to follow. Init was one of these. He managed to change it, it hurt, but it was for the better, all things considered.
That is basically my position too, except the idea that Lennart has somehow caused people trouble with his projects, which is hilarious given how enthusiastically people adopt his software over the alternatives.
I really like systemd, though it has flaws. I was using Fedora at home, and Debian on servers when it was new. As soon as it was straightforward, I started using systemd on my Debian machines (building from source, when Debian was not systemd-based) and it solved a lot of issues I'd been having, made it dead simple to get new services up and running.
When Arch Linux switched to systemd, that was what convinced me to switch to Arch Linux on the desktop. I had been getting a lot of value out of systemd on Fedora, but I had wanted to try a proper rolling release.
I have a similar story with PulseAudio. I've owned many systems with no hardware mixer over the years, and the other options had been total trash.
PulseAudio actually worked. When I wanted a feature, it tended to be available on PulseAudio. In 2017, when I spent a lot of time between a laptop and a desktop (now I mostly just use a phone/PDA and a desktop), I liked being able to switch seamlessly between them.
I set up a network audio device as my second default sink (after local headphones) on both machines, so I could move my headphones between them, and whichever device was playing audio would play it through my headphones. It took hardly any fiddling about, thanks to Lennart's other project: Avahi.
Over the years, I hear a lot of people criticizing the software, but taking the functionality for granted. What systemd, PulseAudio, and Avahi do for ordinary people using GNU/Linux on the desktop is generally not possible with competing packages, which is why these packages are ubiquitous. It's not some grand conspiracy to take away your beloved OpenRC; systemd is just better (warts and all) than the alternatives, for the vast majority of users.
Obviously Lennart has personal issues with some people in some places, like any human being, but that has nothing to do with the software.
Richard Stallman may not have the best Spanish elocution, and GNU has flaws; does this tell you enough to know to choose a different libc, or a different core utilities package?
“Life does not ask what we want. It presents us with options”
— Thomas Sowell
For clarity, Bill Gates is also a very prolific guy that people love to hate. I take some time every day to curse both of them for the amount of dispair that they cause with their offsprings.
I've always wondered about this sentiment about software you are free to use or not. Or is it the fact that a majority of others, or those that have the power, choose for you by making life harder if you deviate? Shouldn't you curse those people, instead of the creators of the software?
A lot of software can feel like a bait and switch. To keep compatibility you have to use windows, but the quality goes up and down. Bundled IE, windows ME, then XP which people loved, then Vista, then windows 7 which people loved again, then windows 10. There isn't nearly as much freedom of choice when it is an all or nothing game and things are changing underneath you. Windows 10 reverts your settings after doing forced updates. It forces Cortana to be on and Microsoft has been found to have employees listening in on voice commands. This doesn't apply to bill gates any more, but it does illustrate why people end up using software they hate.
Seeing as gnome is/was nowhere near the top desktop environment, ubuntu had its own version of systemd at the time, and systemd had already garnered a huge amount of support across other distributions … no, it's not "the only reason" systemd won. systemd won on merits of practicality, because while the vocal minority hates some of the things it does (such as providing a bundled ecosystem of administrative software that all works together), it's also a big reason why it's popular across people who just want their computer to work.
From my understanding, and I may be wrong, the reason why systemd is..."controversial"...had mainly to do with the heavy-handed way it was incorporated.
It was almost like it appeared out of nowhere, written by one person who "thought he knew better" (maybe he did? but that's not the point), without any community input or discussion, and yet despite all of this somehow it got crammed into a distro (I don't recall which) - in what seemed to be an almost unilateral manner. A "my way or the highway" attitude of sorts.
It smacks of the whole "rockstar coder" mentality, where you have one guy on the team who forces everything to be his way, and he's begrudgingly recognised as probably right, and good for his work - but you still feel slighted as not having input on anything, because you're supposed to be a team (or a community).
What I really don't understand is how systemd has been so "infectious" - it seems like every distro is or has switched over to it...
...whereas init was (from what I know) more organic in how it came about, which might also explain its warts and other pitfalls that systemd supposedly addresses. I haven't been so deep in the weeds of linux to really understand all of the arguments of this nature; while I sympathise with the init crowd, I am but mostly a mere user of the system, who occasionally throws on an admin hat, but has found over time this has become less of a need for me to do (ah, for the olden days of Turbo Linux 2.0 and kernel recompiling - though my first Linux experience was via Monkey).
Had he introduced it in such a way to promote a discussion and dissemination of his ideas, maybe it wouldn't have turned out to be exactly like it is today, but it might have been more accepted (and maybe not as monolithic as I understand systemd to be - maybe it would have been more akin to a hybrid between his ideas and init?).
SysV init, which was the traditional type used on Linux systems (with some exceptions like Slackware), was itself derided by critics as overcomplicated. And since it was part of the commercial distribution of UNIX released by AT&T, it was viewed by many as corporate contamination. Not "organic" at all. The BSD world never accepted it.
After his foolish use of alloca() in systemd was revealed, it's clear that the derision is well deserved. One would think that after cutting his teeth on PulseAudio he'd have learned how to write safe, system level C.
There is even more depth to the alloca() fiasco than most people realize.
cppcheck could detect the bug without any hard setup effort (launching it in systemd codebase, with maybe an option to activate all checks, was enough) at least 2 years before it was revealed (probably more like at least 3 or 4, I don't remember the exact value). That's a fact easy to verify.
I suspect other tools could find it too, though I have not checked.
What that implies is more speculative, but there are some kind of "either or" situations that are extremely nasty. For example either RH (and all the other distro using it) did not analyse it, or they hid it for other reasons. The most reasonable hypothesis is that they just did not analyzed it. Which put them at least 15 years behind MS in some domains that were even more critical at the time (and still today) than 15 years before.
Please, it's not like any single other component in Linux desktop is somehow more secure. If anything, most stuff on Linux desktops are majorly more buggier and unsafe, they're just less popular in most cases.
Desktop code can be expected to fail sometimes. Core system components that orchestrate everything, should not. Ever. This requires disciplined programming that doesn't assume the stack is a limitless resource free to abuse and fill with tainted data.
Even Linux kernel has had tons and tons of vulnerabilities and bugs. Not to mention non-systemd core system components and services have been found exploitable times and times again. You can't set higher standards for systemd than other core pieces of software, it's simply not fair.
The Linux kernel has high standards. Most of the bugs come from the drivers. If systemd wants to be the end all be all init replacement it should have known from the start that it needed to meet a high bar of code quality.
Pay specially attention to "Making C Less Dangerous", "STACKLEAK: A Long Way to the Linux Kernel Mainline", "Sub-system Update: Kernel Self-Protection Project", "Year in Review: Android Kernel Security", "Sub-system Update: Linux Integrity Status Update", "Security Module Stacks that Don't Fall Over ".
It has high standards but the track record shows that standards isn't all it takes. We can always blame some subcomponent under someone else's control but the end result matters more.
If you want to systemd to adhere to really high standards then you're a hypocrite if you don't apply the same standards to every subcomponent of a non-systemd system, be it upstart, logrotated, cron, chrony or whatever else.
But it seems to me that you actually don't apply the same standards to the alternatives, they've all been hit with some vunerabilities, they all have bugs, they all have at least some terrible code, some lack maintenance or are just outdated. I wouldn't start throwing rocks from a glass house.
Oh and let's not forget that based on a pure empirical observation of the Linux ecosystem we can see that it is a better choice. And no, noone has been forced to use it(, neither was anyone forced to use Pulseaudio).
Obviously, since djb's daemon tools isn't used by default, which is exactly the sort of software that would be used by people who would rely on such functionality.
> It has high standards
One of SystemD's core contributers was banned from contributing to Linus' tree because his code was sub-standard.
> based on a pure empirical observation
...we should then also be able to see the Microsoft Windows operating system is a better choice.
I simply used to disable PulseAudio in favour of Alsa until it started working properly Out of the Box in a distro (which took, what, 3, 4, years?)
Not saying it wasn't needed, but it was anything but stable or efficient at the beginning (and given said person's behaviour in dealing with bugs and vulnerabilities in systemd, it is not hard to see why)
And somehow Fedora always seemed to do systemd and pulseaudio correctly. It's Debian and Ubuntu who somehow manage to make it into garbage. Is it intentional? Is it just because they use ancient, old versions? If indeed they want to be "stable" you'd think they'd update to incorporate the bug fixes.
For those not attuned, writing systemd as "SystemD" is a dogwhistle which comes from a time when Lennart specified that it wasn't meant to be capitalized, and this crowd went the other way just to spite him.
I do too thank him for actually manageable and nice-to-use service management and how much less it actually gets in my way than other inits, audio systems, logging and logrotating systems do. I instantly dismiss anyone's opinion who finds stuff like `rc-service $(name) status` or tracking down where the f* some garbage decides to log (turns out it's stdout >:|) even remotely acceptable.
For those looking for obscure-but-useful, checkout xdotool. `sleep 2; xdotool type "foo"` is super handy for typing passwords into virtual machines which don't support guest additions. I'd rather not elaborate on the filthy things I've made it do, but rest assured you can use it to do some quick and dirty automation tasks if you really need to :)
On macOS I use Keyboard Maestro[1] with a "Type String" macro[2]. Pops up an input[3] and then types the string you enter after a delay. One of many time-saving uses for KM!
Last time I tried Karabiner Elements, it was quite buggy and brought down the kernel. Not a happy camper. Then Apple blessed us with allowing Escape-Caps remapping out of the box (guess that Touch Bar resulted in something useful...)
I mainly use Hammerspoon as I prefer Lua over Json. I find Lua far easier to modify... to be fair, both Hammerspoon and Karabiner Elements have quite an impressive repository. If you want to do something it is probably already done.
My favourite is probably swapping of Cmd to Ctrl in VMs. That way you can use keybinds in Linux or Windows VM with the same muscle memory as in macOS. It may get confusing if you use Super a lot in Windows/Linux.
Another one is rebinding right Option (or "Alt") to Hyper. Most of the keybinds I use I got from this repo [1]. Though I did make quite some modifications I found it a good starting point (merging my own back). I remap Caps to Escape and Ctrl (latter if combined with another key) via Hammerspoon. You could also use Karabiner Elements though. Although I still use Caps mainly for Esc (muscle memory...)
On a Windows computer, I used AutoHotKey for some other stuff (gaming related QoL improvements). For some reason, Blizzard decided that in WoW you are not allowed to spam a key if you hold it. Which is flat out painful for the hands. I no longer play WoW regularly though. If I do, it is via Wine (on a Linux desktop). In Diablo 3 I made a keybind to swap gearsets. This was before Blizzard implemented the wardrobe.
I've started using it a few months ago, and it seems pretty stable.
I've got a fancier mapping for the caps lock key: when you hold it, it works like ctrl, and when you tap it it works like escape.
I've also got something similar for space: when I tap space, it works like space. When I hold space, I can tap additional characters. (So space works like a modifier, similar to ctrl or shift.) For example, space-x = delete, space-p = page up, space-j = cursor down.
The space one however, did not work well for me. It resulted too frequently in space not working at all. Supposedly it got matched as a combination with another key instead of a tap.
I recommend to apply a new rule, then test it out, then make another change. This way, you figure out which rule poses an issue.
There is one ruleset in Hammerspoon in the Github repo which I mentioned which -for me- makes it impossible to type cd. It always becomes c d
One of the three major reasons why I use Mac OS rather than Linux is the existence of Keyboard Maestro and TextExpander, which do tons of useful things and work everywhere. (if you care, the second reason is working system-wide clipboard and the third reason is Emacs keybindings in ALL dialog boxes and inputs).
However, I really dislike how if I click what is traditionally the maximize button, it doesn't maximize both horizontally and vertically. I also really dislike how if I use the fullscreen mode and then use alt tab to switch windows it takes like 400ms to transition with some animation, and I can't disable it. I also really dislike how alt tab behaves, I want it to switch all windows not window classes. I also really dislike that I can't alt-click+drag to resize or move windows like I can in linux.
But most of all, I really dislike that there's no easy way to modify these behaviors without installing third party applications which at best can be described as dirty hacks.
They're the major reasons I use GNU/Linux over MacOS. Or would choose Windows over MacOS if Linux wasn't available.
> However, I really dislike how if I click what is traditionally the maximize button
That's no keybind though. The keybind for fullscreen is Control-Command-F as per [1]. On Firefox, I use Tree Tab Style and in order to hide the tabs, I need to also hide the top bar with the 3 top left window management symbols. Forced me to learn the shortcut (Cmd+H is another one I regularly use, to hide current application).
We should assume the user also is able to utilize multitouch gestures on TrackPad.
Fullscreen applications work very well with 3 finger swipe up which yields all windows and desktops, or 3 finger swipe down which allows further interaction to select the top window. Triple swipe left and right switch to current desktop minus or plus one. If you're going to run a VM, you will need these gestures.
Nothing in Linux land beats these gestures nor the Apple Magic Trackpads, IMO. I've been trying to get my Apple Magic TrackPad 2 to work on Linux. With multitouch. It works, but not as good as on macOS (tried with Libinput 1.13, not 1.14 yet).
You can use Cmd+` to swap between application windows. Nice boss key.
I found two third party apps which potentially fix your issue: Witch and HyperSwitch.
> and then use alt tab to switch windows it takes like 400ms to transition with some animation, and I can't disable it.
I didn't find a way to fix this. It does not bother me, as it is easy on the eyes, but I understand your concern. I also agree it is annoying that we need third party applications to fix these use cases but it does go with the minimalism theme. You could regard Gnome Tweaks as the same problem. And there's more third party applications I wouldn't want to live without such as Bartender.
> I also really dislike that I can't alt-click+drag to resize or move windows like I can in linux.
For resizing or dragging you can do this with the titlebar. I'd use one of these third-party applications like Spectacle or Amethyst to manage windows. I agree its a loss this isn't native. (I suppose Hyperdock provides this functionality?)
If you're doomed to use Windows, you could use AutoHotKey (if allowed to).
It is FOSS, the scripting language is simple (though not Python, like AutoKey, there is an old Python port of it), and there is a large community with decent documentation and examples available.
AutoHotKey, unfortunately, does not work on Linux, at all. Not even with Wine.
I love that the keybinds on macOS are rather universal.
- Unit/Integration test X11 tools inside docker Xephyr sessions during CI
- Transplant magnet links from ThePirateBay into a bittorrent client
- Type stuff into virtual machines rather than install guest
additions
- Import data into remote desktop sessions for otherwise internet-isolated+Copypaste disabled remote hosts, complete with integrity checking powershell scripts which were also imported into the environment that were used to self-integrity check prior to integrity checking other files.
The use of xdotool is probably an antipattern in a perfect world, but that doesn't mean that it's not damn handy from time to time.
One of the less awful things I've done with xdotool is to hook into latexmk to continuously update the window title of the resulting PDF with the compilation status. So you can have the screen split just between editor and pdf viewer, with the compile always running in the background, yet know what the status is. This got upstreamed into latexmk some years back.
I recently had to do some mandatory training which would require me to spend 30h in front of the computer clicking every couple of seconds. The issue is that I already know the material perfectly well, so my time would be spent better learning something else.
Nothing so difficult that couldn't be done with simple shell loop and automated clicking with xdotool:)
I rememberdemoing Sikuli to the boss, when it clicked where we didn't expected just because the web we were trying to automate had a link we didn't notice.
xdotool is the dirty magic underlying my personal voice-control system for Linux. Super-useful for being able to arbitrarily interface with X, without having to learn the insane interface you're supposed to use.
Oh man. This made my Friday - just an adorable bitmap bear on my Debian 10 desktop... get this - when you move him, the dragging cursor is a little heart <3
Only problem is now I feel slightly guilty sending a teddy bear a SIGINT.
I still miss a good debugging GUI with useful data visualizations. Sometimes staring at pointers and (multidimensional) arrays of numbers just isn't enough.
For data visualizations I use gdb's Python API. For simple things that can be just adding pretty printers, for hairy things it can be a custom command that prints extra information or dumps it to a graphviz script.
Was it DDD that didn't support threads, or GDB though? I remember that GDB support for threads was horrific for a long time, especially back in the 90's.
My two favorites were xev, for finding out which key/event codes I needed to put in config files, and xnest, for trying out new window managers or containing window-happy applications in a single top-level window before workspaces became a common thing.
Also xmag, for those "what is going on at the pixel level" questions that screenshots are poor at answering. Alas, this doesn't work on wayland for obvious (yet... deeply regrettable) security reasons.
Fun point of trivia about XBill: you might not guess from XBill's (ahem) slick, beautiful user interface, but one of the two people who wrote XBill is Matias Duarte.
Yes, that Matias Duarte, the guy in charge of UI for Android and who came up with Material Design.
There is not much of a GUI in XBill- just a bloody program with a menu and a window. The same can be said about Android - Windows 1.0 rereleased. From an engineering point of view XBill is a better achievement than the GUI of Android.
Tgif is one of my all-time favorite X11 programs. It's used to create vector drawings, and I could whip out nice infrastructure diagrams etc. so fast using it.
xeyes is also a great way to tell if you're in a Wayland session. If it tracks your mouse always, it's X. If it only tracks in its own window, it's Wayland.
I was expecting X11 tools such as xev, xdotool, wmctrl, etc. Not a list a more or less obscure graphical programs (some stuff are even using GTK in the list). Fun nonetheless.
Many of those types of programs like XRoach, XSnow, XNeko as well as every program rendering to the root window will never be possible with wayland (unless you built them into the display server).
XRoach doesn't work even on a modern X desktop. The background window on, say, gnome, isn't really the root window. I compiled XRoach a few years ago and didn't understand at first why it wasn't working. I don't know if any of the modern desktops have an actual root window that's visible.
You can run a virtual X-Server, like Xephyr or Xnest. They are pretty handy and will make it easy to use root painting programs.
Fun Fact: The XScreensaver "preview" function works (worked?) as following: Start an instance of Xnest and run the screensaver rendering the root window there.
XMosaic - I remember reading about that in '93 and thinking that it looked like a cool hypertext browser but why would anyone want to load documents over a network!
Shameless plug - you can add also my tiny transset rewrite and enrichment - set_opacity[1]. It allows making X windows translucent, without any interaction required. Wrote it more than a decade ago, but still should be usable. This is how you can use it:
set_opacity -o 0.5 -i `pgrep gkrellm`
There is also a patched[2] xcompmgr with the colored shadows support:
xfig also has one of the few implementations of x-splines (x means "cross" here, like "pedestrian xing", unrelated to the X window system). I find x-splines very nice and intuitive.
Ah Motif, XBill and Afterstep! My nostalgia bit just got set.
My first experiences of GUI programming on Unix (HPUX on a Motorola 68040 machine) was with Motif, which was a pretty good toolkit after you got used to the very long function names.
The rendering on that 42s is close enough that I can almost feel the buttons. Never thought I'd describe a calculator as sensual, but HP's of that era had such a distinct look and feel.
This is a great find. I used a 42S heavily through high school and college. I was surprised at how some of the muscle memory of how I did certain things came back. Seeing the dot matrix answer after doing some calculations brought back the feeling of being bored in math class, when I would just play with all the functions and write little programs. I didn't have a phone or even a laptop to turn to in those days.
Even now though, it will be useful to do calculations in RPN. Even the ability to swap X and Y, and store intermediate results in order to avoid parentheses or M buttons is nice.
Not sure if it counts as obscure, but to add to the note on xclipboard: xclip, which lets you change and inspect the primary selection/clipboard from the command line.
This reminded me of xjump, a very addictive falling tower game where you must continue to jump to the next highest platform as the lower platforms collapse beneath you.
I wish I could find game xjumpxjump, it was a small number puzzle I played a lot in FreeBSD. It was removed from ports years ago and I have yet to find the src :(
Sometimes xterm is still used; I use xterm. It is still being maintained, too. I also sometimes use xfontsel. I do not think these are so obscure, isn't it?
Some of them, although I do not use them, I would not think they are so obscure, such as xbiff, xload, xclock (I have the functions of all three programs in another program I wrote, to display on a status line).
The GTK screenshots all use then ThinIce theme[1] – still my favorite, but sadly not available for GTK 3 or 4. And I guess it wouldn't fit with GNOME's current design direction anyway.
xcostena. It was an X application written at SGI which took an order and faxed it to La Costena, a taqueria on Rengstorff (at the time). It might have been the first case of e-commerce on the internet and this was pre-web.
Let me add my own cool but obscure project KDocker. You can use kdocker to move any app to the system tray :) These days it's maintained by john at https://github.com/user-none/KDocker
Edit: oh wow, I actually tried it again now and it actually works! Crazy, this was a tool I wrote like 12-13 years ago. I also found the initial sourceforge page - http://kdocker.sourceforge.net/
I switched to the "display" command from the various image/graphics magic packages years ago, and now am frustratingly finding it has become unstable.
But, recently seeing some PBS specials on NASA and the planetary probes made me reminisce about "xv". I remember having downloaded images of the Shoemaker-Levy comet impact on Jupiter and browsing them with xv...
That grey-and-pink color scheme from the screenshots gives me such a wave of nostalgia. It is fascinating how this color scheme is both terribly, terribly ugly and gorgeous at the same time. ;-)
Nice nostalgia. Unfortunately most of the ones that deal with text are from before the 8bit to utf-8 move, which makes them unusable nowadays (unless you restrict yourself to ASCII).
Takes me back so many years to grad school. I still find myself using a few of the tools though, even after all these years. xload for one is a favourite.
Strange coincidence this appears on the front page, as I have been having system instability with freezes, and my hunch is that it's something with the QT library. So lately I've been running only X programs instead of KDE apps, and it hasn't frozen in a while. This list will give me some additional apps to play with.
Guess 1: this page was originally going to be "Cool X11 Tools from the 1990's."
Guess 2: perhaps the X11 version of vim is obscure. I usually visualize vim users working in a terminal, with those interested in a GUI text editor using something else.
Cloud computing is becoming a thing ... eg. apps that runs "in the cloud" or in your browser. But with Xserver you can just ssh -X into any machine, run an app, and the front-end GUI will be visible on your machine! You can even play games that way. Technology keeps going in circles ...
It usually helps a bit to enable ssh compression. But, some toolkits are better than others at managing the X connection; in general, things have gotten worse and worse as X over network has gotten less and less popular.
To some degree, you're never going to have a snappy experience when the program and the display have a 50+ms round trip, but it's much worse if the program makes lots of synchronous calls to the display while doing work.
Most of the older tools discussed here should be pretty good at managing the X connection and are probably doing more things in an asynchronous manner.
It works fine for me, but I can not really see any use cases, as I can just run the app locally. Use case's might be thin devices, like mobile phones and Chromebooks. Instead of running containers on Chromebooks, students could ssh into a computer that has all the apps they need; GUI apps like Photoshop, CAD, etc.
Just a couple days ago, I used remote X to show some coworkers some things:
a) a (bad) NES emulator i wrote that was on my home machine, I didn't want to compile it on the work laptop
b) chrome running on the home machine hitting a webcam pointed at a pressure gauge --- I didn't want to bother with proxying and prozy settings, and I don't let the webcam accept connections from public internet.
I've also found it super useful for running java based KVM clients for IPMI --- run a VM with the properly old version of java so the webstart file works, and display it with remote X.
xv or eog is nice for looking at images without the hassle of transferring them first (although, transferring them would probably use less bandwidth)
Some more obscure games were there, for example Sun Microsystems once released a book about games available on Solaris, which included a flight simulator amongst many others. Though I am unable to recollect the name.
To be fair, it's Gvim that's listed, which presumably is bundled with the main vim package.
I had some vague awareness there was a GUI version of Vim, but only just checked it out after spotting it in the list. The menus serve as a handy reference for common commands. Quite good really.
With the exception of local editors (gvim) and administration software (xload), the need for these applications is easier to satisfy with online HTML5 apps.
These are historically exciting, but nowadays the web browser is your X11.
It was pretty good if I recall (from twenty years ago), but not exactly like like arcade game. I sort of miss games like that -- Xchomp (a Pac-Man game) is another. Before the advent of emulators, programmers used to make versions of arcade games that they hadn't seen in years, making them (intentionally or not) different from their inspirations.
Some of these are not obscure at all, but absolutely standard. Xterm was the shell, I’m not sure there were even alternatives in early X. Xbiff+Xload+Xclock used to be on everybody’s desktop. XV was the main image viewer on X for a long time.
Anybody remember xvacuum? I guess it’s truly obscure since it didn’t make the list. One of my favorite tricks to play on other people in the lab, before X security was a thing, was to run xvacuum on other people’s displays ... it slowly sucks everything on the screen into the mouse cursor.
If the page maintainer is reading, Xsnow has a calculator in the screenshot covering the snow. This one is a bit obscure, but I loved xsnow, so I think it deserves a calculator-less view! :)