GNOME 3.16 on OpenBSD [video]
bsdfrog.org
bsdfrog.org
1) why was this video even made to celebrate such a port, if it was trivial?
2) perhaps you can show us where the systemd interfaces were merely "optional" in GNOME?
I love unsupported assertion day!
And OpenBSD (OPENBSD MAN!!) is a great excuse to make this fun appear less stupid than it really is. :)
EDIT: After actually watching this video, there is something genuinely interesting in it: the applications to manage hardware and user accounts work, so the porting team must have put some effort into this. The rest is, supposedly, just the same as in Linux...
"the odd men out" are the one with the the highest user base (I suppose you know that Ubuntu is moving to SystemD too)
Windows has a crummy POSIX layer, and it's not like it ships sysvinit.
Be serious.
Linux systems are quite POSIX. the whole point of GNU was to be compatible.
They were never unix, because they weren't of BSD or AT&T heritage. true, and completely irrelevant.
systemd absolutely hates POSIX, and is actively steering Linux away from it.
I have no idea why windows even applies here. If you are comparing Windows to systemd, you may be correct, but both are abhorrent to OpenBSD users.
Remember maths class? Show your working. systemd has fuck all to do with POSIX. If anyone still cared about POSIX, I'm sure you could waste money to get a systemd platform fully certified.
(By the way, OpenBSD is about as POSIX compliant as Linux in that neither are particularly concerned about it.)
can you please show me where OpenBSD shows as much hatred of POSIX compliance as LP (or even Linux) does?
(Plus, you have yet to point out anything about POSIX that is incompatible with systemd, or vice versa. Go away now, troll.)
Do you even use OpenBSD?
Again, show your work.
show your work.
But back to my question: you're stating that, if tested, systemd would pass POSIX compliance. that's very interesting, and I'd like to see how you came to that conclusion. care to elaborate?
(I've just looked at your history of comments. Discussion over.)
Thank you for keeping HN civil.
as GNOME requires SystemD to operate (battery, login, logging, etc, udev) [1],
and as SystemD is only a Linux technology (more specifically, a Red Hat Technology), and BSD would either have to a) recreate systemd in their software stacks, or b) make a shim so that GNOME will continue working[2],
and as every *BSD conference talk in the last year has at least one derogatory mention of systemd therein,
Therefore, the fact that we can now use GNOME under OpenBSD is thanks to the hard work of a lot of people who really do not like systemd, and are working extra hard to ensure it doesn't infect their OS.
1. https://blogs.gnome.org/ovitters/2014/09/07/systemd-in-gnome...
2. http://undeadly.org/cgi?action=article&sid=20140915064856
now, if they liked SystemD, why would they create shims, rather than reimplement it in OpenBSD?
What exactly do you mean by "reimplement it in OpenBSD" and what would be the difference to the current approach you call "shims"?
As GNOME 3.14 is quite different in many incompatible ways with 3.16[1], the fact that they're making that old code work, and updating it to 3.16 is not exactly a trivial task.
they haven't implemented any systemd interfaces. they have essentially redirected the systemd calls to proper utilities supported on OpenBSD (such as ntpd), which is defined as a "shim"; GNOME thinks systemd is there, but in reality, the apps that handled stuff before systemd are still handling everything while lying to GNOME.
1. https://blogs.gnome.org/ovitters/2014/09/07/systemd-in-gnome...
The article you link to doesn't support your claims. It explicitly states that Gnome 3.14 (which, btw, is only one revision ago, since Gnome uses the old Linux kernel version scheme) would still support ConsoleKit (i.e. a non-systemd codepath). In fact, Gnome 3.16 still supports ConsoleKit, at least in gdm (see the configure-option here [1]). Can you point out commits where non-systemd support was removed in Gnome 3.14?
And what exactly do you mean by "redirected the systemd calls"? Gnome calls certain methods on certain D-Bus objects; if there is a process on OpenBSD that receives these method calls and acts appropriately, why not call that implementing that particular interface?
I don't want to diminish the amount of work that went into this port. I find it really great that someone is doing all that work. But I don't think that the picture you paint of this is entirely accurate. You assume that the OpenBSD-guys hate systemd. That might be the case (it probably is for a lot of them), but I don't think that this has anything to do with this video. If the video e.g. had shown that they removed any reference to systemd whatsoever from the Gnome code and inserted some sneering comments, I might agree with your conclusion. But it simply shows that they succeded in porting Gnome 3.16 to OpenBSD.
How would this video have had to look, to persuade you of the opposite (i.e. that there were OpenBSD developers that love systemd)?
1. https://git.gnome.org/browse/gdm/tree/configure.ac?id=3.16.0...
As for dbus objects, GNOME calls systemd's interfaces to dbus, not dbus directly[1]. Calling dbus, which is already fully supported in *BSD, would be far preferable, and we might not even be having this dicsussion if they did.
here's another post with a tad more information on what GNOME needed in order to work on BSD (or even Slackware!)[1][2]. There was a lot of work in this release, and in no way am I attempting to diminish their work. I merely wished to make it clear that systemd was an obstacle they did not reimplement, but rather overcame with the use of shims.
1. https://news.ycombinator.com/item?id=9363060 2. https://news.ycombinator.com/item?id=9362050 3. https://news.ycombinator.com/item?id=9362054
It's a bit odd that you are writing this while citing a blog that said that removing ConsoleKit (non-systemd) code was not done in Gnome 3.16 ?
But let's accept that for the sake of the argument.
It looks like GNOME wants to depend on systemd's public and stable DBus interfaces; this is good because it gets GNOME out of having to maintain OS portability gunk, and puts the burden of maintaining said gunk on other projects, i.e., the systemd project on GNU/Linux.
The goal is rather similar to what the OpenBSD community is doing in its applications, in e.g. the OpenSSH project, which (in its upstream release) only runs on OpenBSD, making maintenance easier.
There is a difference though between the two approaches: while OpenSSH has a downstream project OpenSSH-portable that patches the source code to replace OpenBSD specific calls with portable calls or #ifdefs, the GNOME strategy is to depend on abstract APIs that are implemented by some lower layer in the OS.
Further, thank you for confirming that GNOME depends on systemd directly, and not merely dbus. This was the crux of my issue, and why this port was non-trivial. Had it been dbus alone, which already is in ports, we wouldn't be having this conversation.
but it's relying on systemd's "public and stable" (which we won't get into here) interfaces to dbus. not dbus directly. By depending on systemd, they are not only getting out of maintaining "OS portability gunk", but getting out of supporting any other OS that doesn't use systemd. do you see the difference here?
there is no systemd-portable, such as OpenSSH offers. in fact, Lennart Poettering has stated that such a port would not only be non-trivial, but something he does not wish to happen. if there had been, we might not be having this conversation either.