Anti Leonard Poettering petition: Stop writing useless linux programs.(change.org)
change.org
Anti Leonard Poettering petition: Stop writing useless linux programs.
https://www.change.org/petitions/lennart-poettering-stop-writing-useless-programs-systemd-journal
9 comments
The "Cascade of Attention Deficit Teenagers" model ...
http://www.jwz.org/doc/cadt.html
> Except for heroic efforts by Red Hat, SUSE, and previously Sun, it's mostly a hobbyist affair.
Lennart Poettering is a Red Hat employee.
Lennart Poettering is a Red Hat employee.
And some argue that this is the only reason why these things actually make it into the Linux desktop ecosystem. If he wasn't a Red Hat employee would they ever make it into a distribution?
> On a personal note, the effort required to maintain a stable Linux desktop made me switch to OS X in 2007, after using Linux for 13 years.
To each his own. For me it's much better than Windows and GNOME attempting to copy OSX features has made it much worse. I'm not certainly not switching to OSX ever.
To each his own. For me it's much better than Windows and GNOME attempting to copy OSX features has made it much worse. I'm not certainly not switching to OSX ever.
I think"attempting to copy" is the operative phrase there.
The failure of Linux as a commercial desktop is also (not entirely, of course) his responsibility, considering the crap he pulled with all the desktop components he messed with (PulseAudio, HAL, DBUS etc etc), so clearly it's not a causal factor for his behaviour.
I think the 'failure' of the commercial Linux desktop can mostly be attributed to economics. Most importantly, consumers do not want to pay for a desktop operating system (even if it were proprietary). Microsoft effectively shut down the alternative market by making Windows-hardware coupling mandatory for large hardware vendors. This gives the perception (through scale and coupling) that Windows is nearly free. So, why would one spend money on an alternative operating system?
Then, there are social factors. A vocal minority of the Linux community is outright hostile towards proprietary software or even towards any form of capitalism. It is not a very attractive market to operate in - one misstep, and elaborate PR campaigns are set up.
Then, there are social factors. A vocal minority of the Linux community is outright hostile towards proprietary software or even towards any form of capitalism. It is not a very attractive market to operate in - one misstep, and elaborate PR campaigns are set up.
"Microsoft effectively shut down the alternative market by making Windows-hardware coupling mandatory for large hardware vendors."
How did they do that, how?!
That is exactly why GNU/Linux on the desktop isnt used by more people.
How did they do that, how?!
That is exactly why GNU/Linux on the desktop isnt used by more people.
from http://en.wikipedia.org/wiki/Criticism_of_Microsoft#Licensin...
The Findings of Fact in the United States Microsoft antitrust case established that "One of the ways Microsoft combats piracy is by advising OEMs that they will be charged a higher price for Windows unless they drastically limit the number of PCs that they sell without an operating system pre-installed. In 1998, all major OEMs agreed to this restriction."[30] This has been called the "Windows tax" or "Microsoft tax".[31][32]
The Findings of Fact in the United States Microsoft antitrust case established that "One of the ways Microsoft combats piracy is by advising OEMs that they will be charged a higher price for Windows unless they drastically limit the number of PCs that they sell without an operating system pre-installed. In 1998, all major OEMs agreed to this restriction."[30] This has been called the "Windows tax" or "Microsoft tax".[31][32]
monopolistic behaviour and a solid, conservative set of well-documented APIs.
Why would a hardware vendor care about APIs or monopolistic behaviour?
Why would a hardware vendor make a deal which said vendor can only use this software on the hardware they make but not other?
Why would a hardware vendor make a deal which said vendor can only use this software on the hardware they make but not other?
Unless I am misunderstanding you, your second question makes it appear that you didn't read the material cited in spot's response to your earlier post. If I'm wrong, could you perhaps rephrase your question?
[deleted]
He is responsible for distributions choosing to use his software?
Linux user since 1999, redhat 6.2 days I think, kernel 2.2. Messed with getting audio to work on an old ISA card, setting some ports in some config files, recompiling the kernel. I got it working, no big deal, even from several sources at the same time, with no artsD or esd, but I did try those to just for fun.
Invested same amount of time and effort, still have only horrible memories of pulseaudio. I shiver anytime I see puslea. Argh.arhgh.why,.asdhj as.
Invested same amount of time and effort, still have only horrible memories of pulseaudio. I shiver anytime I see puslea. Argh.arhgh.why,.asdhj as.
> On a personal note, the effort required to maintain a stable Linux desktop made me switch to OS X in 2007, after using Linux for 13 years.
I did the exact same thing (except in early 2008 - been using Linux since 1995), for the exact same reasons. A Kubuntu upgrade breaking my mouse config was the last straw.
I did the exact same thing (except in early 2008 - been using Linux since 1995), for the exact same reasons. A Kubuntu upgrade breaking my mouse config was the last straw.
> the effort required to maintain a stable Linux desktop made me switch to OS X in 2007
I remember it was complicated in 2002. In 2007 it was already at the "mostly works" stage.
I remember it was complicated in 2002. In 2007 it was already at the "mostly works" stage.
It was even more complicated in 1994. But, throughout high school and university I had plenty of time, and fixing things was an interesting challenge.
Then real-life started (internships, thesis writing, a day job), and the few hours per day that are left, you'd rather spend with loved ones, sports, and interesting projects. And then you suddenly realize that you'd rather have "works" than "mostly works".
YMMV
Then real-life started (internships, thesis writing, a day job), and the few hours per day that are left, you'd rather spend with loved ones, sports, and interesting projects. And then you suddenly realize that you'd rather have "works" than "mostly works".
YMMV
"Mostly" is not enough when it's not a hobby. It needs to "just work". Of course other OS'es aren't at 100% in that regard either, but at least they don't break stuff that used to work so often. I've used Linux since late 1990's into 2005-2007 or so, after that only revisiting it every now and then to see if things have improved. They have, but not enough. And the curve is only getting flatter, especially with much/most of the crowd that used Linux because it wasn't Microsoft moving to Macs over the last 5 years.
I started using Linux in 2001 and can agree with you that things were a bit messy up until 2005 or so. In my experience, I had very little problems since then, the only major frustration was Compiz not working on a cheap notebook that had 3D acceleration but no Linux support for it. Since then, everything just works, provided I don't sabotage myself buying hardware I know won't work properly.
I've also been a Mac user since the late 90's and I have a very solid experience with OSX since 10.2. It's not as flexible as Linux or FreeBSD, but, for a consumer-grade experience, it's excellent. I find the hardware choices somewhat limiting, but that's me. For work, I prefer Linux for its flexibility and, like I said before, I can't remember the last time my machine stopped working.
I've also been a Mac user since the late 90's and I have a very solid experience with OSX since 10.2. It's not as flexible as Linux or FreeBSD, but, for a consumer-grade experience, it's excellent. I find the hardware choices somewhat limiting, but that's me. For work, I prefer Linux for its flexibility and, like I said before, I can't remember the last time my machine stopped working.
I think blaming someone for innovating is possibly the stupidest thing one could do.
dbus is awesome. Best bus we have.
systemd is really nice and useful, overall a better upstart. The reason it's not a patch for upstart or sysinit is that their designs preclude certain features that systemd provides.
I don't know about pulseaudio, and I'm not sold on Journal.
dbus is awesome. Best bus we have.
systemd is really nice and useful, overall a better upstart. The reason it's not a patch for upstart or sysinit is that their designs preclude certain features that systemd provides.
I don't know about pulseaudio, and I'm not sold on Journal.
systemd doesn't appear to solve a problem, it seems to just add a layer of indirection and complication, as well as a single point of failure for ALL system startup services, rather than letting each service just handle it's own deal.
`init` already exists to kick things off properly - now init just runs systemd which then kicks things off, for no appreciable gain.
`init` already exists to kick things off properly - now init just runs systemd which then kicks things off, for no appreciable gain.
Seriously, do you even know what you're talking about? init does not start systemd at all. systemd replaces init, in a way that I can even select whether I want to use the traditional init or systemd, on boot time, with a kernel option.
And have you seen proper systemd integration? I installed Fedora lately, and man, that boots fast. Fedora solves so many things in a sane way that Ubuntu has been struggling since years. usplash, xsplash, splashy? Fedora has FDO's plymouth. Guess what, it works. SYS V init, the stupid Arch init, ubuntus upstart? Fedora has FDO's systemd, and it's faster than any of those.
And have you seen proper systemd integration? I installed Fedora lately, and man, that boots fast. Fedora solves so many things in a sane way that Ubuntu has been struggling since years. usplash, xsplash, splashy? Fedora has FDO's plymouth. Guess what, it works. SYS V init, the stupid Arch init, ubuntus upstart? Fedora has FDO's systemd, and it's faster than any of those.
You're right, I misunderstood the integration.
It still seems like it's optimizing for the wrong thing for the vast majority of linux users. The # of linux servers, which don't care about boot time (or where software init is a very tiny part of boot time anyway) is way larger than the number of people using it as a desktop. Boot time isn't the thing that's keeping linux off the desktop.
Rewriting scripts and rolling them into a C daemon defeats the whole point of scripts in the first place - the administrator of the system can't make quick changes or easily troubleshoot things (or, optionally, selectively enable/disable small sections of initialization). It's also a large amount of new work for folks busy fixing actual broken or buggy parts of their software.
Lennart complains that the starting PID on his linux desktop is too high, because init scripts call 'grep', 'awk', etc. - and that developers should rewrite all of that into their own startup daemons. It seems like he's complaining about the 'UNIX way' of small, text-oriented tools each doing one job and piping the results between them for flexibility and power for the the system administrator. Moving all of that into a C-based daemon, hiding it entirely from the administrator (short of a unsupported-by-your-contract recompile and source mod) doesn't seem like a net win for me, especially for a few seconds saved two or three times a year.
Most scary is the way he wants to handle socket based services - it's already the source of one remote DOS against a machine running systemd: https://bugzilla.redhat.com/show_bug.cgi?id=739538
It still seems like it's optimizing for the wrong thing for the vast majority of linux users. The # of linux servers, which don't care about boot time (or where software init is a very tiny part of boot time anyway) is way larger than the number of people using it as a desktop. Boot time isn't the thing that's keeping linux off the desktop.
Rewriting scripts and rolling them into a C daemon defeats the whole point of scripts in the first place - the administrator of the system can't make quick changes or easily troubleshoot things (or, optionally, selectively enable/disable small sections of initialization). It's also a large amount of new work for folks busy fixing actual broken or buggy parts of their software.
Lennart complains that the starting PID on his linux desktop is too high, because init scripts call 'grep', 'awk', etc. - and that developers should rewrite all of that into their own startup daemons. It seems like he's complaining about the 'UNIX way' of small, text-oriented tools each doing one job and piping the results between them for flexibility and power for the the system administrator. Moving all of that into a C-based daemon, hiding it entirely from the administrator (short of a unsupported-by-your-contract recompile and source mod) doesn't seem like a net win for me, especially for a few seconds saved two or three times a year.
Most scary is the way he wants to handle socket based services - it's already the source of one remote DOS against a machine running systemd: https://bugzilla.redhat.com/show_bug.cgi?id=739538
This isn't about boot time, that is just a nice side effect for desktop users.
This is about servers, and better ways to manage the services on them. A service shouldn't need to daemonize itself, and monitor it's own process via shell scripts and PID files. Having infrastructure to run services (as apposed to just starting them), monitor them, and resolve dependencies between them is a huge step forward.
(I also don't agree with the handling of socket-based service in systemd, but it's an experiment, and maybe I'm wrong, so its worth a try).
This is about servers, and better ways to manage the services on them. A service shouldn't need to daemonize itself, and monitor it's own process via shell scripts and PID files. Having infrastructure to run services (as apposed to just starting them), monitor them, and resolve dependencies between them is a huge step forward.
(I also don't agree with the handling of socket-based service in systemd, but it's an experiment, and maybe I'm wrong, so its worth a try).
> Rewriting scripts and rolling them into a C daemon defeats the whole point of scripts in the first place - the administrator of the system can't make quick changes or easily troubleshoot things (or, optionally, selectively enable/disable small sections of initialization). It's also a large amount of new work for folks busy fixing actual broken or buggy parts of their software.
Well, kinda. But I think this is somehow a weird point to take, considering that much other software is indeed written in C and noone complains about that (grep, awk). It is just that the bootscripts were scripts for a long time, but I think this does not mean that that it is an undefiable law. Plus, it is still open source, so if you want to change samething, just remcompile. As you would do with any other software.
And indeed, the "lower" level it gets, the lower level languages I'd accept there. Kernel in C, Bootscripts in Vala, and the desktop in JavaScript or Python, sounds quite reasonable to me.
And the socket based services are one interesting element. Whether it is a good solution time will tell, but I can't remember anyone trying this before and I applaud people to think in new ways. Yes, a DOS is not nice, I admit, but maybe we should give it a chance? Consider that systemd is still pretty new.
It saddens me sometimes that people dismiss ideas, just because they are different to what is now. One consideeable advantage that I see in systemd that it tries to be a solution for the majority of Linux distributions. I hate all the custom rolled init systems, I hate all that custom rolled network interface configuration, I will it all went away.
One single init adopted init system also means potentially more people fixing one single service file, so you don't have to. Instead of someone fixing just the Debian one, he also fixes it upstream so it can migrate to other systems.
Well, kinda. But I think this is somehow a weird point to take, considering that much other software is indeed written in C and noone complains about that (grep, awk). It is just that the bootscripts were scripts for a long time, but I think this does not mean that that it is an undefiable law. Plus, it is still open source, so if you want to change samething, just remcompile. As you would do with any other software.
And indeed, the "lower" level it gets, the lower level languages I'd accept there. Kernel in C, Bootscripts in Vala, and the desktop in JavaScript or Python, sounds quite reasonable to me.
And the socket based services are one interesting element. Whether it is a good solution time will tell, but I can't remember anyone trying this before and I applaud people to think in new ways. Yes, a DOS is not nice, I admit, but maybe we should give it a chance? Consider that systemd is still pretty new.
It saddens me sometimes that people dismiss ideas, just because they are different to what is now. One consideeable advantage that I see in systemd that it tries to be a solution for the majority of Linux distributions. I hate all the custom rolled init systems, I hate all that custom rolled network interface configuration, I will it all went away.
One single init adopted init system also means potentially more people fixing one single service file, so you don't have to. Instead of someone fixing just the Debian one, he also fixes it upstream so it can migrate to other systems.
> `init` already exists to kick things off properly - now init just runs systemd which then kicks things off, for no appreciable gain.
NO, systemd in an init replacement. Yes, init may get the job done, but it can be done so much better. Solaris dropped init years ago, but unfortunately licencing prevented their implementation from being ported to Linux distributions.
Upstart (by Canonical/Ubuntu) was the first major attempt in Linux, and has been running services in Ubuntu and Fedora for a few releases now. Lennart saw that upstart may not have gone far enough, and started his own implementation. Systemd may not be the panacea we want, but the it is on the right track for innovation, which we need.
NO, systemd in an init replacement. Yes, init may get the job done, but it can be done so much better. Solaris dropped init years ago, but unfortunately licencing prevented their implementation from being ported to Linux distributions.
Upstart (by Canonical/Ubuntu) was the first major attempt in Linux, and has been running services in Ubuntu and Fedora for a few releases now. Lennart saw that upstart may not have gone far enough, and started his own implementation. Systemd may not be the panacea we want, but the it is on the right track for innovation, which we need.
"You seem to know a lot of stuff about me. I am not particular fond of people who turn their dislike of software I wrote into personal accusations and judging in a public forum." - Lennart Poettering Sep 21, 2008 http://lwn.net/Articles/299615/
For what it's worth, 4 years on I still struggle daily with audio and only audio on Linux. I'm not in a position to tell if it's ALSA or PulseAudio that makes nothing come out unless I plug/unplug, mute/unmute in the correct order everytime I come back from suspend/open a different app/want to use headphones. But I didn't have these problems before Fedora 8 when I was using ESD ;)
And just recently I've resorted to manually starting couchdb in a console instead of using the init scripts on fedora because after upgrading to 15 they do some bad things to file permissions. Is it the distributors fault or is it systemd? Correlation does not imply causation?
For what it's worth, 4 years on I still struggle daily with audio and only audio on Linux. I'm not in a position to tell if it's ALSA or PulseAudio that makes nothing come out unless I plug/unplug, mute/unmute in the correct order everytime I come back from suspend/open a different app/want to use headphones. But I didn't have these problems before Fedora 8 when I was using ESD ;)
And just recently I've resorted to manually starting couchdb in a console instead of using the init scripts on fedora because after upgrading to 15 they do some bad things to file permissions. Is it the distributors fault or is it systemd? Correlation does not imply causation?
Why does nobody else create a better sound system?
Oh they do, all the time. OSS, ALSA, PulseAudio... http://xkcd.com/927/
ALSA already is the better sound system as long as you don't need all your applications to have one extra redundant volume control or playing audio on a remote computer over the internet. However de-pulsifying a linux install correctly isn't easy.
" or playing audio on a remote computer over the internet".
I thought thats the point of pulseaudio and really wanted to try it.
How can I say... it FAILS at even that! I got it working with ssh and mpd faster than... oh dont make remember.
I thought thats the point of pulseaudio and really wanted to try it.
How can I say... it FAILS at even that! I got it working with ssh and mpd faster than... oh dont make remember.
> " or playing audio on a remote computer over the internet".
>
> I thought thats the point of pulseaudio and really wanted to try it.
AFAIK (but I wasn't using linux at the time) the point of pulseaudio was that it was very easy for an application to lock your audio exclusively with ALSA or OSS (and still is unless ALSA is properly configured) and there were several competing "sound daemon" trying to solve this problem. Pulse audio was supposed to be the one true sound daemon, emulating everything else under the sun. Then it got sound mixing and networked audio bolted on because Poettering is the master of the kitchen sink.
AFAIK (but I wasn't using linux at the time) the point of pulseaudio was that it was very easy for an application to lock your audio exclusively with ALSA or OSS (and still is unless ALSA is properly configured) and there were several competing "sound daemon" trying to solve this problem. Pulse audio was supposed to be the one true sound daemon, emulating everything else under the sun. Then it got sound mixing and networked audio bolted on because Poettering is the master of the kitchen sink.
Honestly, I don't understand why move this personal attack against Lennart. From my point of view he just wrote pieces of software he deemed necessary. I would rather put the blame on distributions other than Fedora¹ for trying to integrate his stuff early and poorly (thus starting a chain-reaction which caused even more distributions to rush with integration attempts). I think he's getting a lot of flak for choices made by others.
_________
1: Fedora is known to ship with lots of experimental software/wide-scale changes. Its users expect breakage/major innovations from time to time.
_________
1: Fedora is known to ship with lots of experimental software/wide-scale changes. Its users expect breakage/major innovations from time to time.
He could have improved esd or jack. But no.
Sure he could, but things like that happen all the time. Countless people start forks and new projects every day, while they could improve the existing ones (the world is full of examples).
I have this darwinian vision of the software world where it's extremely positive to experiment with new stuff. Only time will tell which things surpass the test of time.
Attacking someone publicly this way just because he doesn't contribute to your¹ favorite project is, in my opinion, a sick thing to do.
______
1: Not addressing you in particular.
I have this darwinian vision of the software world where it's extremely positive to experiment with new stuff. Only time will tell which things surpass the test of time.
Attacking someone publicly this way just because he doesn't contribute to your¹ favorite project is, in my opinion, a sick thing to do.
______
1: Not addressing you in particular.
jack? That's a completely different user-case.
Haha, "Wolfgang Draxinger" signed 28 days ago. Check out this epic battle between Draxinger and Poettering: http://www.youtube.com/watch?v=ZTdUmlGxVo0
The way Poettering dismisses the "1970s unix mindset" is really sad. Here we have a big Linux contributor who apparently doesn't appreciate his heritage, which explains why he's constantly trying to reinvent it... and poorly, as the saying goes. I'm one of those who really didn't see the need for PulseAudio or any of the *Kit stuff, and even HAL was kind of a train wreck (all those years to make it stable and supported by desktop managers, to then throw it all away).
I'm sure he's just the most visible advocate of this approach, not the only one, but he's certainly responsible for a lot of the misery Linux desktop users like me were and are subjected to. After a decade of Linux on my desktop, I've switched back to Windows 7 in early 2011 and, to be honest, I'm quite happy I did.
I'm sure he's just the most visible advocate of this approach, not the only one, but he's certainly responsible for a lot of the misery Linux desktop users like me were and are subjected to. After a decade of Linux on my desktop, I've switched back to Windows 7 in early 2011 and, to be honest, I'm quite happy I did.
> I've switched back to Windows 7 in early 2011 and, to be honest, I'm quite happy I did.
Yes, because Windows 7 and OS X already have all this modern non-70s-stuff that Lennart is trying to bring to Linux.
Yes, because Windows 7 and OS X already have all this modern non-70s-stuff that Lennart is trying to bring to Linux.
No, it's because they're coherent experiences, developing single components over 10 or even 20 years. They don't chuck out entire subsystems on a whim, breaking compatibility with everything and then blaming anybody but themselves for the resulting mess.
Edit: it's quite astonishing how such a wide ecosystem of developers continues to misunderstand how you build successful developer ecosystems.
Edit: it's quite astonishing how such a wide ecosystem of developers continues to misunderstand how you build successful developer ecosystems.
And I am tired of the 1970 Unix mindset, don't fix what is not broken. Can we please have filesystems with a consistent encoding, like in Plan 9 or, woohoo, Windows? Or do we really need to support a mixture of Shift-JIS, EUC-JP, CP-850 or whatever else an application chooses to use?
When I read the headline of the article, I had to think exactly about this video. :)
There were indeed good reasons for writing things like DBus, systemd, PulseAudio and others.
There were indeed good reasons for writing things like DBus, systemd, PulseAudio and others.
I've to admit that the presentation as an 'epic battle' made me dismiss this at first.
But thanks a lot for that link. It was amusing _and_ interesting.
But thanks a lot for that link. It was amusing _and_ interesting.
Thank you for the youtube link. Great talk.
Why shouldn't Poettering be allowed to write whatever programs he wishes, useless or not? I think distributions are responsible for choosing the best selection of software, and nobody should be blamed for providing new alternatives to the table.
I hear a lot of people complaining about these new programmes, like PulseAudio, but as far as I'm concerend, with PulseAudio I can now have proper working sound. No more of this "Oh I have pidgin open, which wants to do sound, so Firefox with flash can't watch youtube" problems that used to happen.
What's the back story here?
Lennart is a Fedora dev known for writing replacements for linux subsystems. For example, he started PulseAudio and systemd, a replacement for init. Recently, he's suggested a replacement for syslog where the logs aren't written as plain text.
I would guess the last one was the impetus for this petition.
I would guess the last one was the impetus for this petition.
I don't understand what the big deal is. If his systems aren't useful distros won't adopt them and no harm is done. If they are useful and distros adopt them then he has advanced the state of the entire Linux community.
This petition seems childish.
This petition seems childish.
He's a Red Hat employee so everything he does ends up in Fedora at some point.
Don't use Fedora?
What's a better use of my time -- converting my 1000+ machines to another distro (which may turn out to be worse) or convincing Fedora not to make a stupid decision?
If you don't like this change, you probably also don't like the other Fedora changes that came in the past and surely also in the future, so yeah I'm with sjs. In the long time you will save time if you switch to a distribution that aligns with your choices.
Plus, you can do a dry-run with a limited number of machines and you can select a distribution which seldom changes (Gentoo switched to baselayout2 after.. years, Slackware still has tarballs as packages). Unlikely that they will push radical changes soon.
Plus, you can do a dry-run with a limited number of machines and you can select a distribution which seldom changes (Gentoo switched to baselayout2 after.. years, Slackware still has tarballs as packages). Unlikely that they will push radical changes soon.
If you don't like Fedora switching away from it will be more productive then fighting it on every change for all eternity.
A non-plain text syslog? That sounds stupid to me. Plain text is one of the reasons I love Unix in the first place.
Yup, incredible stupid. That means it will go into Fedora.
So who of you actually read Lennarts blog postings about the rationale? Or do you just dismiss it because SYSV didn't do that, some fourty years ago?
I read it. The benefits are awfully dubious, and the downside is significant. It reinvents a wheel in the most literal sense. It claims to fix problems that are already addressed, or are easily addressable, in the current implementation and derivatives like rsyslog.
Lennart's not even planning on documenting the format.
Lennart's not even planning on documenting the format.
If I wanted non-plain text logging, I'd use Windows. And I like BSD (I have never liked the SYS-V init system).
So your argument is you want plaintext because you want plaintext?
I replaced the BSD-like init system in Arch, because it is buggy. And I can dual-boot init-systems now.
I replaced the BSD-like init system in Arch, because it is buggy. And I can dual-boot init-systems now.
Stupidity, in a word (attacking a single person in this way).
If you ask for possible reasons to attack Lennart in the first place: He was the main force behind Pulseaudio (which, for various technical and political reasons was reviled for a long time) and now systemd (a C replacement for the sys-v scripts, think smf/launchd).
If you ask for possible reasons to attack Lennart in the first place: He was the main force behind Pulseaudio (which, for various technical and political reasons was reviled for a long time) and now systemd (a C replacement for the sys-v scripts, think smf/launchd).
The only reason people hated PulseAudio was because Ubuntu shipped it as their default sound system a year or two before it was ready. Now it's a pretty mature sound system that works well (at least with all the Linux hardware I have)...
"A year or two before it was ready", people like Lennart were already advocating it as The One True Way for Linux audio, so I don't blame Ubuntu for jumping the gun.
Besides, looking at how things go in that area, now that it works well enough it will probably be replaced quite soon.
Besides, looking at how things go in that area, now that it works well enough it will probably be replaced quite soon.
i don't have an opinion on the larger fight here, but you have to disable pulseaudio if you want a fast startup in opensuse 12.1 (otherwise there's a 30s pause when the desktop starts). disabled, everything seems fine.
FWIW, my laptop, running Fedora, boots to the desktop in 15s total, with pulseaudio. I would sooner attribute that to a problem with the suse init system (every time I've dug into the suse init scripts, I've found horribly absurd decisions) than I would pulseaudio.
Quoth Dziuba: "A long time ago, the original neckbeards decided that it was a good idea to chain together small programs that each performed a specific task, and that the universal interface between them should be text. If you develop on a Unix platform and you abide by this principle, the operating system will reward you with simplicity and prosperity."
I guess this is mainly caused by the failure of Linux as a commercial desktop. Except for heroic efforts by Red Hat, SUSE, and previously Sun, it's mostly a hobbyist affair. As a hobby, people prefer to do the fun work, not the tedious and boring maintenance, bugfixing, and polishing.
The quality of Linux as a desktop operating system is in stark contrast with Linux as a server operating system. Thanks to the enormous amount of money invested in server-related components, Linux as a server is generally very polished and reliable.
On a personal note, the effort required to maintain a stable Linux desktop made me switch to OS X in 2007, after using Linux for 13 years.