Slashdot Mirror
GSOC Project Works To Emulate Systemd For OpenBSD
An anonymous reader writes Through a Google Summer of Code project this year was work to emulate systemd on OpenBSD. Upstream systemd remains uninterested in supporting non-Linux platforms so a student developer has taken to implementing the APIs of important systemd components so that they translate into native systemd calls. The work achieved this summer was developing replacements for the systemd-hostnamed, systemd-localed, systemd-timedated, and systemd-logind utilities. The hope is to allow for systemd-dependent components like more recent versions of GNOME to now run on OpenBSD.
Not really.
* This software is not going to end up in the base system but in ports. It will not have a big effect on the base system.
* The goal of the project is not to import the systemd programs like the NTP daemon or the cron daemon. Instead, it implements some of the APIs so it will be easier to port software that depends on some systemd features.
When the software is ready and ends up in OpenBSD ports, it will probably only be installed if you install a piece of software that depends on systemd (future gnome, for instance). So if you don't install these kinds of software, you don't even end up having "systembsd" on your computer.
In what way is the refuge gone now?
The three services are actually needed.
The systemd-localed is simple: it provides the user with capability to change the locale on the fly (and applications with the ability to react on the locale change).
The systemd-timedated does almost the same for the date and time.
And the systemd-logind is basically a dbus wrapper to provide access to log-out/shutdown/etc functions.
The usefulness of logind can be argued, but centralized management of date/time and locale changes were long overdue. Linux is pretty much the only OS remaining, where application, if needed, can't really know if/when date/time or locale has changed.
In no way the services itself depend on the systemd - they are simply part of the systemd package. Nothing more.
All hope abandon ye who enter here.
you could try reading up on it. Here's a taster for you..
"systemd is a system and service manager for Linux, compatible with SysV and LSB init scripts. systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux control groups, supports snapshotting and restoring of the system state, maintains mount and automount points and implements an elaborate transactional dependency-based service control logic. It can work as a drop-in replacement for sysvinit. "
and if you are in the mood for reading, here's a longer introduction.
http://0pointer.de/blog/projec...
its probably getting rid of SCO stuff from Linux as well as its a Linux specific project
"The hands that help are better far than lips that pray." - Robert Ingersoll (1833-1899)
because Desktop Environments DO interact with the lower systems.
They need access to the DRM and input device, they need access to things like reboot/shutdown/hibernate.
If I understand it correctly one goal of logind is to run the X-server and the Desktop Environment without root, so they cannot do this directly... they use the logind API for it.
The three services are actually needed.
For what? If you say "to bring more windowsisms to linux" then I can believe it. Otherwise, not so much.
The usefulness of logind can be argued, but centralized management of date/time and locale changes were long overdue. Linux is pretty much the only OS remaining, where application, if needed, can't really know if/when date/time or locale has changed.
Unix (not so much linux) has for a really long time been a multi-user system, where multiple users can use different locales and different time zones. The system itself always ran on UTC. UTC is not supposed to change. Users changing their locale need to log out and back in again. That works well enough for the expected frequency of such changes occurring and doesn't need lots of code to notify every running process AND lots of code in every running process to deal with the change.
As an engineering tradeoff, the Unix way makes sense to me. The poetterix way, not so much. So I don't really buy your "long overdue", no.
The thing the inexperienced systemd developers (but I repeat myself) do not understand is that "modular" isn't about some technical detail such as how you compile various features. For example, busybox intentionally compiles everything into one big binary. The features it provides, on the other hand, are still very modular in the UNIX sense. The key difference is that the tools busybox provides ("cat", "wc", "mkdir", "dd", and many others) all implement well defined APIs.
What is an Application Programming Interface (API)? It's not some function you can call, or the fact that a program understands some option ("--foo"). It is not even the documentation that may or may not be provided that describes how to use some feature. So what is it?
An API is a PROMISE .
It is a social feature, not a technical one. The functions, options, and documentation are just the technical implementation of that promise. The key part of an API is that it is a promise by the developer that if you want to interact with some feature, this is the way to do so, because while other internal stuff may change at any time, the promised API will be stable and reliable.
The problem with systemd is exactly this. Pulling a n00b move and agglutinating various features into one project is annoying and not recommended, but it is not, on its ownn, a reason to avoid systemd. The problem came when Poettering stripped down the barriers betwen features with the specific goal of removing established APIs. His stuff may compile into various separate programs, but Pottering is very careful to keep various key interfaces "unstable", specifically to not make any promise about how those interfaces will work in the future. He likes to call this hididng of interfaces "efficency" or "removing complexity". What he never mentions is that many of us used those promises, and by removing them he has at best forced others to do a lot of work to fix the breakage, or at worse made various features impossible.
A good example is logind, which was absorbed into systemd just so promises about its behaviuor in the future ("stable APIs") could be removed.
The reason many of us that have been watching Poettering's cabal for many years now suggest these changes are intentional and malicious are based on this. Occasionally removing features because of a technical need or bug or security requirement is understandable. Purposfully stripping out entire sets of features - that is, the features that allow other groups to develop with confidence that some feature they won't simply vanish - is something entirely different.
If MS acted like Poettering's cabal and removed a formerly-public API that competetors used - while promoting their own product that happens to use internal, not-publicly-promised APIs, the world would be screaming "monopoly". This happened, and resulted in several high-profile court cases.
So go ahead an prove that you don't know what you're talking about and assert that systemd is in any way "modular", when non-modularity was an explicit goal behind systemd. The rest of us are choosing to not go along with Poettering's attempt to embrace and extend Linux into a cheap, buggy, feature-free windows clone.
Ce n'est pas une signature automatique.