rleigh, it's really not as easy as you think. Making the event loop portable to kqueue is complex, but doable, I can agree to that. -- But the trouble starts beyond that. The BSDs don't have anything like cgroups. There's no way to attach a name to a group of processes, in a hierarchal, secure way. And you cannot emulate this. (And no, don't say "BSD jail" now, because that is something very different). But this already is at the very core of systemd. It's how systemd tracks services. And then, a big part of systemd is to track device status, as they come and go. Device management is fundamentally different on all OSes, you get very very different semantics. On Linux we have the udev rules set, which is entirely lacking on other OSes. systemd integrates very closely with that.
Portability of the most basic building blocks of the OS userspace goes way beyond just replacing a few system calls, it massively changes the semantics you expose, the behaviour you can rely on, and even becomes visible in the APIs you export.
Really, you should try porting this stuff, and you will run against a series of walls, and you cannot climb over them, as you will notice. When you start porting, don't start with the easy ones, such as epoll(), start with the hard ones, that are actually at the core, start with cgroups, start with device management. And you will notice that portability of this code is not just a question of caring, it's a massive undertaking.
Posted Nov 14, 2012 12:34 UTC (Wed) by clump (subscriber, #27801)
[Link]
I suppose the relevant question to ask you is if anyone has come forward to help systemd get ported to different operating systems?
Crowding out OpenBSD
Posted Dec 5, 2012 1:27 UTC (Wed) by trasz (guest, #45786)
[Link]
Not really. The relevant question would be why would anyone want systemd ported to different operating systems.
Crowding out OpenBSD
Posted Dec 18, 2012 13:17 UTC (Tue) by clump (subscriber, #27801)
[Link]
Not really. The relevant question would be why would anyone want systemd ported to different operating systems.
Or the relevant question could be exactly what I asked. If you have to ask why, you didn't read the article or the thread.
Crowding out OpenBSD
Posted Nov 14, 2012 16:56 UTC (Wed) by michaeljt (subscriber, #39183)
[Link]
> There's no way to attach a name to a group of processes, in a hierarchal, secure way. And you cannot emulate this.
One could require that administrators should create private users for daemons if they wanted to be able to shoot them down reliably. Not saying you should have gone this way, just that it would be another way of handling it.
> Device management is fundamentally different on all OSes, you get very very different semantics.
Yes, that can be a lot of fun.
Am I right though in thinking that the interfaces through which processes higher up in the stack communicate with systemd are normal DBus ones on the whole? If so then portability issues caused by software on Linux depending on systemd (I mean GNOME panel-like software) could presumably also be solved by making native infrastructure on the target system present those interfaces too.
Crowding out OpenBSD
Posted Nov 14, 2012 17:15 UTC (Wed) by Trelane (subscriber, #56877)
[Link]
Perhaps also the comparison with now is shortsighted. Yes, it would take a lot of things to port systemd to a BSD. However, it's not like the features that were developed were developed all at once. The pieces on which systemd relies have been developed over time, and the BSD folks in some cases actively chose not to develop similar or compatible systems. In other cases, it was a more passive decision e.g. deciding to focus developer time in other places. Though of course hindsight is 20/20 and it's hard to predict what features the next cool new thing will rely on, so it is oftentimes also understandable.
But the main message is that the entirety of systemd is not just systemd itself, and the majority of things that make it distinctive and non-portable were developed for Linux and not developed on the BSDs over a large swath of time, not all at once.
It should be noted that similar problems would likely arise from trying to port it to aix, hpux, solaris, OSX, or HURD (I suspect you know a bit more about what that would entail than I ;). But the BSDs are not special in this regard either.
(Incidentally, why the complaint about Linux instead of e.g. OSX's proprietary systems? Why are there not outcries against a lack of e.g. Aqua for BSD? Though perhaps this has been raised and answered elsewhere and I've not seen it.)
Crowding out OpenBSD
Posted Nov 14, 2012 18:44 UTC (Wed) by jwakely (subscriber, #60262)
[Link]
> why the complaint about Linux instead of e.g. OSX's proprietary systems?
I thought the same thing. I wonder how many *BSD users and devs were lost to Mac OS X. The BSDs are benefiting from LLVM and Clang, but I don't know if the same is true of other tech Apple have built on top of a BSD kernel.
BSD developers' moves to Apple?
Posted Nov 19, 2012 22:38 UTC (Mon) by dmarti (subscriber, #11625)
[Link]
Just what I was going to ask. (Someone asked me what happened to *BSD user group meetings, and I guessed that they're still going on, but they're in a conference room in Cupertino and nobody who goes is allowed to talk to you.)
Crowding out OpenBSD
Posted Nov 15, 2012 0:55 UTC (Thu) by geofft (subscriber, #59789)
[Link]
Silly question: has anyone tried adding cgroup support to a BSD kernel (instead of trying to make systemd not use cgroups)?
Crowding out OpenBSD
Posted Dec 5, 2012 1:18 UTC (Wed) by trasz (guest, #45786)
[Link]
There is no point in doing it. For simple purposes, you're better off with login classes. For complicated - with jails. There is point in adding third mechanism.