Hacker News new | ask | show | jobs
by samworm 4528 days ago
I personally prefer systemd to upstart. I just hope that distros (in this case Debian) stick to a technical review and don't get drawn into ad hominem arguments.

For many people it seems the answer to the question posed in the post title is "I would expect it to not be designed/authored by the man behind pulseaudio".

2 comments

One argument that is on the edge: Lennart often takes controversial decisions, and in the case of systemd, he refuses portability patches that would allow systemd to run on other unixes than Linux (BSD, Hurd, etc).

Since debian is supposed to be universal (hence, support alternative Unix kernels), choosing systemd barely means that they will have to drop this trait of the distribution.

Various features that systemd exposes have no equivalent in other kernels. This makes it impossible. He also explained various times why he refuses non-complete portability patches. This because you get more ifdefs and those are difficult to test/guarantee.

He and Kay claimed that kdbus couldn't be used for Binder as well. Greg thought it was possible. Only after writing kdbus he came to the conclusion that Lennart+Kay had it right.

Suggest to write a complete patch to make systemd work on FreeBSD. I assume you'll discover Lennart is right :-P

Actually, feasible or not, I understand and somewhat agree with the fact that they don't want portability patches, it would probably force systemd to be limited to the lowest common denominator and add a lot of complexity to the project.

However, I was wondering if platform-specific forks are a sustainable solution.

You do not get portable code with ifdefs, you only get 2 non portable programs in the same file.
Upstart also has the issue of being non-portable as of right now, so either way a porting effort has to be actually undertaken (even if Upstart is saying that it's planned)--And Debian is adopting large amounts of systemd for other systems.

Lennart hate is fine, but let systemd stand on its technical merits (or lack thereof, if you really feel that way).

A lot less non-portable though. There are people that have managed to boot it on kFreebsd.

https://lists.ubuntu.com/archives/upstart-devel/2014-January...

But yes, it is still a work in progress.

There is an observed situation in evolutionary ecology which the response to Lennart rather reminds me of: the case of the overwhelming singular adaptive advantage. An ecological situation arises which gives one subspecies a huge, but temporary, advantage. So huge that all the other subspecies are competed to extinction. But that advantage was an advantage in only one aspect of survival and now there's a monoculture (which we all know is more fragile against future threats). If there's a latent, (or perhaps overt?), Lennart-phobia, it's that he possesses that one temporary huge advantage which will lead us to a monoculture? ...or not, this is just a curious analogy [shrug]
Up until this debate, I don't think most people were aware that there was even an init-culture to fear turning into a monoculture :)

I think your observation is true though.

I suspect that if someone actually did the work to port systemd, upstream would be nicer.

I have mixed feelings about the BSD & Hurd ports. "You shall not crucify Debian Linux upon a cross of Hurd" and all that.

I'm pretty much done with Debian because of this. I have one last server to migrate and then I'll never have to deal with the personalities and preaching again.
> I would expect it to not be designed/authored by the man behind pulseaudio

Having used a bunch of Lennart's software, I'm generally coming to the conclusion that he's better at ideas than code -- but once his projects take off and the bugs get fixed, the end result is significantly better than what we had before.

(Using pulseaudio as a specific example, per-app volume controls and easily mixing and matching sound sources and playback devices; seamlessly switching from speakers to headphones to HDMI to a sound server on another PC entirely, etc -- features that are too high-level for the kernel and too low-level for applications, and thus can only be brought into existence by a fairly large change in the audio stack)