Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why systemd?

blog.jorgenschaefer.de

Post reply on HN
Print view View original

131–140 of 263 posts

Re: Why systemd?

#131

Post by cbsmith »

andrewflnr wrote: post #102
cbsmith wrote: post #91

Earlier quoted context omitted.

> We're to the point where certain software packages (GNOME comes to mind) are requiring hard dependencies on it. Wow... we've come a long way baby! Now freely available software that you can modify as needed without interference is taking away your freedom! ;-) > I was just today reading about some incompatibility that arises if your kernel is set up with no IPv6 support which is explicitly caused by systemd. Actual…

Call it flexibility, then. I don't think you can reasonably deny that a package that requires major surgery to work with a different init system is less flexible than one that simply doesn't care, even if said surgery is perfectly legal with the source available. That flexibility is a large part of why a lot of us came to Linux, and regardless of whether it's technically "freedom", losing it feels like losing freedom…

> I don't think you can reasonably deny that a package that requires major surgery to work with a different init system is less flexible than one that simply doesn't care, even if said surgery is perfectly legal with the source available.

I think you'll find that it isn't nearly that difficult a problem to address. For all kinds of reasons, just like every other system design that has come before it, there will need to be accommodations made to work with other stuff. Its not like the old code just disappears overnight. You can't succeed as a new platform without a way of working with the old (and again, you've mostly been sold a bill of goods... most of systemd's architecture is the old system).

> That flexibility is a large part of why a lot of us came to Linux, and regardless of whether it's technically "freedom", losing it feels like losing freedom.

If it feels like losing freedom to you, you don't know what that is about. You're losing someone writing code the way you wanted them to. That's not losing freedom. That's getting it.

Re: Why systemd?

#132

Post by ash »

chousuke wrote: post #127
rjsw wrote: post #119

Earlier quoted context omitted.

Why would booting be slower ? My BSD systems boot quickly enough for me.

My FreeBSD system has a 30-second timeout during which the entire boot process is halted because it waits for a default route to the internet... which it won't get, because I haven't configured one. It's pretty dumb, and not enough of a problem for me that I'd figure out how to work around it, but it's a pretty good example.

I don't think this 30-second timeout is a bug in FreeBSD or in rc. You may want your server to wait for the network to become available. Ubuntu Server has the same "waiting for network" timeout:

http://askubuntu.com/questions/63456/waiting-for-network-con...

Re: Why systemd?

#133

Post by chousuke »

lmm wrote: post #122
navait wrote: post #42

Earlier quoted context omitted.

This init process debate has brought out one of the worst elements of people in the FOSS community: treating some FOSS technology as an extension of their identity. Let's keep some perspective here. We are literally just talking about an init system. There are many others you can use. systemd is not taking away your freedom in any meaningful sense of the word "freedom". Debates should be about the technical merits of…

> systemd is not taking away your freedom in any meaningful sense of the word "freedom" Systemd has made it impossible for me to run an up-to-date Gnome on FreeBSD. That feels a lot like taking away my freedom.

You're blaming the wrong party here.

The systemd project has no control over what Gnome relies on. They independently rely on systemd because it provides functionality that makes their lives easier, and it's their right to do that. If you want "up-to-date Gnome" to work on FreeBSD, go and write some code to help make it happen.

Re: Why systemd?

#134

Post by clarry »

albertzeyer wrote: post #128
clarry wrote: post #101

Earlier quoted context omitted.

Yes, modern linux and sysvinit are pigs compared to some alternatives (though systemd is worse). The choice isn't a binary choice between sysvinit and systemd. How about this? init + rc + all the scripts combined are smaller than your handful of daemon-specific scripts. And I understand exactly how all of this works (the kernel parts included). I can easily change any part of it, I can easily debug any part of it, I…

I think you also need to count the Bash source code there.

That's not really fair since the shell is an independent part of the system and could be swapped out for another implementation. Plus, it's not there just for the init system; it'd be there regardless of the init system. It's an already existing independent component, which is used for leverage.

Otherwise should we also count the C compiler, libc, all the CLI utilities and the kernel?

But here you go. Still smaller than systemd. Sysvinit needs a shell too...

    $ wc -l /usr/src/bin/ksh/*.[ch]
     127 /usr/src/bin/ksh/alloc.c
    1412 /usr/src/bin/ksh/c_ksh.c
     935 /usr/src/bin/ksh/c_sh.c
     560 /usr/src/bin/ksh/c_test.c
      53 /usr/src/bin/ksh/c_test.h
     201 /usr/src/bin/ksh/c_ulimit.c
      60 /usr/src/bin/ksh/config.h
     829 /usr/src/bin/ksh/edit.c
      86 /usr/src/bin/ksh/edit.h
    2163 /usr/src/bin/ksh/emacs.c
    1333 /usr/src/bin/ksh/eval.c
    1433 /usr/src/bin/ksh/exec.c
     107 /usr/src/bin/ksh/expand.h
     593 /usr/src/bin/ksh/expr.c
     984 /usr/src/bin/ksh/history.c
     438 /usr/src/bin/ksh/io.c
    1653 /usr/src/bin/ksh/jobs.c
      13 /usr/src/bin/ksh/ksh_limval.h
    1643 /usr/src/bin/ksh/lex.c
     132 /usr/src/bin/ksh/lex.h
     196 /usr/src/bin/ksh/mail.c
     786 /usr/src/bin/ksh/main.c
    1149 /usr/src/bin/ksh/misc.c
      91 /usr/src/bin/ksh/mknod.c
     285 /usr/src/bin/ksh/path.c
     267 /usr/src/bin/ksh/proto.h
     420 /usr/src/bin/ksh/sh.h
    1161 /usr/src/bin/ksh/shf.c
      82 /usr/src/bin/ksh/shf.h
     897 /usr/src/bin/ksh/syn.c
     231 /usr/src/bin/ksh/table.c
     183 /usr/src/bin/ksh/table.h
     420 /usr/src/bin/ksh/trap.c
     708 /usr/src/bin/ksh/tree.c
     141 /usr/src/bin/ksh/tree.h
      57 /usr/src/bin/ksh/tty.c
      37 /usr/src/bin/ksh/tty.h
    1210 /usr/src/bin/ksh/var.c
      10 /usr/src/bin/ksh/version.c
    2128 /usr/src/bin/ksh/vi.c
   25214 total

Re: Why systemd?

#135

Post by e12e »

bwood wrote: post #59
nextos wrote: post #3

We often criticise systemd for being too bloated, and making it hard to write a drop in replacement. I totally agree with this line of thought. However, in my mind it has made several awesome things possible. My boot time got dramatically shorter when I adopted it thanks to parallelization. Besides, daemons have now simple and robust service definitions. Sys V had become a mess! Lastly, lightweight containers are the…

> Lastly, lightweight containers are the real-deal for small development tasks (not for production!). I've come across this sentiment a few times in the last month, but I haven't yet heard an explanation other than "VMs are battle-tested and containers might leak data to each other". Is there something more that I'm missing? Why aren't containers a good idea to use in production?

If we (fairly or unfairly) group Linux' LXC (eg: docker) and * bsd's jails, the main contrast with "proper" hypervisors (xen/kvm/vmware/bhyve(? That new thing in freebsd 10?) is (the possibility of) full resource accounting/limitation. Go ahead run you pi-digit-finder at "100%" cpu, pipe /dev/zero over an ssh pipe to /dev/null on some box and pipe it to a local file as well: no other vm or the host will notice. You only get 1mbs, x cycles of cpu and x mb of disk.

Secondly, assuming a bug in the kernel, one might assume root in a container can lead to root on the host. Bsd jails have been pretty solid for the last few years afaik - but hardware support for virtualization might still get more of both separation/safety and speed. There have been som bad bugs in (as i recall) the io system in xen, leading to similar issues ... but again the last time i saw anything on that was years ago.

Ymmv - generally docker doesn't have "run untrusted code, safely, as root" as a design-goal (yet, afaik) (not entirely sure about lxc, née vserver -- the underlying technology) -- so don't expect it to do that. Isolation and security (esp. without sacrificing performance) is very hard to get right. Or so a long series of privilege escalation exploits across many different os' seem to indicate.

Re: Why systemd?

#136

Post by RexRollman »

allegory wrote: post #103
ultramancool wrote: post #63

Earlier quoted context omitted.

Well said. I recently migrated to FreeBSD after trying sytemd on Arch and seeing that Debian and Ubuntu are planning to move too. The dead simple rc.conf file seems so much nicer than the stuff I was dealing with in the entire world of Linux-based systems, like going back to the way Arch used to be when I really liked it.

This. The FreeBSD rc system just works, is well documented and is small enough to understand by one person without too much effort.

I've been tinkering with NetBSD the last couple of weeks in a VMWare Fusion virtual machine and the RC system it uses it very nice. OpenBSD's is nice as well.

Re: Why systemd?

#137

Post by lmm »

chousuke wrote: post #133
lmm wrote: post #122

Earlier quoted context omitted.

> systemd is not taking away your freedom in any meaningful sense of the word "freedom" Systemd has made it impossible for me to run an up-to-date Gnome on FreeBSD. That feels a lot like taking away my freedom.

You're blaming the wrong party here. The systemd project has no control over what Gnome relies on. They independently rely on systemd because it provides functionality that makes their lives easier, and it's their right to do that. If you want "up-to-date Gnome" to work on FreeBSD, go and write some code to help make it happen.

What are my real options?

I could write patches that reimplement the functionality that Gnome gets from systemd using lower-level functionality, in a cross-platform way. But those patches would be rejected; the Gnome project has decided to use systemd and would not want to duplicate its code. If I were to maintain my own gnome fork I would have to convince distributions to adopt it.

I could write patches that add FreeBSD support to systemd. But those patches would be rejected - again, as a policy decision, systemd doesn't want to support FreeBSD. Thankfully in this case there is a fork, uselessd, but again, we need to convince distributions to adopt it or it's meaningless.

The claim that Gnome "independently" relies on systemd is specious; there was a lot of lobbying and politics from the systemd side. My only practical option is to counter at the same level, and lobby Gnome (and linux distributions) to make the political decision to move away from systemd.

Re: Why systemd?

#138

Post by walterbell »

clarry wrote: post #130
lmm wrote: post #122

Earlier quoted context omitted.

> systemd is not taking away your freedom in any meaningful sense of the word "freedom" Systemd has made it impossible for me to run an up-to-date Gnome on FreeBSD. That feels a lot like taking away my freedom.

There's legal freedom, and there's practical freedom. Sadly, the latter is seldom talked about. You can be stuck in a maze, in a pit or under a tree trunk. You're legally free, since no law or copyright license is saying may not get out. Yet, you're stuck and if you can't get out, you're not free at all. When it comes to software, it is the size, complexity and complicated interdependencies that make the maze. As the…

> "the trend seems to be that all aspects of a modern OS are getting larger and more complicated. A little here, a little there, it all adds up and becomes a lot, everywhere. It's a sad trend."

Some hypervisor-based systems are moving in the opposite direction, with unikernels that reduce or eliminate the OS to run directly on virtual hardware: Cloudius OSv, HalVM, OpenMirage, Erlang on Xen.

Re: Why systemd?

#139

Post by e12e »

jsnell wrote: post #49
audidude wrote: post #27

Earlier quoted context omitted.

> Opaque C code that sits in 20 binaries and some man pages don't help you a lot if have to debug an issue. It's okay from a user perspective but with systemd (or other systems that rely on in this principle) you need to start reading c-code, start gdb, deal with dbus... if it's a toolbox of scripts a `grep -r ` is often the first step on the way to understand and learn something and fix the problem. What's opaque ab…

My machine with systemd (FC20) doesn't boot up at all unless systemd loglevel is set to debug on the command line. Even with it it takes about 5 minutes to boot. Luckily I don't need to reboot often, but every single time there's a small fear that some upgrade has made systemd crap up even worse, and the system won't boot at all. How do you debug a complete black box, where turning on debugging partly fixes the probl…

Reminds me of the joyful early days of moving from grub to lilo. Grub was (is) more fragile due to being more complex -- but at least the grub shell gives more information than lilo failing at "LI"...

Grub always seemed like the improved features made up for the added complexity; I'm not convinced about systemd.

Re: Why systemd?

#140

Post by walterbell »

bwood wrote: post #59
nextos wrote: post #3

We often criticise systemd for being too bloated, and making it hard to write a drop in replacement. I totally agree with this line of thought. However, in my mind it has made several awesome things possible. My boot time got dramatically shorter when I adopted it thanks to parallelization. Besides, daemons have now simple and robust service definitions. Sys V had become a mess! Lastly, lightweight containers are the…

> Lastly, lightweight containers are the real-deal for small development tasks (not for production!). I've come across this sentiment a few times in the last month, but I haven't yet heard an explanation other than "VMs are battle-tested and containers might leak data to each other". Is there something more that I'm missing? Why aren't containers a good idea to use in production?

> Why aren't containers a good idea to use in production?

See Dan Walsh articles here: http://www.projectatomic.io/blog/2014/09/yet-another-reason-...

Post reply on HN