Systemd 216 Piles On More Features, Aims For New User-Space VT

[energyman]

Do you want to build your own distro from scratch? If not, you don't have many options besides Gentoo and even then you can't just pick any GUI like you used to. Half of the GUI userland irreversibly depends on systemd now

nope.

Gnustep does not depend on systemd
KDE does not depend on systemd
enlightenment does not depend on systemd
xfce does not depend on systemd
lxqt does not depend on systemd

The only 'gui userland' that depends on systemd is Gnome3. Which is increasingly becoming irrelevant -and whose dependency can be worked around with a shim. Which just supports the notion that the dependency was introduced to force systemd unto the masses.

[energyman]

Final thoughts: at this point it's too late to discuss whether systemd is good or bad (unless you're into purely academic discussions like what NT would be without Win32 API). The freedom of choice is forever gone and distros are merely different labels slapped on what is actually the same product.

Bow to your corporate masters and adapt to systemd or stay independent and migrate to another OS. That's all, folks.

really?

* sys-apps/systemd
Available versions: 212-r5(0/2) 215-r3(0/2) **9999(0/2) {acl audit cryptsetup curl doc elfutils +filecaps +firmware-loader gcrypt gudev http idn introspection kdbus +kmod lz4 lzma pam policykit python qrcode +seccomp selinux ssl test vanilla xattr ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" ABI_S390="32 64" ABI_X86="32 64 x32" PYTHON_SINGLE_TARGET="python2_7 python3_2 python3_3 python3_4" PYTHON_TARGETS="python2_7 python3_2 python3_3 python3_4"}
Homepage: http://www.freedesktop.org/wiki/Software/systemd
Description: System and service manager for Linux

not installed. And I am not missing anything.

[interested]

This doesn't make any sense. BSD users shouldn't care, because it doesn't really effect them.

Oh, but it does. The *BSD projects never really contributed much to e.g. Desktop Environments like KDE/Gnome since they were GPL projects, but soon BSD developers will have to actually work in order to have fully functional DE's. This is why OpenBSD tries to partially clone systemd.

systemd will make it harder for *BSD forks to leech Linux software, especially in the long run. They will face the same choice as non-systemd Linux distros; either offer upstream projects similar features like logind and cgroups, and that means getting developers and start coding, or upstream projects will slowly cease supporting them.

[oleid]

Here's something to consider to judge systemd by. Suppose I want to use a different kernel/base system to run my GNU software and other compatible software, how much has systemd tied us into the "core os" to prevent us from doing that? And to those wondering there are other systems like the Genode framework and soon to be OS.

Depends. If genode was providing all the kernel interfaces (cgroups, kdbus, ...) it should run - obviously. As it doesn't provide the interfaces, one would have to port the PID1 portion of systemd and all the other stuff should work. I don't know, however, how much of dbus is really used in systemd and if a microkernel-native message bus could be used instead for communication. Possibly, one would have to create a message-bus adapter.

Actually, the more I think about it, systemd would make a nice porting layer considering it provides all a modern desktop needs. If genode was to provide systemd-ish interfaces and maybe Wayland, porting something like GNOME3 would probably be a lot easier.

[oleid]

Bow to your corporate masters and adapt to systemd or stay independent and migrate to another OS. That's all, folks.

I'm deeply bowing down to my grand master Arch, whoever that is and whyever he owns a Linux distribution. (head -> table)

[Guest]

really?

* sys-apps/systemd
Available versions: 212-r5(0/2) 215-r3(0/2) **9999(0/2) {acl audit cryptsetup curl doc elfutils +filecaps +firmware-loader gcrypt gudev http idn introspection kdbus +kmod lz4 lzma pam policykit python qrcode +seccomp selinux ssl test vanilla xattr ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" ABI_S390="32 64" ABI_X86="32 64 x32" PYTHON_SINGLE_TARGET="python2_7 python3_2 python3_3 python3_4" PYTHON_TARGETS="python2_7 python3_2 python3_3 python3_4"}
Homepage: http://www.freedesktop.org/wiki/Software/systemd
Description: System and service manager for Linux

not installed. And I am not missing anything.

1) you are a gentoo user
2) gentoo devs went into great lenghts to maintain separate udev fork (since udev was merged into systemd quite some time ago)
This however might not last, since udev fork is getting harder and harder to maintian since it's getting merged into systemd more than before and might no longer work without it.
3) other distros doesn't use udev fork (and most desktops are built around it), so they have systemd even if they don't use it as init (again, this might become impossible if lennart&sievers keep pushing their agenda).

[Guest]

thx balle

This....!!

[prodigy_]

Gnustep does not depend on systemd
KDE does not depend on systemd
enlightenment does not depend on systemd
xfce does not depend on systemd
lxqt does not depend on systemd

DEs are useless without applications, mate.

---

Why oh why every time I post on Phoronix forums it feels like I'm talking to a bunch of total retards...

[TheBlackCat]

with results of academic research made available to anyone without distinctions (individuals AND companies alike) - since research is already been paid for (if not actually funded by privates and corporations)

That the "results of academic research made available to anyone without distinctions" is a fairly recent concept that still hasn't gotten universal acceptance. You still need to pay to get the results of a lot of research. and you can't get the results of much research at all until after some time has elapsed. Although this is not the fault of scientists but rather the publishing industry.

[TheBlackCat]

KDE does not depend on systemd

KDE plasma workspaces is planning on using systemd socket activation for service management under wayland. Enlightenment also seems to support systemd socket activation for services, although it doesn't appear to require it yet. They are not being pressured to do so, there are no lower-level things that will break if they don't use socket activation. It is just a feature they find useful. I have brought this up to opponents of systemd dozens of times, and not once has any of them bothered to address this. The best I have gotten amounts to "I don't find the features of systemd useful, therefore nobody else should be allowed to use them."

Which is one thing that the anti-systemd crowd can't seem to accept: projects are using systemd voluntarily because it provides features they useful. Yes, there are cases where projects low in the stack voluntarily joined the systemd umbrella, and this has led to projects higher in the stack using it too (although that was also because the alternatives that once existed are unmaintained). However, this is far from the only reason, as those examples demonstrate. SUSE (pretty much the only major opponent of Red Hat) and Arch also adopted systemd very early on, long before it became such a fundamental part of the Linux stack.

The anti-systemd crowd seems to assume all projects fall into one of two categories: forced to use systemd against their will and red hat stooges. They just cannot wrap their head around the idea that systemd actually offers solutions people and projects want to use.

That seems to be the fundamental problem. It isn't that they refuse to do the work, it is that they refuse to recognize that there is actually demand out there for features that sysvinit doesn't offer. They are going to begin working on alternatives as long as they refuse to accept that there is demand for something more then sysv.