Live data from Hacker News

Without Systemd

without-systemd.org

81–89 of 89 posts

Re: Without Systemd

#81

Earlier quoted context omitted.

Extremely outdated. In the 15 versions since then, systemd has evolved quite tremendously with too many things to list succinctly.

Ok, I'll bite. What does systemd itself link to now?

  0x0000000000000001 (NEEDED)             Shared library: [libsystemd-daemon.so.0]
  0x0000000000000001 (NEEDED)             Shared library: [libudev.so.1]
  0x0000000000000001 (NEEDED)             Shared library: [libselinux.so.1]
  0x0000000000000001 (NEEDED)             Shared library: [librt.so.1]
  0x0000000000000001 (NEEDED)             Shared library: [libwrap.so.0]
  0x0000000000000001 (NEEDED)             Shared library: [libpam.so.0]
  0x0000000000000001 (NEEDED)             Shared library: [libaudit.so.1]
  0x0000000000000001 (NEEDED)             Shared library: [libcap.so.2]
  0x0000000000000001 (NEEDED)             Shared library: [libkmod.so.2]
  0x0000000000000001 (NEEDED)             Shared library: [libdbus-1.so.3]
  0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
  0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
  0x0000000000000001 (NEEDED)             Shared library: [ld-linux-x86-64.so.2]

They've replaced libattr with librt, otherwise the linked libraries are the same. Also, the package dependencies are the same.

What's this about being out of date? Systemd changes very fast, but no additional libraries are linked to and one was changed, and no additional package dependencies required.

I'll have a look at interface changes next.

Re: Without Systemd

#82

Earlier quoted context omitted.

Ok, I'll bite. What does systemd itself link to now?

0x0000000000000001 (NEEDED) Shared library: [libsystemd-daemon.so.0] 0x0000000000000001 (NEEDED) Shared library: [libudev.so.1] 0x0000000000000001 (NEEDED) Shared library: [libselinux.so.1] 0x0000000000000001 (NEEDED) Shared library: [librt.so.1] 0x0000000000000001 (NEEDED) Shared library: [libwrap.so.0] 0x0000000000000001 (NEEDED) Shared library: [libpam.so.0] 0x0000000000000001 (NEEDED) Shared library: [libaudit.so…

So, not that many major changes:

205:

* systemd-machined daemon added for VMs

* systemd-run utility added for transient units

* added scope, slice and transient units

* some new functions added

206:

* new features added

* no new binaries or files

207:

* new tool for save/restore backlight across reboots added

* variety of tweaks and changed - none effect the interface

208:

* tweaks, bug fixes but no interface changes or additional files/dependencies added

209:

* introduced systemd-networkd component

* systemd-socket-proxy for added to help services that can't support socket-activation natively

* rfkill utility added

* 3 new API headers

210, 211

* no new files, no interface changes, no dependency changes

212:

* systemd-journal-remote added

* some new functions added

* No new dependencies

213:

* new timesync daemon added

* new systemd-resolved added

214:

* Dependency on libattr dropped

215:

* no new files, no interface changes, no dependency change

216:

* networkctl tool added

* systemd-firstboot component added

* bus API changes for PolicyKit

* new library systemd-terminal added

* new tool systemd-journal-upload added

217:

* systemd-consoled daemon added

* multi-seat-x tool removed

218:

* no new files, no dependency changes

219:

* new API sd-hwdb.h added

* systemd-importd for importing container images into nspawn

Re: Without Systemd

#83

Earlier quoted context omitted.

I can't see why most people would want that, with the exception of replacing journald. Why strip out device init, or even timers? Swap init is less useful, but I don't see the harm. What is it that makes uselessd attractive? And why do you consider systemd to be bloated?

I like my init system to be an init system. However, the scope of systemd seems to expand monthly. I mean, you get an ntp client, a dhcp client, a logging system, and they apparently want to expand into containerized applications? I'd rather have a project with a smaller, well-defined scope.

You can turn these services off :-)

http://0pointer.de/blog/projects/three-levels-of-off

Re: Without Systemd

#84
post #13

Earlier quoted context omitted.

I like many things systemd has brought. However, I think the app-ification they are planning to deploy in Linux systems is extremely dangerous. Essentially they are implementing app bundles as containers [1]. All good lessons learnt from package managers? Gone. Nix? Forgotten. Imagine a heartbleed like scenario. In a controlled situation with a distro that uses a package manager this is easy to fix. Just upgrade the…

I get the impression, e.g. from Ubuntu's "new package format", that NIH aside (always a big factor with Ubuntu), that many of these efforts are mostly targeting "simple apps", i.e. standalone applications that don't require any kind of complicated wiring into the system. It looks like they'll still need a "real" package format to actually do things like update the system, install kernels, libraries, and dev stuff, et…

Anything about libc will apparently be handled by special "library" packages, or bundled with the "apps" themselves.

As for kernels and such, at least with Ubuntu Snappy this will be handles in a ChromeOS like fashion. Dump the updated base system into a separate partition, change the Grub config, reboot. If the system fails to boot up it will either instruct the user (i see no admins, nor "power-users" in this scenario) to pick the failsafe/recover option, or do so automatically.

Basically you can forget everything you learned about PC or server. The future is all containers and VMs. The computational equivalent of TV dinners or canned goods.

Re: Without Systemd

#85
post #18

Earlier quoted context omitted.

Similar feelings here, this "it kinda works"-feeling was the reason why I switched to Linux in the first place. What are your plans? Where do you go when you 'leave'?

To a distro that doesn't force things down the throats of its users in the same degree Ubuntu et al. do. e.g. Gentoo. (You can even run a FreeBSD kernel in Gentoo if you want.) That isn't to say it's been all rosy in Gentoo-land. It was an effort to keep Gnome3 off my system, to keep the existing Gnome2 versions of everything until MATE (and the Gentoo community packaging) was ready enough to replace Gnome2. But my s…

I do wonder how much effort and forks will be required to keep Gentoo, well, Gentoo going forwards, as more and more stuff either is either lumped into Systemd or depends on/assumes its presence.

One can already see how you at least have to keep the libsystemd package installed on Debian's latest, even if you use something other than systemd as the init etc, or else apt throws a tantrum.

http://ewontfix.com/15/ may be the most interesting read in all this. Notice how everything but dbus and the systemd lib have various issues. And if kdbus hits the kernel, systemd is poised to position itself as the mediator between (legacy) dbus and kdbus.

All in all there is some serious "one true way"-ism coming out of the systemd camp.

Re: Without Systemd

#86
post #31

Earlier quoted context omitted.

Pulseaudio had bugs which caused problems, but what in particular is it about the design of PA that is flawed?

Massively overdesigned while trying to solve a problem that almost no one had (network transparency). FreeBSD's implementation of /dev/dsp is a good example of how simple it can be.

Supposedly network transparency came later.

Best i could find, Poettering started work on Pulseaudio because he picked up a usb headset (basically a usb soundcard with tethered headset) and ran into issues with switching the IO streams around mid-use (say plugging it in while in the middle of a Skype call).

Not sure why he passed on using JACK though, or if it was not mature enough for him at that stage.

Also, i don't think Alsa had dmix (user-space software mixing) at that point in time.

As best i can find the one thing Alsa is missing is a interface other than .alsarc for configuring pr user virtual devices.

Re: Without Systemd

#87
post #79

Earlier quoted context omitted.

> I can imagine a future world in which package management tools understood containers Solaris has had this with zones since, IIRC, before Oracle bought Sun.

Oh god no! Zones are cool, but package management on Solaris is pretty bad. It has improved since they built something similar to Apt, but AFAIK it doesn't have the deep understanding of Zones that I'm suggesting is desirable.

On Solaris 10 package management was generally a pain, but there was a "sparse root" kind of zone that shares /usr with the global zone, so these get the updates automatically.

http://solaris.reys.net/zones-in-solaris-10-part-three-spars...

For OpenSolaris derived products with ipkg, the documentation says that "pkg update" in the global zone will update not only the global zone but all non-global zones as well.

https://docs.oracle.com/cd/E26502_01/html/E28984/gmhaa.html

Re: Without Systemd

#88

Earlier quoted context omitted.

I like my init system to be an init system. However, the scope of systemd seems to expand monthly. I mean, you get an ntp client, a dhcp client, a logging system, and they apparently want to expand into containerized applications? I'd rather have a project with a smaller, well-defined scope.

You can turn these services off :-) http://0pointer.de/blog/projects/three-levels-of-off

I know, but I still don't think they belong under the same umbrella.

Re: Without Systemd

#89

Earlier quoted context omitted.

Particularly that it doesn't work. I always hear about people for whom It Just Works, but that hasn't been the case for me over the course of a couple handfuls of machines. For what it's worth, LP and his gang seem like people for whom "it mostly works" is satisfactory, and that's not something I'm comfortable with in something like an init system, to be frank, because what about when it doesn't? The answer there unf…

Your implementation doesn't work. My question is what part of the design is flawed?

> Over the course of a couple handfuls of machines

That's more than "your implementation" considering that it spans at least ten machines across about the same number of distros including Fedora (and one FreeBSD). But it's cute that you're so quick to say it's "implementation" when it's clearly broken across so many different environments.

Pulseaudio is a stinking pile of shit.

Post reply on HN