GNOME 3.13.2 Temporarily Depends On Systemd

[TeamBlackFox]

They *are* seperate(sic) daemons. Wouldn't know if systemd functioned on a static /dev (or DEVTMPFS for that matter).

Well I meant not that systemd itself would fail if udev died, but anything depending on udev such as networkd or logind would die if udev died. systemd is the root of all processes and in an attack designed to take a server offline from a hacked user account, its the easiest target. Thats what I meant. In FreeBSD, init isn't a full blown process supervisor, and is much harder to get to, thats all.

Not to mention, the systemd pantheon keeps mushrooming outward, violating the principle of a limited, well defined function.

[mdias]

...
Not to mention, the systemd pantheon keeps mushrooming outward, violating the principle of a limited, well defined function.

You're missing the point. What you're calling "systemd" doesn't exist; systemd isn't a single executable.
Systemd is a group of several components, and each one does a limited, well defined function.

What you're saying is comparable to saying "a music band violates the principle of a limited, well defined function because it plays more than one instrument".

[Vim_User]

if it is dbus communication, then linking simply makes no sense at all. you provide connecting interface as part of your app and that is it. if it wouldn't be so, then whole point of dbus would make no sense. with dbus communication... YOU DON'T implement innards, that is up to server providing interface. so, if sysv somehow satisfied dbus interface for logind... why not? client should not notice any difference

I was replying to the post stating that they directly link to systemd libraries, which is not DBUS communication and therefore a hard dependeny, which can only be thrown out by either dropping the dependent code, switching to DBUS communication or implementing the needed functions yourself.
Therefore the question which it is.

[Vim_User]

It seems to me that this isn't a bad thing. I know not one person who uses GNOME on BSD, or on anything at all really, unless you count Cinnamon, and if I remember correctly as of version 2 that no longer relies on the GNOME package as a direct dependency - in other words - we're not going to lose much. All BSD projects are BSD-licensed and as GNOME is a direct part of GNU the effort is really sort of wasted to keep it BSD compatible, its only ever going to be a port or package and never included in base, unless you're PC-BSD.

I have to say I don't mind Wayland one bit, because it is indeed more UNIX way conforming to vs X11. The issue is that it currently depends on udev, a GNU/Linux dependency. It'd be nice if instead of relying on a piece of systemd that Wayland instead used a protocol which could map to udev, HAL, devd (FreeBSD's equivalent) or whatever the underlying system used for that role.

Why the heck would you want to put GNOME in base? Regarding persons that use it on BSD, since there are OpenBSD developers porting GNOME to their OS I guess that there is interest in running GNOME on BSD.
Regarding Wayland, it is a protocol, it is not dependent on udev. You possibly mix that up with Weston.

[Vim_User]

I was replying to the post stating that they directly link to systemd libraries, which is not DBUS communication and therefore a hard dependeny, which can only be thrown out by either dropping the dependent code, switching to DBUS communication or implementing the needed functions yourself.
Therefore the question which it is.

Nevermind, I misunderstood your post at first. Stupid edit limit, Michael should really throw that out or at least extend it to something reasonable.

[Ericg]

Not to mention, the systemd pantheon keeps mushrooming outward, violating the principle of a limited, well defined function.

Except.. Its not. Everything like hostname control, journal, networking, all of that are separate processes with their own functions and jobs and limited permissions. Only thing they have in common is they are in the same source tree and thankfully all follow the same Dbus / API guidelines so that there is some unity and standardization amongst low level control.

[Scimmia]

• The BSD userland is mostly POSIX compliant and can be run on top of the Linux kernel, or the illumos kernel without much difficulty, unlike systemd on BSD, which will never happen at least for FreeBSD and OpenBSD, and I doubt illumos is interested either.

This one always gets me. People are really upset about software using advanced features available in the kernel? If so, new features would be useless, the kernel stagnates.

This is really the sticking point. You really believe that everything has to work on a 1980s Unix kernel and nothing new is allowed beyond drivers. That's fine, but the rest of us would like to move forward.

[Teho]

Well I meant not that systemd itself would fail if udev died, but anything depending on udev such as networkd or logind would die if udev died.

Eh? No they don't. The only thing that happens if you kill systemd-udevd is that systemd restarts it. Also you can use systemd and systemd-networkd in containers without even having systemd-udevd. Nothing happens to systemd-logind if systemd-udevd crashes.

[finalzone]

The BSDs base software consists of applications that perform a limited, well definined function. They're also independent of each other, if something in your cat binary breaks its not going to affect any other binary unless cat is a specific dependency. In systemd, they're all tied together. udev is the main duct-tape, glue, whatever term you'd want to use for systemd-udev. If anything breaks udev, the entire monolith breaks apart.

The BSDs distributions themselves are fragmented. FreeBSD, OpenBSD and DragonFly differ from each other lacking standard. Systemd took inspiration from BSD model to properly standardize the Linux core system.

The BSD userland is mostly POSIX compliant and can be run on top of the Linux kernel, or the illumos kernel without much difficulty, unlike systemd on BSD, which will never happen at least for FreeBSD and OpenBSD, and I doubt illumos is interested either.

POSIX is outdated and become irrelevant as long the consortium stall rather than taking account of modern technologies. Systemd is specifically designed for Linux kernel as a core, its developers clearly uninterested to BSD distributions free to port it as they wish.

[Rexilion]

Eh? No they don't. The only thing that happens if you kill systemd-udevd is that systemd restarts it. Also you can use systemd and systemd-networkd in containers without even having systemd-udevd. Nothing happens to systemd-logind if systemd-udevd crashes.

Yes, that would be my guess as well.

Well I meant not that systemd itself would fail if udev died, but anything depending on udev such as networkd or logind would die if udev died. systemd is the root of all processes and in an attack designed to take a server offline from a hacked user account, its the easiest target. Thats what I meant. In FreeBSD, init isn't a full blown process supervisor, and is much harder to get to, thats all.

Not to mention, the systemd pantheon keeps mushrooming outward, violating the principle of a limited, well defined function.

The systemd executable is quite limited in it's functionality. I would not consider it *huge*....

20:18 gebruiker@delta /usr/lib/systemd
==> ls -lah systemd
-rwxr-xr-x 1 root root 1014K 13 apr 09:07 systemd
20:18 gebruiker@delta /usr/lib/systemd
==> ldd systemd
linux-gate.so.1 (0xb774d000)
libpam.so.0 => /usr/lib/libpam.so.0 (0xb76f9000)
libcap.so.2 => /usr/lib/libcap.so.2 (0xb76f4000)
libkmod.so.2 => /usr/lib/libkmod.so.2 (0xb76dc000)
libseccomp.so.2 => /usr/lib/libseccomp.so.2 (0xb76cb000)
librt.so.1 => /usr/lib/librt.so.1 (0xb76c2000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb76a4000)
libpthread.so.0 => /usr/lib/libpthread.so.0 (0xb7687000)
libc.so.6 => /usr/lib/libc.so.6 (0xb74c5000)
/lib/ld-linux.so.2 (0xb772c000)
libdl.so.2 => /usr/lib/libdl.so.2 (0xb74c0000)
libattr.so.1 => /usr/lib/libattr.so.1 (0xb74ba000)
libz.so.1 => /usr/lib/libz.so.1 (0xb74a2000)

You're missing the point. What you're calling "systemd" doesn't exist; systemd isn't a single executable.
Systemd is a group of several components, and each one does a limited, well defined function.

What you're saying is comparable to saying "a music band violates the principle of a limited, well defined function because it plays more than one instrument".

Systemd actually is a single executable if you want. There is like 39 executables in /usr/lib/systemd in Arch. Each with their own configuration. But I guess that people more wonder about the project as a whole...