SystemBSD: Custom D-Bus daemons emulating systemd behavior on OpenBSD [pdf]
darknedgy.net
darknedgy.net
I'm perfectly content ignoring Gnome, but if every full desktop environment starts relying on this because it's available, then it's not really so optional anymore. (and of course, if the alternative is guaranteed to be no major DE running on BSD at all without this, then we similarly have our hand forced. It depends on who would flinch first.)
Essentially Gnome seem able to throw a whole lot more man hours at various topic than can the rest of the DEs, KDE included. This in turn seem to lever Freedesktop towards them (though Freedesktop may have overly favored Gnome from the get-go).
I was under the impression they had FreeBSD users on their dev team, and kept it alive, just with some limited features (like automounting not really working) and only relying on a few Linuxisms like Consolekit.
Still on 4.10 though, so perhaps that's no longer the case on the newer versions.
the tour was taken using openbsd
Basically, with Wayland the compositor/Window Manager/toolkit gets elevated to the same level as X11. Meaning that it has to do pretty much everything that X11 used to do for it.
The alternative to using logind+polkit is to run the DE/WM/compositor as root. Not something often talked about, as wayland is supposed to be the secure choice vs X11.
Frankly it feels like Linux is turning into some kind of marketing mess, where stuff is being presented as one thing but is in essence something quite different for those in the know.
> Frankly it feels like Linux is turning into some kind of marketing mess
I feel it's just been becoming a mess in general. They're trying too hard to cater to every possible use case, and there's nobody really in charge of the whole end-product to say "NO" to things. So they completely miss the elegance that comes with simplicity and minimalism.
More and more, I feel the long-term solution for BSD is going to have to be a full split on the graphical stack. It's been lovely for transitioning to be able to take all of my Linux apps with me to BSD, and it's a huge hindrance to eg Haiku adoption, but ... with Linux becoming more and more insular with Linux-only dependencies all throughout the stack, it seems inevitable that this Frankenstein of Linux emulation is going to have to collapse at some point. We could still have GTK/Qt ports, so we could still run the truly portable stuff (Audacious, Pidgin, Transmission. etc.)
Or as a nice alternative, dedicate a TTY to running a virtual machine of a full Linux OS for your graphical desktop.
For anyone following Linux since 2000 at least, this statement is so funny.
X11 was never simple nor minimal. The various init daemons were never simple nor minimal. The mess that is the collection of kernel drivers has never been simple nor minimal. Linux has always been about choice: if you like stripped-down, you go and strip it down; if you like full-featured, you go and pack everything. There is no one-size-fits-all, no single design. Anything else would not be Linux.
The un-linuxness of systemd is exactly that it's becoming less and less optional. We whined for years that X11/Xorg was really a non-optional piece of crap, and when it's finally seeing some competition, we're being saddled with a non-optional daemon that takes over the rest of your system -- and unlike X11, it's not even desktop-only.
This is wrong. Linux has never been about anything. It's always been only what people have made it; no less, no more.
Viewed like this, systemd is not at all "un-linuxy" (if that made sense in the first place). It is a set of tools written by a bunch of people to solve their problems, and has gained mindshare, users and developers faster than other alternatives, which is exactly what Linux (the kernel) did.
Your only choice is to use it, or not use it, but you don't get to complain if someone else decides to depend on it because they deem superior to alternatives. If you want to keep other software from depending on systemd, the onus is on you to provide a reasonable alternative. It will not work to simply demand that others must spend their effort maintaining code that they have no interest in because you want something.
You're saying it as if there aren't already plenty of them.
Previously, every distro built their own init systems and core tools to manage services, leading to meaningless differences in an area where heterogeneity is not a benefit, but hinders progress instead.
I don't really have an opinion one way or the other about the rest of the project's tools like networkd or the dhcp server and what have they, but having a working service manager out of the box (which means it actually gets used by default!) has already made my life easier compared to the old sysvinit thing that couldn't even reliably tell you if your services were running or not, never mind anything more advanced.
There's your problem. You don't even have any defined scope. A "coherent, modern core userland" doesn't actually mean anything concrete - it covers enormous ground that no single package can obey.
Modern service managers are plentiful - nosh, s6 and perp probably being the most promising.
The "old sysvinit thing" has been replaced many times for over 15 years by now. Just because you didn't notice, well, that's your problem.
I found it rather enlightening and found myself agreeing with pretty much everything. Trying to argue for or against systemd is a waste of time, so I will stop.
All the time spent debating would likely be better used just spreading knowledge about your preferred methods so that people can make informed choices when solving their own problems.
Trying to argue for or against systemd is a waste of time, so I will stop.
I have to agree.
Does the fact that sshd's X11 forwarding doesn't require to run an X11 -errm- client(?) to run X11 software on a remote machine make X11/Xorg more optional? (Obviously, you do need to run X11 on the machine that displays the GUI, and you do need X11 libs installed on the remote machine.)
You could choose among different windows servers, desktop systems etc, but all of these would only run on top of X11/Xorg. Compatibility with other implementations both at protocol and interface levels was barely even nominal. Whenever X11/Xorg development stalled or hit problems etc, the entire desktop ecosystem was screwed, often for long periods.
Now we're going to see this happen with basically the entire userland. If distributions keep pushing it, systemd is going to become "X11 for userland", regardless of its actual quality.
So yes Wayland Like X is in theory OS agnostic but in practical terms they are only as portable as there specific implementation.
I've always heard things like "Wayland is going to be the replacement for X.org." and "Work on Wayland compositors is proceeding at pace.". Pardon my confusion.
To address my claim, do you know if there is currently a functional, non-toy Wayland compositor that doesn't plan to add a dependency on systemd?
There are native BSD desktop projects being worked on that are quite polished and require none of the Linux based SytemD+Gtk+Gnome dependency stack.
Lumina is worth looking at (Qt based) and also runs on Linux.
https://en.wikipedia.org/wiki/Lumina_Desktop
From what I remember the author started this work before the nuclear meltdown which is commendable. But we are obviously in a post schism age.
At last count SystemD has over 40 "Interfaces". These are not publicly versioned standards. So there is no stable interface to even implement and there is no commitment that these "interfaces" will not change at any point in time.
If the project estimate to actually implement XYZ interface takes years of full time engineers and millions of dollars to complete its basically out of the reach of any volunteer open source operating system project.
I just find the argument disingenuous. Everyone making these claims knows that there is practically 0 chance that anyone but RedHat or another big Corporation like Google or Samsung has the resources to Implement something like this.
Take a look at https://wiki.freedesktop.org/www/Software/systemd/InterfaceP... and you'll see that there are indeed a plethora of systemd service apis. But almost all of them are covered by the systemd stability promise (https://wiki.freedesktop.org/www/Software/systemd/InterfaceS...) and almost all of them are documented.
So, there is a commitment that these interfaces will not change.
In short SystemD is an implementation. And as they say in there own documents there implementation is and never will be a portable implementation.
The "Interface Stability Promise" is referring to the unit configuration file format and the command line interface. This is not stability of the implementation c interfaces.
If you want to see a proper portable specification take a look at the Wayland Protocol Specification. There or perhaps POSIX.
This is not true.
Isn't this what the systemd 'Interface Stability Promise' does as listed here ?
http://www.freedesktop.org/wiki/Software/systemd/InterfacePo...
Judging by this chart, ~99% of the intefaces are stable.
http://www.freedesktop.org/wiki/Software/systemd/InterfacePo...
CreateSession(in u arg_0,
in u arg_1,
in s arg_2,
in s arg_3,
in s arg_4,
in s arg_5,
...
I remember someone complaining about that years ago already. Apparently nothing changed.
The CreateSession description states that it should never be called from the clients, but instead be handled through PAM, so assume this is why they don't describe the arguments for this one call, while all the other method arguments and return values are described under 'Methods'.
What I mean specifically is that they document the client interface only, not the full interface needed for a complete replacement.
If you want to re-implement logind you will invariably read the logind source code anyway, where the call arguments are described.
You said there been a complaint about this, was there a discussion you can point me to ?
1) Does this mean that you consider software's source code to be adequate documentation of an API and its behavioral contracts?
2) There's this saying that goes something like "You never know that you have a good API until you've created three independent implementations of it.". It's very difficult to create an independent implementation of an API if the primary documentation of important parts of that API's behavior is the source code that implements that API.
If this fails the test, I suggest that it is a marvelous failure which every project should strive to emulate. To suggest that systemd is poorly documented indicates an insufficient exposure to the sad reality of most Open Source projects where "our unmaintained, outdated, bug riddled code base is the documentation" is the best case answer to the question of documentation.
There are a lot of praiseworthy things about systemd and its approach to documentation. The blog posts are definitely one of them. That doesn't mean everything is praiseworthy, that there's no room for improvement, or that complaints about things not being documented are illegitimate or inappropriate.
There's an (as far as I can tell) IPv4-only implementation for Linux in ucarp. [0] I use it for failover on my home LAN.
Question: Does OpenBSD CARP support "passwords" longer than 15 or 16 characters?
The neat thing is that most of the things you need for that role are in the base install, which is quite minimal.
> They were in MagicPoint format, so I had to convert them to PDF with a dubious third-party Python script, slightly modifying the MGP manifest in the process. That's probably why the formatting is so iffy.
You'll also note that the author "reluctantly" gave permission. For all we know, it was precisely because the author knew that people would criticize the paper over superficial format conversion issues than actual substance.
https://uglyman.kremlin.cc/gitweb/gitweb.cgi?p=systembsd.git...
I find it a little hard to understand too. I am going to chalk this up to me starting to be an old man and complaining about not understanding the youths.
For what it's worth, I was a horrible writer when I was an undergraduate, and this was a GSOC project, so I'm willing to cut some slack. Might be because I'm a slacker.
They were in MagicPoint format, so I had to convert them to PDF with a dubious third-party Python script, slightly modifying the MGP manifest in the process. That's probably why the formatting is so iffy.
For those wondering, the systembsd sources are here: https://uglyman.kremlin.cc/gitweb/gitweb.cgi?p=systembsd.git...