Perhaps this is the main problem - the people pushing technology are not willing to acknowledge that people have different use cases to them. There are complaints, and they are valid - you just do not see them as valid, because they don't concern you.
Since you brought PulseAudio up, there's a very legitimate, common complain about it - latency. Yes, the people who care most about audio - the creators and audiophiles - are pushed aside as "not relevant," because Lennart is only interested in "appealing to the majority," not some minority fringe groups.
Really, the only reasonable solution for some people is Jack - but any hope of bridging the gap between Jack and Pulse is lost in a barrage of people pushing for a "single audio solution" - and prematurely claiming Pulse as the victor.
As a result, people write applications to only use PulseAudio, which are then unusable to someone using Jack (aside from hacks to make pulse act as a jack client). Professional audio software is still basically required to code for both Jack and Pulse/ALSA or whatnot - we're nowhere near a single audio solution.
But don't tell that to Poettering - because he is adamant that his solution is the only solution, and anyone who it doesn't suit is just playing with toys.
That's literally how he referred to Debain's choice to not push systemd because it targets multiple kernels, which systemd does not work with. (Which btw, Arch does too - although perhaps not the same people.)
Have you still yet to see a valid complaint? Of course kFreeBSD is not a valid complaint to you, because you've never used it, and never plan to - it's of no concern for you.
If we only cared about what's popular, Linux would not be what it is now - and you'd be on Windows. Linux is not the end-all solution to every problem anyway, as other lesser popular kernels have some great technology in them which is lacking in Linux. It's the only solution for Red Hat though - so you can see why they're happy to push such agenda. If you're not a Red Hat customer, your opinion is invalid.
Arch was built with a different mentality - the one of personal freedom to do what the hell you want with your desktop, not for the benefit of some company. You are free to use or reject any software you don't want.
Well, not any more. Pushing systemd on users breaks that mentality - because the choice is stripped from you. The choice is already there in Arch though - and has been for a while. If you want systemd, you can use it. If you don't want it, don't bother. Moving the other way is not really possible though - because if you build your system around systemd, you can't revert back (without taking the time to rewrite everything that depends on systemd.)
The dependency problem in itself is a complaint against systemd. Should udev users be forced to use systemd for example? Normally we would introduce another layer of abstraction to our code - such that we can share common code between systemd-udev and non-systemd-udev, and have a solution where everyone wins - the systemd users benefit from improvements in systemd integration, whilst everyone benefits from improvements to udev which aren't systemd dependent. This is programming 101.
Well, not if you're the package maintainer and have more political motives. Any proposal to introduce such a split with common code will probably be met with: NO, we're not interested - It's too much work - It's pointless supporting non-systemd - Fork it.
A fork it will be - and because the fork will be much less popular - it will obviously be a toy.
Just to be clear - I'm not against systemd and Pulse from a technical point of view, and I can very clearly see the advantages they have over alternatives, for linux. I'm not really against fragmentation either.
What I am against though, is the politics of it. The constant pushing of systemd down everyone's throat like it's a fucking panacea. One day saying "don't use if if you don't want," and the next blogging "you're fucking idiots for not using it." (Lennart's approach to Ubuntu.)
This takes away no choice, I'm sure if you want to use old style init that'll be available too, you'll just sacrifice easier config, faster boot, better diagnostics, logging and profiling of boot.
The old init will still be available, but the point is that anything built to run on systemd only, will not be easy to use with older systems without effort to backport them. This isn't much of a problem if you do choose to use systemd though, because it's backward compatible with older scripts.
It would be awfully hard to make a service that didn't work without systemd. Your software shouldn't depend on systemd, just as it shouldn't depend on init.d, rc.d, or anything else unless it's a tool specifically for working with that (like chkconfig or update-rc.d).
I brought it up primarily as an example of what is NOT relevant to systemd.
> But don't tell that to Poettering - because he is adamant that his solution is the only solution, and anyone who it doesn't suit is just playing with toys.
That's not what he said about PulseAudio. He specifically mentions the need for the other APIs and that the situation sucks. http://youtu.be/9UnEV9SPuw8
> That's literally how he referred to Debain's choice to not push systemd because it targets multiple kernels, which systemd does not work with. (Which btw, Arch does too - although perhaps not the same people.)
The advantages the Linux kernel provide (particularly, cgroups) is such a useful thing it would be stupid not to use it just because it doesn't exist everywhere. So either stick with your current init system, make a similar init system that is compatible with unit files (which are extremely simple), or add the necessary features to the BSD kernel. I'm not seeing a valid complaint here because systemd doesn't affect you unless you want it to.
>Arch was built with a different mentality - the one of personal freedom to do what the hell you want with your desktop, not for the benefit of some company. You are free to use or reject any software you don't want.
> Well, not any more. Pushing systemd on users breaks that mentality - because the choice is stripped from you. The choice is already there in Arch though - and has been for a while. If you want systemd, you can use it. If you don't want it, don't bother. Moving the other way is not really possible though - because if you build your system around systemd, you can't revert back (without taking the time to rewrite everything that depends on systemd.)
There is no "everything that depends on systemd" other than the init process itself. You say this choice is stripped from you, but what you want is to force the Arch developers to maintain init scripts. Take responsibility for it yourself - get together with other people who want those init scripts maintained and maintain them. You won't get things you want by just demanding that the world give it to you.
> The dependency problem in itself is a complaint against systemd. Should udev users be forced to use systemd for example? Normally we would introduce another layer of abstraction to our code - such that we can share common code between systemd-udev and non-systemd-udev, and have a solution where everyone wins - the systemd users benefit from improvements in systemd integration, whilst everyone benefits from improvements to udev which aren't systemd dependent. This is programming 101.
Where are these systemd-dependent parts of udev? They don't exist. There is no need for an abstraction layer to deal with the differences because there are no differences from a user perspective.
>What I am against though, is the politics of it. The constant pushing of systemd down everyone's throat like it's a fucking panacea.
Really, you're more political than anyone I've seen on the pro-systemd side of things.
>One day saying "don't use if if you don't want," and the next blogging "you're fucking idiots for not using it." (Lennart's approach to Ubuntu.)
Perhaps this is the main problem - the people pushing technology are not willing to acknowledge that people have different use cases to them. There are complaints, and they are valid - you just do not see them as valid, because they don't concern you.
Since you brought PulseAudio up, there's a very legitimate, common complain about it - latency. Yes, the people who care most about audio - the creators and audiophiles - are pushed aside as "not relevant," because Lennart is only interested in "appealing to the majority," not some minority fringe groups.
Really, the only reasonable solution for some people is Jack - but any hope of bridging the gap between Jack and Pulse is lost in a barrage of people pushing for a "single audio solution" - and prematurely claiming Pulse as the victor.
As a result, people write applications to only use PulseAudio, which are then unusable to someone using Jack (aside from hacks to make pulse act as a jack client). Professional audio software is still basically required to code for both Jack and Pulse/ALSA or whatnot - we're nowhere near a single audio solution.
But don't tell that to Poettering - because he is adamant that his solution is the only solution, and anyone who it doesn't suit is just playing with toys.
That's literally how he referred to Debain's choice to not push systemd because it targets multiple kernels, which systemd does not work with. (Which btw, Arch does too - although perhaps not the same people.)
Have you still yet to see a valid complaint? Of course kFreeBSD is not a valid complaint to you, because you've never used it, and never plan to - it's of no concern for you.
If we only cared about what's popular, Linux would not be what it is now - and you'd be on Windows. Linux is not the end-all solution to every problem anyway, as other lesser popular kernels have some great technology in them which is lacking in Linux. It's the only solution for Red Hat though - so you can see why they're happy to push such agenda. If you're not a Red Hat customer, your opinion is invalid.
Arch was built with a different mentality - the one of personal freedom to do what the hell you want with your desktop, not for the benefit of some company. You are free to use or reject any software you don't want.
Well, not any more. Pushing systemd on users breaks that mentality - because the choice is stripped from you. The choice is already there in Arch though - and has been for a while. If you want systemd, you can use it. If you don't want it, don't bother. Moving the other way is not really possible though - because if you build your system around systemd, you can't revert back (without taking the time to rewrite everything that depends on systemd.)
The dependency problem in itself is a complaint against systemd. Should udev users be forced to use systemd for example? Normally we would introduce another layer of abstraction to our code - such that we can share common code between systemd-udev and non-systemd-udev, and have a solution where everyone wins - the systemd users benefit from improvements in systemd integration, whilst everyone benefits from improvements to udev which aren't systemd dependent. This is programming 101.
Well, not if you're the package maintainer and have more political motives. Any proposal to introduce such a split with common code will probably be met with: NO, we're not interested - It's too much work - It's pointless supporting non-systemd - Fork it.
A fork it will be - and because the fork will be much less popular - it will obviously be a toy.
Just to be clear - I'm not against systemd and Pulse from a technical point of view, and I can very clearly see the advantages they have over alternatives, for linux. I'm not really against fragmentation either.
What I am against though, is the politics of it. The constant pushing of systemd down everyone's throat like it's a fucking panacea. One day saying "don't use if if you don't want," and the next blogging "you're fucking idiots for not using it." (Lennart's approach to Ubuntu.)