Hacker News Reader

Comment by LukeShu | Hacker News Reader

nosh is cool, but the "systemd compatibility" is for the systemctl command, socket activation, and automatic unit file conversion; it doesn't offer implementations of the systemd APIs, which is where "systemd compatibility" is really needed.

View on HN

Would there be any point of re-implementing all those APIs rather than using systemd?

Systemd cannot be used on the BSDs because it uses Linux kernel specific features.

I've just read that it uses a lot of Linux-specific things, but are there features that inherently can't be ported to BSD? And are those features absolutely critical to running it at all?

What I've read sounds more like "we're focusing on Linux, and won't be porting it" rather than "this software is inherently Linux-only, and can't be ported".

I daresay coming up with a shimmy layer to port it to BSD is probably less effort than completely rewriting it.

I like systemd, but I do think it'd be far easier to write a compatible system for FreeBSD (or enhance the FreeBSD kernel to provide the necessary features) than to port it. For instance, systemd fundamentally depends on cgroups; without an equivalent mechanism, it won't work at all. The same goes for dozens of other features. The necessary functionality doesn't exist in POSIX; rather than attempting to write a half-functional "portable" implementation, it would make more sense to embrace the FreeBSD kernel, use its features as appropriate, and build a full-featured init system specifically for FreeBSD. In an ideal world, that system would provide all the features of systemd.

(Note, for instance, that I said "FreeBSD", not "BSD"; portability is not worth trying to enhance 3-4 kernels to support the features you need, or sinking to the lowest common denominator.)

The systemd developers do no care about BSD, full stop. In fact they believe that portability is a negative attribute that leads to compromises and that by coupling everything together systemd can make Linux a better user experience and more like the popular proprietary OSes.

> I daresay coming up with a shimmy layer to port [systemd] to BSD is probably less effort than completely rewriting it.

The self-styled "uselessd guy" is right here on this very page. Xe attempted making systemd portable. The project is now dead. The experiences of the "uselessd guy" and of Ian Sutton, who is the bloke who did the work trying to make a systemd-logind for OpenBSD, are worth hearing.

* https://news.ycombinator.com/item?id=10176275

* http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/de...

They've expressly said that they won't accept any patches that will make it portable -- "We do not consider it feasible to port systemd to other Unixes (let alone non-Unix operating systems) and will not accept patches for systemd implementing any such portability" [1]. A lot of the issues come down to how Linux does namespacing, and how there's a lot of code that's hard-wired to require it. So any port would be a fork by near definition.

[1] http://www.freedesktop.org/wiki/Software/systemd/InterfacePo...

Wouldn't that be more simply fixed with patches to systemd?

Systemd refuses such patches as a matter of policy. You can form your own opinion as to what kind of open-source citizens that makes them.

Given the other replies in this discussion thread, I am inclined to believe that they are /Good Stewards/ of the design goals they have.

I believe a more proper examination of 'open-souce' or even Free Libre citizens might be found in examining the license selected for their works.

They chose the GNU LGPL 2.1+ license. Given their other stated beliefs, I read that they believe in allowing others to build off of this work, but would prefer those developers fork it and to begin a sister work that is more optimally coupled to another operating system.

That would be fine if they would standardise their APIs. But they only do that at the boundary; as more and more functionality moves into systemd that means more and more with no documented, supported API. Any port would have to implement systemd piecemeal, like GNU did with unix - but all the systemd interfaces are nonstandard and unsupported, making that impossible.

I'm assuming you've read http://www.freedesktop.org/wiki/Software/systemd/InterfaceSt... and http://www.freedesktop.org/wiki/Software/systemd/InterfacePo...

Which APIs do you refer to that are not documented as an stable interface, but should be?

The internal ones, as I said. E.g. you can't write a drop-in replacement for logd, or even a reader of its files. IIRC systemd doesn't support non-kdbus dbus - or indeed older kernels at all.

Here is documentation for the on-disk journal format (with links to the JSON+export format): http://www.freedesktop.org/wiki/Software/systemd/journal-fil...

systemd supports non-kdbus DBus, that is essentially what every deployed systemd system is using. Including this laptop, which is on latest systemd (227) with upstream kernel (4.2.5, kdbus not included).

Why is it important to be able to replace journald (assuming that is what you meant by logd)?

Being able to replace individual pieces is the heart of open source - the only reason the GNU project was able to get off the ground is because it could swap out individual parts of unix without having to write the whole thing from the ground up. More generally, forking only works if you can do it on a granular level. So if I have an idea for improving journald and for whatever reason the official maintainers won't accept my patches, I should be able to release my own fork of just journald and if people like it then it will become more popular and maybe be mainlined or maybe not. If I have to fork the whole of systemd to do that then it's too much overhead.

journald is a separate module in the systemd tree, so this is very likely possible. You have both the code implementing the daemon and the one using it available to study, so the interface.

The issue is that systemd might change that interface at any time, even in a minor or patch release. Because systemd's released as a single monolithic project, they don't have to commit to any standardization, deprecation cycle or the like for the interface between components.

Yep, no stable interface for journald. Someone is gonna have to prove to them it is needed, by implementing something useful that utilizes said interface.

but as documented previously in thread, for plenty of their components they have committed to stable, documented interfaces.

systemd supports 'older kernels', just not old ones. systemd 227, released last month, requires Linux 3.7+. That version was release December 2012, or nearly 3 years ago.

systemd depends on Linux-only kernel features. (Like cgroups.)

You'd have to patch the FreeBSD kernel first to be Linux-compatible.

On top of that, systemd is LGPL. That may not be a 100% showstopper for inclusion in a BSD-licensed system, but it is fairly close to it, especially for such a core component.

Reply on news.ycombinator.com