5 ms·

SystemD makes me feel weird. When I boot Debian 8 (which has systemd) I'm amazed how quickly it boots. Systemd units are nice. SysVinit was a mess. I wish I c

by smcleod 12y ago

SystemD makes me feel weird. When I boot Debian 8 (which has systemd) I'm amazed how quickly it boots. Systemd units are nice. SysVinit was a mess. I wish I could interrupt stuck processes when booting / shutting down: http://i.imgur.com/a4ImjAk.jpg http://i.imgur.com/a4ImjAk.jpg When someone comments about how overly complex and controlling systemd is for an init system, I think of all the hideous shell scripts that don't talk to their neighbors which end up forming most the sysvinit boot process on many distros (in the past?). I wish there was something [lighter|simpler|more portable|more unix] than systemd. Every time I seed something [good|bad] about systemd it makes me want to [comment|upvote|walk away].

digi_owl 12y ago
There have been several over the years, but none of them had RH riding shotgun.
- deleted 12y ago
  [deleted]
vezzy-fnord 12y ago
I wish there was something [lighter|simpler|more portable|more unix] than systemd. Your best bets are probably s6 or nosh. If you want just a service framework without init, then you can look at OpenRC, too. http://skarnet.org/software/s6/ http://skarnet.org/software/s6/ http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/nosh.html http://homepage.ntlworld.com/jonathan.deboynepollard/Softwar...
- mrmondo 12y ago
  Thanks for the links - I'm sticking with Debian for now so I guess I'm using systemd for the foreseeable future there, which I [do|dont] have a problem with. systemd hasn't failed me yet - it really does just make me feel 'weird'.
  - anonbanker 12y ago
    feeling uneasy about a software decision you didn't make is one of the reason many of us switched from Windows to Linux in the first place. It's a little weird seeing people make the same rationalizations I made with Windows.
joshuapants 12y ago
There's always http://smarden.org/runit/ http://smarden.org/runit/
cturner 12y ago
> SysVinit was a mess. Not just SysV - every attempt to move beyond BSD-style init has been a mess. > I wish there was something [lighter|simpler|more portable|more unix] than systemd. I think the trick with systemd is to realise that it's not unix. But it's something else that's really interesting in its own right. Init/scheduling is a much more difficult problem than it first appears, and it has always and everywhere been tacked on to its host OS as an afterthought: init scripts, cron, windows services, system v init. All are poor, partial solutions. Yuck. To fill the void, there has been a proliferation of application containers, each of which does a different 70% of the general problem. All of this stuff could just be done in the platform. And that's what systemd is. There's going to be two separate camps at the end of this: a group led by the BSD platforms will stick to convenitional unix goals. On the other side, the linux kernel plays second-fiddle to systemd. The systemd service graph is a new operating system tradition. [New, but not without precedent: in the debian world, the 'apt' package management system has become more significant than the kernel. You can create things that are not linux, but which are still debian. Both systemd and apt use a sophisticated data-graph to contain a difficult problem.] There are exciting opportunities for developers on a systemd operating system: you'll be able to quickly put together application stacks using microservices in a way that hasn't been practical until now. It /is/ unixy in the sense that it gives the console operator a powerful new general-purpose tool.
- vezzy-fnord 12y ago
  I don't follow. Application containers were born out of a variety of reasons, but primarily seem to be oriented around partitioning a host OS into individual resource namespaces each with its own library context. Thus, an attempt to address the fact that the host OS is deficient in providing a multi-tenant experience out of the box. In fact, application container deployments frequently don't use an init and process supervisor at all, but when they do it's a bare minimum loop that reaps zombies and reexecs a process on SIGCHLD. On the linux side, the kernel will start to play second fiddle to the systemd. That much is true, for better or for worse. systemd and much of the new desktop userland is refactoring a lot of kernel components into userspace, creating the de facto equivalent of an unwieldy hybrid kernel. I suppose Tanenbaum did win that debate, after all. Sort of. in the debian world, the package management system has become more significant than the kernel. The package management infrastructure is basically what makes a Linux distribution a "distribution". It's the backbone. That you can create Debian stacks based on non-Linux kernels is because many Linux packages are cross-Unix. as a development platform you'll be able to quickly put together application stacks using microserves in a way that hasn't been practical until now Wikipedia defines microservices as: In computing, microservices is a software architecture style, in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs. These services are small, highly decoupled and focus on doing a small task. That sounds a lot like... the Unix philosophy, which you openly admit systemd is in opposition to. It seems like a daemontools-style toolkit approach (e.g. s6, nosh, perp, runit, etc.) fits the "microservices" umbrella far better. Indeed, I've been seeing plenty of container configurations based on those tools.
cpncrunch 12y ago
For the servers I run, boot time isn't an issue. I might reboot a server once a year, and booting in 10 seconds vs 40 seconds isn't really an issue. What is an issue for me is stability. I don't really care about "hideous shell scripts" as long as they work.
- hobarrera 12y ago
  But linux isn't all about servers, there's a lot of desktop users out there. And having desktop and server diverge at a kernel/init level seems too much burden to maintain.
  - felixgallo 12y ago
    no, there are almost no desktop users out there; certainly, far fewer, probably by two orders of magnitude, than server and embedded installations; and the divergence in favor of doing things the desktop developers' way is very much the tail wagging the dog.
- rwmj 12y ago
  Virtual machines, containers and appliances all require very short boot times, because they may be created and booted frequently.
  - digi_owl 12y ago
    Sometimes it feels as if these would be better served with the age old DOS flat files than something as convoluted as a *nix init. This because if a "service"/daemon fails to come up, you may as well scuttle the whole VM/container/appliance and spin up another in its place.

by smcleod 12y ago

digi_owl 12y ago

There have been several over the years, but none of them had RH riding shotgun.

deleted 12y ago
[deleted]

vezzy-fnord 12y ago

I wish there was something [lighter|simpler|more portable|more unix] than systemd. Your best bets are probably s6 or nosh. If you want just a service framework without init, then you can look at OpenRC, too. http://skarnet.org/software/s6/ http://skarnet.org/software/s6/ http://homepage.ntlworld.com/jonathan.deboynepollard/Softwares/nosh.html http://homepage.ntlworld.com/jonathan.deboynepollard/Softwar...

mrmondo 12y ago
Thanks for the links - I'm sticking with Debian for now so I guess I'm using systemd for the foreseeable future there, which I [do|dont] have a problem with. systemd hasn't failed me yet - it really does just make me feel 'weird'.
- anonbanker 12y ago
  feeling uneasy about a software decision you didn't make is one of the reason many of us switched from Windows to Linux in the first place. It's a little weird seeing people make the same rationalizations I made with Windows.

joshuapants 12y ago

There's always http://smarden.org/runit/ http://smarden.org/runit/

cturner 12y ago

> SysVinit was a mess. Not just SysV - every attempt to move beyond BSD-style init has been a mess. > I wish there was something [lighter|simpler|more portable|more unix] than systemd. I think the trick with systemd is to realise that it's not unix. But it's something else that's really interesting in its own right. Init/scheduling is a much more difficult problem than it first appears, and it has always and everywhere been tacked on to its host OS as an afterthought: init scripts, cron, windows services, system v init. All are poor, partial solutions. Yuck. To fill the void, there has been a proliferation of application containers, each of which does a different 70% of the general problem. All of this stuff could just be done in the platform. And that's what systemd is. There's going to be two separate camps at the end of this: a group led by the BSD platforms will stick to convenitional unix goals. On the other side, the linux kernel plays second-fiddle to systemd. The systemd service graph is a new operating system tradition. [New, but not without precedent: in the debian world, the 'apt' package management system has become more significant than the kernel. You can create things that are not linux, but which are still debian. Both systemd and apt use a sophisticated data-graph to contain a difficult problem.] There are exciting opportunities for developers on a systemd operating system: you'll be able to quickly put together application stacks using microservices in a way that hasn't been practical until now. It /is/ unixy in the sense that it gives the console operator a powerful new general-purpose tool.

vezzy-fnord 12y ago
I don't follow. Application containers were born out of a variety of reasons, but primarily seem to be oriented around partitioning a host OS into individual resource namespaces each with its own library context. Thus, an attempt to address the fact that the host OS is deficient in providing a multi-tenant experience out of the box. In fact, application container deployments frequently don't use an init and process supervisor at all, but when they do it's a bare minimum loop that reaps zombies and reexecs a process on SIGCHLD. On the linux side, the kernel will start to play second fiddle to the systemd. That much is true, for better or for worse. systemd and much of the new desktop userland is refactoring a lot of kernel components into userspace, creating the de facto equivalent of an unwieldy hybrid kernel. I suppose Tanenbaum did win that debate, after all. Sort of. in the debian world, the package management system has become more significant than the kernel. The package management infrastructure is basically what makes a Linux distribution a "distribution". It's the backbone. That you can create Debian stacks based on non-Linux kernels is because many Linux packages are cross-Unix. as a development platform you'll be able to quickly put together application stacks using microserves in a way that hasn't been practical until now Wikipedia defines microservices as: In computing, microservices is a software architecture style, in which complex applications are composed of small, independent processes communicating with each other using language-agnostic APIs. These services are small, highly decoupled and focus on doing a small task. That sounds a lot like... the Unix philosophy, which you openly admit systemd is in opposition to. It seems like a daemontools-style toolkit approach (e.g. s6, nosh, perp, runit, etc.) fits the "microservices" umbrella far better. Indeed, I've been seeing plenty of container configurations based on those tools.

cpncrunch 12y ago

For the servers I run, boot time isn't an issue. I might reboot a server once a year, and booting in 10 seconds vs 40 seconds isn't really an issue. What is an issue for me is stability. I don't really care about "hideous shell scripts" as long as they work.

hobarrera 12y ago
But linux isn't all about servers, there's a lot of desktop users out there. And having desktop and server diverge at a kernel/init level seems too much burden to maintain.
- felixgallo 12y ago
  no, there are almost no desktop users out there; certainly, far fewer, probably by two orders of magnitude, than server and embedded installations; and the divergence in favor of doing things the desktop developers' way is very much the tail wagging the dog.
rwmj 12y ago
Virtual machines, containers and appliances all require very short boot times, because they may be created and booted frequently.
- digi_owl 12y ago
  Sometimes it feels as if these would be better served with the age old DOS flat files than something as convoluted as a *nix init. This because if a "service"/daemon fails to come up, you may as well scuttle the whole VM/container/appliance and spin up another in its place.