> But I think it's reasonably clear that I wasn't saying they were trying to build a moat around desktop linux, but around those enterprise offerings. One part of that is making their init system the defacto standard.
Frankly, no, it was not, or I wouldn't have written that. Those "enterprise offerings" have zero interaction with Pulse outside of some edge cases in SPICE for VDI.
The only "moat" that "they" were building (and by "they", you mean "individual contributors who happened to have a @redhat.com email address") was in making desktop Linux usable enough for their engineers to work on it day-to-day.
As I said elsewhere, RHEL6 used upstart. "They" made "their" init system the defacto standard by using upstart, finding a metric ton of things wrong with it (and upstart was used in the first place because maintaining complex sysvinit scripts and day 2 operations in horizontally scaling applications was such a nightmare that it was worth throwing away all of the accumulated man hours in those scripts), and writing something better.
Nobody forced the Debian steering committee, Arch, Gentoo, Slack, or anybody else to default to systemd.
> I don't think I can get into it without being rude, but I think that hasn't born out history. If an outsider does submit patches to scratch their own itch they can expect to at best be held to a much higher standard and at worst be treated quite rudely. I recognize that that's going to be subjective but there's definitely some bad blood between gnome and many third parties. Look at lxqt/lxde, appindicators, etc.
GNOME is what it is, and they had that reputation before Pulse.
We shouldn't conflate Pulse and systemd just because they were both Lennart any more than you conflate selinux and podman because they're both Dan Walsh.
This perception also grossly misrepresents or misunderstands open source. If an outsider does submit patches where? Which one of the 600 different projects are they submitting to? How many of them do you presume are controlled by black-robed @redhat maintainers?
OpenSSL, Apache/httpd, coreutils, glibc, and a bunch of other core projects have so few maintainers/contributors that we're lucky they move at all. There is not some "Linux@redhat" repo which it all goes to where patches from outsiders get gated. Open source is a reputation-based community. If a @redhat.com email happens to be a maintainer of a widely-used project, it is, broadly, because they earned it through contributions like anybody else.
Maintainers, once they get there, do tend to get less rigorous code review. That's true. But nobody hands you maintainer rights along with your badge, and the perception that things work this way is untrue both historically and today.
That being said there is a bit of hard data, this post nicely shows gnome contributions over time, as less and less non-redhat developer contribute.
https://hpjansson.org/blag/2020/12/16/on-the-graying-of-gnom...
Now I'm sure you have a dozen explanations lined up for why that might be the case, most of them involving how good redhat is and how they're a bastion of light all that, which sure I have no way to definitively prove that there's any malfeasance going on.
Still, I think it's clear that at the very least gnome has a bit of an image problem going on. Where we're not debating any kind of concrete facts as just shouting our subjective opinions of who's the asshole at each other, well I don't expect us to come to any sort of an understanding.
I don't think we'll reach any real agreements either, but I also don't think it's all that subjective. We could say my perspective is skewed from being "behind the curtain" for a decade, but it's equally true that I'm dramatically more informed about the economics and realities of open source contributions due to it.
Redhat was (and likely still is) a collection of engineers who are passionate about open source, and get paid to work on it. For a long, long time Redhat paid below the market average. It was not a place you went right out of college. It was a place where people who really gave a damn about open source went because the money was enough, and they got to work on something they felt was actually making software better.
It wasn't some corporate machine, it wasn't particularly profit-driven, and it definitely wasn't somewhere where the engineers wanted to push some corporate vision of how Linux should be. As of maybe 2017 or 2018, we started hiring more "new grads" and pivoting more to cloud workloads (outside of what Openstack already had), but the fundamentals didn't really change.
The perception of what Redhat is/was and what they actually were/are? is very different. It wasn't a perfect place, and the best ideas didn't always win, but at least you always felt like you could voice them, and you never felt like you were railroading a project to build a "moat" around some business model. Good projects got a lot of developer/admin/ops mindshare, and those dominated the market, so you should write good software which people will like/use. It wasn't complex.
One of the things which I miss the most (outside of being surrounded by people who were passionate about software ethics) is QA -- Redhat's QA is, in no small part, what has kept software quality high.
> That being said there is a bit of hard data, this post nicely shows gnome contributions over time, as less and less non-redhat developer contribute.
> https://hpjansson.org/blag/2020/12/16/on-the-graying-of-gnom...
> Now I'm sure you have a dozen explanations lined up for why that might be the case, most of them involving how good redhat is and how they're a bastion of light all that, which sure I have no way to definitively prove that there's any malfeasance going on.
Try not to turn people into strawmen.
The likely explanation is that GNOME has gotten much more complex and harder to contribute to, and the divide for new contributors to meaningfully fix bugs or add features has gotten wider as GNOME3 has stabilized (and bloated a bit). There's a clear pike just before 3.0, and it kinda declines after that, but some of the other major contributors (Ximian, Collabora, arguably Sun) aren't players anymore.
The other missing piece of data here is that, outside of the kernel (which gets a ton of contributions from hardware vendors submitting code to support their own stuff), you'd find the contribution ratio to be shockingly similar. glibc, openssl, and a number of other core projects are also more Redhat than not.
That doesn't mean they're trying to control the ecosystem. It means that, yes, it contributes to the company's bottom line, but you shouldn't assume that the contributions have a motive any more sinister than any other contributor.
GNOME's image problem is the same as GNOME's image problem always was, but we really haven't been talking about that. I'm not trying to defend Redhat or call you an asshole, but the amount of commits Redhat makes to open source projects all over is not subjective, that they get those commits upstreamed into projects they do not control is not subjective, etc.
Don't let your personal opinion about Lennart color what Redhat engineers do for open source or to paint all of them with the same "corporate peon building a 'moat' brush" (which also doesn't describe Lennart).
You don't agree with some of the decisions the communities made. That's fine. That's open source, too. It doesn't mean that you're right and Redhat is some Benedict Arnold scheming for control.
As an aside, part of my frustration with talking to you is that specific problem. You're very early to dismiss complaints with things like
> (me) If an outsider does submit patches to scratch their own itch they can expect to at best be held to a much higher standard and at worst be treated quite rudely.
>> (you) This perception also grossly misrepresents or misunderstands open source.
Now I can point to at least a few instances of that happening, but I know from experience that the goalposts will likely move again. I can point to a well respected SDL developer saying "this architecture is not how anything else works and will cause significant issues for the SDL project, and therefor many games on linux" and a gnome developer saying "Fix the applications and libraries that claim the support Wayland, but don't do it properly.". Now even if they were right on a technical level (they weren't) that's no way to talk to your fellow open-source developers who were being very polite and explaining why the proposed architecture wouldn't work.
For that particular issue at some point gnome developers did step back and implement CSD.
But regardless, "this perception also grossly misrepresents or misunderstands open source" is completely out of line and where I decided you weren't worth talking to. I can point to multiple specific instances where gnome developers were rude, unhelpful, arrogant, etc, but I'd rather not drag into that. Like I say it gets insulting very quickly. The simple fact is that their reputation for being assholes is, on the whole, earned. I'm sure there are specific cases where it doesn't happen but assholery seems to be endemic to the entire organization.
If you want specific documentation on times systemd has caused significant issues (not counting the pwnies that are well documented) I've started documenting my experiences here (unpublished, and something that I'm unlikely to ever publish): https://traverseda.github.io/scratchpad/systemd.md.html
Or see this article here: https://igurublog.wordpress.com/2012/11/05/gnome-et-al-rotti...
Or this rather infamous interaction: https://trac.transmissionbt.com/ticket/3685
At some point I suppose I'll get around to documenting the times gnome developers were publicly assholes to other open source contributors, but honestly I'd rather let it go and just ignore the whole project as much as I'm able to.
I too can point to multiple specific instances where Linux developers were rude, or where gcc developers were rude, or where SDL developers were rude, or where a lot of other developers were rude. I bet someone could dig through your comment history and find instances where you were rude and unhelpful too, probably even more if you shared any comments from when you were a young teenager. I hope you can see that it is completely ridiculous (and somewhat creepy) for someone to do that to you. Open source programmers just disagree sometimes, and sometimes they have a bad day and aren't totally professional about it, and in larger projects it is a lot more visible than on smaller ones. All you can ask of them is for an apology and then move on. It is unreasonable to expect anything else or to keep harping on this years after the fact.
Also it is completely ridiculous that this thread is getting derailed again into complaints about missing features in GNOME. Lennart isn't a GNOME contributor, I don't think he has written any significant code for GNOME at all. The fact that nonsense conflation is being used should be a "snap back to reality" moment. Just don't do it. This always seems to happen and it's always from the same suspects trying to revive the same old >=10 year old forum threads. Please give it a rest and try to do something positive instead, don't let the lwn trolls get inside your head. You are generalizing an entire group of people based on some cherry picked interactions that both of us likely lack the context to fully understand, unless you were "behind the curtain" like the parent comment actually was. If you weren't, then it is just another tone policing comment from the peanut gallery, the kind you probably would find to be bad if they were made from random users on your projects.
>At some point I suppose I'll get around to documenting the times gnome developers were publicly assholes to other open source contributors, but honestly I'd rather let it go and just ignore the whole project as much as I'm able to.
Letting it go is probably the right choice. If you want to revisit it, I have a suggestion: why don't you go through and publicly document all the times they did something right or the times they were nice to people, and then praise them for that and encourage them to do more of that. Surely you understand that it is not useful to keep beating a horse that died long ago. Just focus on the positive, if the worst thing they did is send some slightly unprofessional email 5-10 years ago (as if most open source developers in the 1990s-2000s didn't do that at some point, I think I lost count of the number of flamewars I read from that period) then it really should not be hard to find some examples of good.
I think that has something to do with redhat defenders/employees needing to nitpick every little issue that anyone has in a public forum. The inability to just say "oh well that's bad but we're working on it" and instead try to mitigate or distract from any legitimate issues. Any discussion about this issues always turns into the same sprawling discussion where I'm asked to prove a bunch of subjective things. I try to illustrate that third parties have issues with redhat engineers and submitting patches. I back that up by showing that the developers of lxde, transmission, and SDL, have all had significant issues with the gnome development team (mostly redhat), and I'm told it's creepy to point that out. But those are some of the cases that gave redhat this reputation.
You can't have a negative opinion about redhat/gnome without a bunch of people crawling out of the woodwork to nitpick and force you to justify every negative opinion to absurd amounts. Most of those people aren't just regular users, they are or were directly involved with redhad or gnome. It's impossible to have a straightforward debate, it will get derailed into a bunch of minutia.
My main complaint is that redhat encourages tighter coupling between their components that I think is reasonable, that's what I said in the root comment and I stand by it. The fact that I'm not debating a bunch of minutia with a bunch of redhat fandboys is frankly endemic to the problem.
Tell me, have you been paid to work on systemd/gnome/redhat in the past?
Yes, I think it is creepy. Don't you think it would be creepy if someone was in a completely different thread in a conversation with someone else who had nothing to do you or with your decisions, started going through your 10 year old comments looking for disagreeable things, and using them as an excuse to discredit everything that you might have been slightly involved with? This person isn't a GNOME developer and he doesn't even work for Red Hat anymore.
>It's impossible to have a straightforward debate, it will get derailed into a bunch of minutia.
Please don't try to make this into a debate. This is not a constructive way to approach anything. If you look at this conversation as something you need to "win" then that would be the core of the problem. It is perfectly fine to express a negative opinion, but what is not okay is when you start saying things along the lines of "I am going to prove all the developers of XYZ are permanent irredeemable assholes". That is just furthering the flamewar, it's not moving past it into the actual issues.
>Tell me, have you been paid to work on systemd/gnome/redhat in the past?
No. This also is a somewhat trollish question that is unnecessarily making things personal and leans on a stereotype, in the future you shouldn't lead a conversation with questions like this. In particular, people can change their mind on all those things despite being paid in the past, or could be paid and still have a bad opinion of them, or could not be paid but still have a good opinion, or any number of other things that are outside the preconceived notions. A much better and friendlier way to phrase this would be something like "What is your experience with these projects/developers/companies?" Then the other person can divulge their employment status at those companies at their own accord, if they have a positive view of the employment then they probably will.
>Sure, you can pipe journalctl into grep, but what if you want to use inotify, or tail a log, or expose logs over a network share? Well you have to learn the systemd-specific solution, instead of just using the tools that work with every other file.
This is absolutely not different from any other tools to manage structured data, like any database. I don't see anyone complaining that postgresql doesn't follow the unix philosophy. Logs are actually structured data, any adherence to a philosophy cannot change that fact. Actually a lot of those "standard" unix tools specifically exist to parse unstructured data into structured data, so from that perspective, having the format already in a structured data format is only there to save you some typing.
>I could complain about service files being spread all over the file tree, instead of in one central obvious place, but as I understand it systemd has some reason why that's better for them and that's fine.
The reason is straightforward. /run/ is for temporary services. /lib/ is for immutable service files shipped by the OS or by programs. /etc/ is for service files defined by admin configuration. /home/ is for service files defined by user configuration. This is all standard filesystem stuff that systemd is following. Actually, it is the old-style inits that break convention by putting everything in /etc, causing bugs in the process. The package manager should not install files to this folder that are not intended to be modified, doing so is sure to cause things to break whenever you upgrade a package. What seems like a "simple" solution in this case is actually too simple to the point of being broken.
>Unfortunatly the built-in OS image was not running systemd, and the kernal was several revisions out of date. While I had no problem getting a debian chroot running, all of the services were designed to run under systemd, this made the whole project much more of a pain in the ass than it should have been.
Well I don't see what this has to do with systemd, this would happen if you want to use any program or driver that depends on a new kernel version. Systemd cannot really do anything to solve the fragmentation caused by embedded devices running ancient kernel versions, that is very much a Linux-as-a-whole problem.
>I took the boot media out for trouble shooting, but when I systemd-nspawned into the host to try to address the problem, I discovered that journalctl would segault. Thankfully /var/log still had all the entries I needed to fix the problem. This appeared to be a general issue with running journalctl using qemu-static and binfmt.
A segfault sounds like an actual unintended bug that should be reported.
>By default systemd will kill long-running processes when I log out. Processes like screen or tmux.
Nit pick: this is not systemd doing this, but logind.
>The intentional and willful breaking of screen and tmux was to fix a GNOME bug of GNOME not closing up as it should when the user logs out
No, this is extremely wrong. GNOME cannot actually do anything about this, if a random nohup processes decides it is going to try to keep itself open.
>There's now no way to, by default, keep a program running in the background without a live ssh session.
The default is a flag in the config file that distros get to decide. There is nothing else they can do to accommodate you here, besides do what they already have done.
>For some reason my mother's computer can no longer resolve DNS. Ripping out systemd-resolved seemes to have fixed it, but note before I lost a few more hours.
>I used to think the systemd hate was silly... until I tried to get a VPN running and realized that all my DNS requests were going through a mysterious local DNS server
Unclear what is going on here without additional info. Copying more random comments that say vague things like "it doesn't work" is not really useful or meaningful to anyone. You could fill an entire book of comments like that made about everything in Linux over the years. It might be humorous, or interesting for historical purposes, but it won't help get any outstanding issues fixed.
>It is getting paid to help companies make Linux work for them
There's an obvious joke there :p
But I think it's reasonably clear that I wasn't saying they were trying to build a moat around desktop linux, but around those enterprise offerings. One part of that is making their init system the defacto standard.
>The only reason why there's a perception that "non-Red Hat stakeholders didn't matter" is because the vast majority of community users weren't submitting patches
I don't think I can get into it without being rude, but I think that hasn't born out history. If an outsider does submit patches to scratch their own itch they can expect to at best be held to a much higher standard and at worst be treated quite rudely. I recognize that that's going to be subjective but there's definitely some bad blood between gnome and many third parties. Look at lxqt/lxde, appindicators, etc.