The context here is that someone new randomly showed up on the xorg-devel mailing list, and started asking a ton of questions about the codebase, which has lead to a couple of cleanups. I wouldn't read too much into it.
A very traditional way to run a mail system is to have the mailserver store the user's mail in their home directory, typically in either maildir or mbox format. Mail clients can then read mail directly from the same place the mail server stores it, rather than having to maintain their own copy. This is a very handy optimization and a lot of "traditional" (read: TUI) mail clients fully support and, indeed, were primarily designed to be used this way. Common TUI mail clients tend to assume a local maildir or mbox, and accessing mail boxes via IMAP is a feature bolted on later, sometimes a bit awkwardly.
A major advantage is that it allows all of the mail tools you might use to operate on the same working copy of your inbox, saving a lot of time synchronizing things. This was a lot more important historically when a typical Unix user would probably have a few different tools they used for mail, like a full-on TUI mailbox viewer and a couple of CLI tools.
I don't find it very compelling that Thunderbird needs to add this functionality, because that's a pretty old-fashioned way of running mail that you probably won't see outside of technical universities and other institutions with a very "traditional" approach to their systems. That's the use-case, though, and I do see that if you are in an environment where your mail is already present in your home directory, or you use multiple mail clients, it would be annoying that Thunderbird can't operate this way when a lot of its contemporaries can.
It's practically more of an issue, though, because Thunderbird kind of supports it, it's just incomplete. That makes it feel less like a feature Thunderbird doesn't have and more like a bug.
Yes, over NFS it's slow, but nowadays everyone has local devices or they just login via SSH or virtualize whole desktops.
Still, if you have over 100k emails, mbox will be slow to parse for obvious reasons as it has to parse every line with often having mboxes as huge as 500MB if not more. Your FS and VFS layers will do a far better task on reading the first lines of thousands of files. In such case your mail client will parse the headers to generate the inbox layout in a much faster way.
> Still, if you have over 100k emails, mbox will be slow to parse for obvious reasons as it has to parse every line with often having mboxes as huge as 500MB if not more.
No, you don't. You store in your metadata database what the offset of the message in the mbox file is. If you don't have such a metadata database, then you're going to be very slow no matter what the storage is.
> Load a GB sized mbox into mail(1) and then say that again.
In other words, use mbox with an application that doesn't have its own message metadata database and you get problems. But if you're designing your own email client in the 21st century, then you're going to want to build your own message metadata database.
if thunderbird doesn't support maildir, either you can't store your email in a maildir, or you can't use thunderbird. maildir has some real advantages, and so does thunderbird, and it would be nice to be able to combine them
Fetchmail on my laptop fetches messages from the IMAP server and procmail + postfix delivers them (after some mangling) to the maildir in my home directory. So whatever mail client I use needs to be able to read that.
Maildir is probably the best way to handle multiple readers one mail source, ie, reading your mail from two+ locations, two+ operating systems, whatever.
IMAP just kludges, and you end up with situations like I have, where thunderbird frequently reports that one mailbox is 'locked' because thunderbird crashed while accessing it several years ago and who knows how to get gmail to forget about imap 'locks'.
> thunderbird frequently reports that one mailbox is 'locked' because thunderbird crashed while accessing it several years ago
That's a lockfile left over on the local filesystem. That's caused by Thunderbird having two threads open on the same folder (i.e. you ran 'update all folders' and then 'compact folders' and they're overlapping)
If you open TB, let it sit for a while, then do file>offline>sync now - then let it complete - make sure all the folders are selected for local download (if this is applicable or viable for your use case)
then wait a while
then do 'compact folders'
it shouldn't happen again
You might also want to go into the 'account settings' and turn 'maximum number of server connections to cache' down to 2 - some IMAP servers get really bothered if you open too many connections to them. It's meant to autoadjust but it doesn't always. 2 lets you have one connection always open to the inbox for push mail and one available for working on other folders.
Yeah TB behaves a lot nicer when you have a 100% complete snapshot of the IMAP account locally; a lot of things in it seem to work a lot faster and more predictably when all the folders are fully synced.
I'd run that 'offline->download/sync' every week or so. It'll automatically sync every folder you open, but running that syncs them all, and if you're an organisation fiend like me you have like 100 folders.
In addition you can take a manual backup of your email now by just zipping up the thunderbird profile folder. Always useful.
Oh man, he'd been on our (Xfce) mailing list for a while, sending a ton of merge requests for various cleanups to our window manager and other components. While I wouldn't say what he was doing was completely useless, it was generally not super helpful, didn't really need to be done, and mainly just caused code churn. On my less charitable days it felt like he was just trying to get his name out there and into the commit history of a lot of projects, but the time and effort he was spending was probably too much if that was the motivation.
Several of his MRs ended up becoming out of date and full of merge conflicts because of other work that was being done, and it just seemed like a waste of time to me.
Someone downthread posted a link where Linus Torvalds himself excoriates this guy for posting anti-vaxxer nonsense to the lkml. That... really takes the cake.
This kind of energy should ideally be molded and funneled into more useful project needs, if they are focusing on trivial cleanups. An enthusiastic free worker comes off as a useful thing.
Fair point, but most of us on the team don't really have much time to spare to work on the project at all, let alone for mentorship, unfortunately. We'd rather be writing our own code, and taking contributions from people who don't require a lot of hand-holding. And it's not like this guy is an entry-level developer. He's clearly been doing it for a while, and is skilled. More like he needs to be taught how to interact with other developers on the internet in order to contribute without turning into a burden on others' time. Unfortunately I don't have the time (or patience, really) to teach that sort of thing.
I’ve never interacted with this person in particular, but your description makes me feel seen. It so perfectly describes interactions I’ve had - where a clearly well meaning and in some ways capable developer makes tons of change requests, which are sort of neutral or maybe slightly positive even, but take up so much effort to incorporate relative to their value that it’s just not worth it, and in my estimation would be better off disappearing.
Often times, when I do work with them to get their changes merged, I’m tempted to make similar changes myself, rather than workshop pull requests for days and weeks. Not because I think the changes are even worthwhile to incorporate, but because it’s less painful than the back and forth to get their changes up to snuff - but “stealing their idea” is socially awkward for its own reasons.
There’s also sometimes a bias towards merging unless you find a problem, so it can feel really antagonistic. Strangers on the internet become your task masters to an extent.
The common reactions I see to not wanting these kind of contributions are “You’re looking a gift horse in the mouth!” Or “It would go more smoothly if you spent more time unwillingly being a Manager for strangers on the internet” or “You’re gate keeping.” To an extent I suppose all these things are true. But, that doesn’t mean it’s the wrong decision. It can be frustrating to experience and difficult to explain if you haven’t been in the position.
Anyway, it’s nice to hear someone else articulate my experience. It makes me feel less crazy. So I wanted to partially return the favor and say also that you may not be crazy.
That's pretty much been the status quo for us for 20+ years now, and yet we're still chugging along, making regular major releases every 2 years, with bugfix releases periodically in between. I worked on it from 2004 to 2009, took a long break, and got involved again about a year and a half ago. The cast of characters (aside from the original project creator) have all changed, but there's still enough interest to keep things going.
And sure, maybe that will change someday, and interest will fade, and the project will end up unmaintained. That'd be a shame, but that's fine. Doesn't invalidate or make useless what we're doing now, and doesn't mean our users need to make any big plans to change their workflows.
I don't often get the chance to talk to people that work on software I've used every day for years and years - so thank you for all of your work on XFCE. It's a fantastic project that 'just works'.
This is one of the most uncharitable views I think you could take. You don't seem to have a nice thing to say about him. And have managed to pack a bit of negative insinuation in without any actual evidence or substance.
Frankly, the dude is involved in cleaning up X.org code that is otherwise verging on unmaintainable. The appropriate response is a shrug and a "thanks". Backbiting is generally the wrong approach to attempted OSS contributions. If you have problems with his PRs go bring them up with him.
There was a talk a long time ago (sorry, can't credit it) where the speaker pointed out that some contributors end up providing net negative value to the project: the value of their contributions is outweighed by the amount of time spent interacting with them in bug reports or the like.
There are two reports in this thread of the contributor here derailing a conversation with something irrelevant. Another report is of him providing low benefit/high noise patches. If you start reading the mailing list posts linked up thread, his contributions to X.org seem to be veering in this direction too: the most recent idea is to... replace include guards with #pragma once. He was called out for this by the X.org maintainers (see https://lists.x.org/archives/xorg-devel/2024-February/059159...).
This bit from that reply covers a lot of how his changes felt to me:
> Looking at this particular thing, what problem are you trying to solve? The existing header files already have the protection in place where it matters. And I don't expect why software that's mostly just in maintenance mode would see a lot of new header files being added.
Quite a few of his changes seemed to me to have the motivation of "I like it better this way and think you should adopt my sense of taste". If you expressed interest in becoming a maintainer of one of our not-so-well-maintained components, then sure, go nuts. But changing a bunch of stuff to your style in code that I have to continue to maintain? No thanks.
It wasn't all like this; one MR I recall changed the names of a bunch of constants so they'd be consistent with each other and what they were for (e.g. prefixing things in a certain way depending on if they were configuration key names, default values, etc.). That I do think was useful. Unfortunately I think that particular MR ended up not working out, because he never talked to me about his ideas in the first place, and I had a branch I'd been working on for a few weeks that, when merged, made his work full of merge conflicts and ultimately not as necessary anymore. And that was part of the issue: if he would have discussed the changes with me beforehand, I would have said "sure, that sounds useful, but you might want to wait a week or so until I merge this feature branch, which is going to change a lot of the code you're going to touch". But... nope, he wanted to lone-ranger it.
Maybe don't criticize without knowing the full situation, eh? Your uninformed, holier-than-thou attempt at dressing me down isn't particularly useful.
Guy was a pain on the mailing list (and occasionally on IRC, too), nagging for code reviews and merges, against a team of part-time volunteers. He'd open many merge requests in a short time span, most of them changing a fair bit of code, some doing some mid-sized refactoring. Very rarely would he discuss his changes with the maintainers before making them.
And when someone disagreed with his approach, he'd get testy and push his point of view harder. Not a team player, not someone I'd ever want to work with, whether on a volunteer open source project or in a professional paid work setting.
> The appropriate response is a shrug and a "thanks".
Not if the contributions (and interactions with the contributor) create a lot of make-work for the maintainers where the benefit is unclear or known to be fairly low. I'm certainly not going to thank someone for creating more work for me that doesn't need to be done.
> If you have problems with his PRs go bring them up with him.
The problems were mostly "this doesn't need to be done, and you're changing the code from something I already know to something I don't, and I'm the one who has to navigate and maintain it, so this will be a net negative to me". And yet... the MRs kept coming.
I'm not going to claim the existing code is the best code in the world; some of my parts were written by me 15-20 years ago when I was fairly junior, and it could use some improvement. But going in and changing things without first talking to a maintainer is not the way to do it.
Don't get me wrong, some MRs ended up getting merged. Some of the maintainers did think that some of them were useful. But it felt like sorting through all of it to figure out what was actually useful, was more effort than it was worth.
If he's causing you stress migraines over in Xfce land, go ban him over there. You're wasting your time trying to convince me you don't like his work, and you're still not going with evidence or substance of a problem. Some people raise a lot of PRs.
> Maybe don't criticize without knowing the full situation, eh? Your uninformed, holier-than-thou attempt at dressing me down isn't particularly useful.
My key complaint, you'll note, is that you aren't providing any details of the full situation and those that you are providing are uncharitable takes. I mean, you're being nasty to the dude and your complaint seems to be he isn't a senior dev. Fair enough. If you only want to review PRs by senior devs, warn the fellow then block him [0]. Don't go with public shaming as a strategy; HN is a big forum forum, the dude isn't here and he's presumably working under his real name.
If you want to be mean because he's done something go ahead. But unless you're going to say he's actually done something bad, I'm going to note you're being mean without a complaint and that is poor form.
> And when someone disagreed with his approach, he'd get testy and push his point of view harder.
I can't pass that by without noting some irony, given the comment it is in context of.
Software devs are known for this.
[0] I speak loosely. Mr Lots of PRs could be anyone for all I know.
> My key complaint, you'll note, is that you aren't providing any details of the full situation and those that you are providing are uncharitable takes.
You're replying to a post where I just provided more details! Regardless, everything everyone posts here is their opinion, and I'm entitled to mine. You don't have to take my word for it, you can be skeptical, you can think I'm an asshole and a blowhard... that's all fine, and is your prerogative.
> I mean, you're being nasty to the dude and your complaint seems to be he isn't a senior dev. Fair enough.
Seems like it's not "fair enough", since you seem to take such exception with my point of view. I don't think he's not a senior dev -- or rather, I think he's a fairly senior programmer, but isn't so senior in the sense of how he works with other developers. That's a skillset that unfortunately some people don't learn as quickly as they learn to code.
> Don't go with public shaming as a strategy; HN is a big forum forum, the dude isn't here and he's presumably working under his real name.
I don't have a "strategy" here; I'm merely responding to the topic in the thread at hand. If you don't find my point of view valuable, fine, downvote it (or flag it, if you think it's particularly egregious), and move on. If you think it's crass of me to air my opinion of someone else on HN, that's fine too, but I'm still permitted to share that opinion if I feel like it.
> If you want to be mean because he's done something go ahead. But unless you're going to say he's actually done something bad, I'm going to note you're being mean without a complaint and that is poor form.
I don't really see myself as being mean; you claim I haven't said what he's done, and yet you've just replied to a post where I've given more detail into what I believe he did wrong. If you're going to choose to ignore it, or decide it's not "enough" based on whatever rubric you've chosen, then I'm not really sure what to tell you.
> > And when someone disagreed with his approach, he'd get testy and push his point of view harder.
> I can't pass that by without noting some irony, given the comment it is in context of.
> Software devs are known for this.
Hah! Fair point. I think the difference here is that he was an outsider, poking into an established project, trying to push his views on others, when those views were not agreed with. And then continued to push them after being told they weren't agreed with.
> I don't really see myself as being mean; you claim I haven't said what he's done, and yet you've just replied to a post where I've given more detail into what I believe he did wrong. If you're going to choose to ignore it, or decide it's not "enough" based on whatever rubric you've chosen, then I'm not really sure what to tell you.
Well; yeah. I think what you've said is what you have - you got a bad vibe on the fellow, found him annoying but aren't in a position to back the sense up with anything specific. No actual situations were problematic enough to point at and a code contribution eventually got merged. You're listing a bunch of things where the charitable take is "this sounds pretty normal". The dude wrote a lot of code without talking to the maintainer first; he thought what he was doing was a good idea and the maintainers got a bit exasperated interacting with him. Nothing there justifies the mean comment, I'd suggest most people have done that somewhere at some point. Random unnecessary rewrites is literally how I get to know new codebases, although I usually delete them rather than trying to get them merged but if they were technical improvements I could see myself giving it a shot.
Given your response to a relatively mild dose of feedback on backbiting; I think you probably can figure out why I see the comment as mean. I haven't impugned your motives or questioned your technical competence and you jumped pretty quickly to seeing an "uninformed, holier-than-thou attempt at dressing me down". Maybe this dude is the next Hans Reiser, but even then if you're going to go at some random contributor's reputation it'd be fair to have some specifics. Dates, links and examples that showcase abnormal behaviour to a bar where it needs to be shared.
> ...you can think I'm an asshole and a blowhard...
You might be expecting people to read a bit too much into comments? As far as I know we've exchanged 3; that isn't enough to get a great clear read on someone outside the topic at hand. Let the records record that I'm not seeing obvious personality tells in your comments. We're all in it together.
> If you don't find my point of view valuable, fine, downvote it
Fun fact; I practically don't downvote things. And the last comment I flagged was in 2022. Either something gets ignored or I post a comment. Downvotes are too ambiguous a signal.
> Random unnecessary rewrites is literally how I get to know new codebases, although I usually delete them rather than trying to get them merged but if they were technical improvements I could see myself giving it a shot.
This I think highlights the key disconnect here. From this statement alone, it is clear to me that you have respect for maintainers' time (for lack of better terminology). This will tend to clearly come across in proposing patches or other interactions, even though it can be difficult to pin it down as something other than vibes.
> outside of the XWayland scope given the diminishing developer interest and lots of talk but little action by those anti-Wayland holdouts in the community to actually contribute to X.Org Server development.
I don't know.. maybe they're actually rising to this "challenge."
Although, I've never understood why the presence of Wayland means X.Org needs to disappear. To me it seems part of our modern churlish desktop software cult that is perennially annoyed that their new systems, while slightly more visually appealing, have actually removed more useful features than they have added and fail to be a compelling upgrade on their own.
So, instead of making anything better, they focus on destroying what already exists.
> I've never understood why the presence of Wayland means X.Org needs to disappear
It doesn't, except for a few annoying facts:
* Most of the people who maintained X.org are sick and tired of it, have moved on to Wayland (or completely unrelated) work.
* No one has stepped up to work on the non-XWayland parts of X.org to the level that's needed to describe it as more than just in maintenance mode.
* Popular GUI toolkits seem to be moving on. GTK, for example, still accepts bug fixes for the X11 backend, but they aren't really working on it. I expect at whatever point maintaining the X11 backend and keeping it up with core changes becomes too big a burden, they'll drop it entirely. I don't know what Qt's stance is, but I wouldn't be surprised if momentum has or will move more toward their Wayland backend.
The end result here is that X.org eventually will be the less-stable, less-featureful platform. It's going to take a while to get to that point (Wayland clearly still has a ways to go), but it feels inevitable, unless some interested parties decide to step up to maintain the non-XWayland parts of X.org and the X11 backends of the popular GUI toolkits.
> I've never understood why the presence of Wayland means X.Org needs to disappear
Same.
I'm on Wayland right now and I already know the next installation will run X11.
Nothing against Wayland but so far all functional differences I noticed were things that don't work anymore.
I don't expect everything to work exactly the way it was previously, but nonexistent alternatives for X11 tools are a dealbreaker for me.
I had the same issues. I try Wayland whenever I end up with a new machine or do a reinstall for whatever reason. It felt like death by a thousand cuts just small things like inconsistent drag and drop behaviour, the primary clipboard working in some places and not in others etc.
Things that are just ingrained in my daily use being inconsistent or broken ever so slightly just become intolerable even after a few days of tweaking and tracking down 5 year old bug reports with no action.
I might have a better time using one of the big 2 DEs but (using KDE on a Surface Pro with Wayland has been fine) but i3/Sway are my preferred WMs and I'm not giving them up.
> Although, I've never understood why the presence of Wayland means X.Org needs to disappear.
Because it takes time, money, and effort to keep it around. Literally everyone who knows anything about the Linux graphics stack agrees that Wayland is the superior approach. So rather than maintain one code path for a superior graphics stack that actually enables a competitive desktop environment and another code path for yesteryear's graphics stack that only caters to a bunch of old grognards who fear change, the project maintainers just said fuck the grognards, the wasted effort supporting them is holding the Linux desktop back. The situation has gotten so bad that the Asahi Linux kernel's video driver attempts to detect if it's being accessed by an X server and refuses to work if it is; Wayland is the ONLY supported path by the Asahi project.
Sorry, X11 has got to die -- because the grognards have supplied nothing but endless whining about the Wayland situation instead of putting in the work necessary to keep it alive. You want to keep it around for your niche use case? Maintain it yourself, or hire someone else to. Just don't expect support from the major distributions, GUI tool kits, or application projects -- or kernel drivers.
For a very simple reason: developers don't want to support multiple backends for their app, and end users don't want to install two different windowing systems to support different apps that made different choices.
The situation on Linux is already pretty bad w.r.t. having to install multiple big frameworks, with some apps assuming Gnome and others KDE. Imagine GTK chose to move to Wayland, but Qt chose to stick to X - you would probably end up with 4 different combos on many systems to support all expectations.
> For a very simple reason: developers don't want to support multiple backends for their app
Yeah, that is why in my code i don't bother with Wayland and just stick with X11 :-P (though things largely work on Wayland via XWayland, aside from a few things like some code i wrote that resets the mouse cursor position manually to allow for scrolling/panning/rotating without being limited by where the cursor is - well, under Wayland this limitation will exist, but it is a minor one).
When in reality they just went "oh hey, double struck mathematical operators? Cool", typed "&1D54F;"[1], scrolled through their font picker, and then sent the invoice.
Presumably, Elon Musk did it himself. Which isn't hard to believe considering his fascination for the letter "X" and that it is a common Unicode symbol.
The story doesn't tell if he paid himself to do that.
I think it's a joke on the claim that Twitter would become an 'everything app' when it became X. The software X11, being a windowing system, actually is a system for running 'every app', in a way.
Maybe they were joking comparing the logo flip with the way X flips the regular notion of client and server (you run the X server on your machine, and you connect the remote app as a client).
I learned C++ with GCC cli in Linux in high school 2007, in Kerala, India. My college had Sun thin client desktop with an extremely outdated GCC so I was helping when teachers were stuck helping. Our college system is such that you take a fixed syllabus for 4 years so people get daunted at first programming subject and nurse their coping mechanisms for 3 years.
Lack of standards compliance, bugs, and generally unhelpful compilation error reporting. It was a nightmare for the OOP class, which used more compiler features. Couple that with undergraduate sophomores and juniors trying to do things at the last moment, and you'll have a lot of former CS majors.
"we need no permission" - duh, it's an FOSS project that nobody has to use. Distro maintainers have chosen to use it because it has a significant number of advantages over SysV init scripts and the rest.
Don't like systemd? Use another init! Use another distro! Use Arch or any one of the distros that makes it very easy to choose your own components. Or... roll your own distro!
People just like to continue beating a dead horse for no reason.
This is why "The Year of the Linux Desktop Is Just a Year Away!". People belly ache about anything modern... and stunt development for their niche requirements.
As I said, you need to dig my comment history for that, because I have no time to rewrite everything I said over and over again.
Distribution politics is something I’m familiar with enough, and I’m well versed enough in UNIX philosophy and how bending it creates problems (which systemd has gone through, and painfully learnt it again).
Another reason that I’m not writing a wall of text is I like horses and not prefer beating them regardless of they are alive or not.
However, if it comes to that, I can roll my own distribution, which I did in a professional capacity before.
Paralel Sys-V (with dependencies), Mudur and upstart was not slower than systemd, and we were already able to do everything systemd was doing. That’s still true.
I’m using systemd on a thousand machines every day, and yes, it has improved, but it’s neither perfect, nor indispensable, yet developers prefer to lock themselves into it.
Lastly, free software moves with respect to each other, not by “moving fast and breaking things because feeling like it”. Systemd became better because they had to accept that they can’t bend everything the way they want. Systemd doesn’t live in a vacuum and doesn’t have the luxury and authority to break and build things as they wish and expect everyone adapt to them and worship them as demigods.
Your sentiment is ridiculous. If Upstart, Mudur or name any of the other many init's were better or became better, distro maintainers would switch. They are some of the most pragmatic people.
Politics did not insert systemd into all of your widely-used distros... merit did. Even if that merit isn't what you wanted for your niche requirements.
systemd came late to the next-gen init debate and ate everyone else's lunch.
Now, the bar is high to replace init's again - meaning the next init system will need to be a leap forward instead of marginal/niche improvements.
> I’m using systemd on a thousand machines every day
You are a niche user and have niche requirements. Understand that...
One of the primary reasons Debian even considered systemd, was because Redhat's control of the Gnome foundation, and thus Gnome's at the time requirement of systemd as an init, created a major conflict in terms of "do we drop gnome or not".
If you want you can read the proposals, the mailing list discussions, the debates, the votes. There's nothing opaque or hidden here. If you haven't done so, then I suggest you do so, instead of disparaging someone who lived through the debates, read the list daily, and partook in the process.
> Systemd was adopted by redhat because it is their baby
You mean after shipping Upstart in RHEL 6 and immediately regretting it?
> And because redhat controls gnome, gnome created a hard depend upon systemd.
This is some revisionist history right there. Red Hat contributes money to GNOME, along with a lot of other organizations. GNOME is not even close to being the only DE either... are you asserting some sort of evil conspiracy to adopt systemd for profit or something? That is absurd...
> ...are you asserting some sort of evil conspiracy to adopt systemd for profit or something?
Why does it have to be an evil conspiracy? Corporations pay folks to work on these things.
Based on my personal experience: Corporations have things like OKRs and performance reviews and the like. Managers in such companies (at all levels) tend to have a hard time understanding what their people work on and whether or not it was actually important and/or useful. This leads to managers getting seduced by things that are easy to fit stories to... Bold Mission Statements and Grand Visions.
One great story is how you're "Revolutionizing Computing and Paving The Way To The Future With Cutting-Edge Technology".
Another great story is how you're "Accelerating the Desktop Through Tighter Integration With Cutting Edge Components".
Absent highly-clued-in managers who have enough slack time to figure out how useful the things you've been doing are, great stories get you more money, accolades and promotions than folks who don't have great stories. Simple as.
No conspiracy needed. It's just a bunch of folks following "incentive gradients" that don't result in optimal outcomes for the unpaid folks who work on and/or use the product.
You mean they don't officially provide support for them, even though you can choose to use a wide variety of init's.
Regardless, there are other distros that don't use systemd by default. Choose one of those if you have it in your head systemd is causing you some sort of pain (it isn't...).
- Mysterious PID1 crash related to timedatectl, resolved by replacing /etc/localtime with a regular file instead of symlink (to a file on same FS). How do you strace PID1 to get some idea what's going on? You don't. Good thing timezone management needs to be part of init!
And those are just the two that I've had to spend hours on in the past few years.
Not using systemd is barely a choice, even if you don't use systemd itself you nearly have to use things which are designed in exactly the same bad ways (polkit, systemd-udevd), there are several (negative) changes which even systemd-resistant distros have adopted for conformity which were first driven by systemd, lots of software has completely removed their provided init-scripts and replaced them with systemd unit files only so you have to write your own or go dig it up from the git history...
Oh and it's extremely brittle and one little piece breaking means you can't boot at all, not even in single user, since everything is jammed into PID1... so good luck even examining what's going on.
I could go on but of course you've already seen and chosen to ignore any argument I could make, because this dead horse has indeed been beaten, by the people who constantly ask "what's wrong with it" when many, many answers are a simple Google away.
It just werks 99% of the time. The few problems it brings are for the most part basically just annoyances for people used to working with something else.
That's exactly the point. It's so complex that it's impossible to track down (and thus fix) the cause of any of its problems. What works for you does not work for someone else, and vice versa, because of some seemingly unrelated difference in how their system was built or configured (usually by their distro, often even as a result of difference between upgrade-vs-fresh install).
As a guy who has been running Unix machines since the early 1990s, including pre-1.0 Linux kernels, SVR4.x , Sony NEWS and Sun machines... I have stopped hating systemd.
Since I no longer install an OS, if it uses systemd :-)
I wonder if 40 years ago people got as bent out of shape about X as they do now about systemd and find one reason or another why it didn't fit the "unix philosophy".
X has long had critics from Unix fans. There’s an entire chapter devoted to X in The UNIX Hater’s Handbook, and the author of that chapter, Don Hopkins, is a major advocate of Sun NeWS. On the Unix side of things, alternatives to X included Sun NeWS and NeXT’s desktop, which are both Display PostScript-based systems. macOS uses Quartz, which is similar to Display Postscript but uses PDF-based objects instead of interpreting PostScript code for rendering graphics. There are also 8 1/2 and its successor rio from Plan 9, which also addressed issues that the Plan 9 developers had with X.
Of course, X won out over all these systems; while X has been MIT-licensed since its early days, none of X’s competitors were open source at the time of their release. NeWS, NeXT’s display system, and Quartz remain closed source, and while Plan 9 was released under an OSI-compatible license in 2002, it wasn’t GPL-compatible; this was rectified in 2014 when Plan 9 was GPL’d, and the licensing became even more liberal in 2021 when it became MIT-licensed.
Quartz isn't really similar to Display PostScript. Vector drawing is done client-side and isn't proxied out to the window server like NeWS and NeXT did. Sure, you can use Quartz to draw to a PDF, but you can do that in Cairo too.
I wish I'd been paying attention while the Systemd Cabal (their phrase, not mine) was canvassing and proselytizing... I had a lot of free time back then and could have spent some of it putting the vast majority of the "missing" features from openrc.
It's somewhat unfortunate that the switch to systemd killed the debian-on-FreeBSD project. Had they chosen openrc, that project would have been able to continue.
S6 is pretty good yes and their developer was looking for sponsorship to develop a full service manager based on it. Don't think he ever got it though.
https://lists.x.org/archives/xorg-devel/2024-February/thread...