4 ms·

Nice project! Even if you believe that systemd is too complicated, it's a great example on how to build an asynchronous, modern init system. Upstart uses some h

by _yy 11y ago

Nice project! Even if you believe that systemd is too complicated, it's a great example on how to build an asynchronous, modern init system. Upstart uses some highly questionable tricks (ptrace!) to track processes across forks whereas systemd uses cgroups.

pjmlp 11y ago
Not only that, it is a nice example of using Go in a role that many would use C for, so it might convince a few to try their hands to safer programming languages. Next step, bare metal runtime! :)
- lmm 11y ago
  Is there even any concurrency in this case? Wouldn't e.g. OCaml be a better choice?
  - commentzorro 11y ago
    What benefit would adding the overhead of learning OCaml be to this project? It's not like a functional or immutable language would add any value here, would it?!
    - lmm 11y ago
      Even at this 3-line stage, the stateful log.SetOutput construct is ugly and error-prone. So I'd say a functional/immutable language would already be adding value, and that would only increase as the amount of code grows. At a minimum an init is going to involve parsing config and something similar to a state machine, both good use cases for functional languages.
      - groovy2shoes 11y ago
        Init's job is to start the init scripts and then hang around to foster orphan processes. Ideally, it should not be parsing configs, but should spawn another process to do that sort of work. A good PID 1 is very, very minimal.
        lmm 11y ago
        This project isn't just a PID1 though, it's a full system. (Well at the moment it's a hello world, but that's the intent)
    - jerf 11y ago
      When C is taken as the baseline, there's a very long list of languages that look better for this sort of program. I don't see a huge reason that init has to be C, or even particularly benefits from it. (Specific init implementations may have the advantage of being battle-tested, but that's a characteristic of the program and time, not implementation language per se.)
    - davexunit 11y ago
      Using high-level languages for init systems is a great idea. In fact, we do this for the Guix System Distribution. Our init system is called GNU Shepherd, and it's written in Guile Scheme. It's great because you write services as Scheme code. For example, I have a number of Ruby web servers that I run for development at work that are nearly identical. Since services are first-class Scheme objects, I wrote a simple function that returns a service object for running a Ruby web server, specialized for a given application. For this workflow, I run Shepherd as an unprivileged user and additionally manage all of my user services like gpg-agent, emacs daemon, offlineimap, etc. No crappy external domain specific language to learn; data is code. Highly recommended. http://www.gnu.org/software/shepherd/ http://www.gnu.org/software/shepherd/
  - pjmlp 11y ago
    Personally I would use OCaml over Go, as I prefer expressive languages. However given Oberon's influence on Go, I find positive other devs that like Go, do use it for such purposes. OCaml already has MirageOS advertising it for system level coding. :) Edit: Regarding concurrency, even systems programming languages older than C have built in support for concurrency. C and C++ are probably the outsiders in terms of built-in support for concurrency, language or std libs.
  - JoachimSchipper 11y ago
    If you want to build a system that can survive out-of-memory conditions, you need to implement init so that it doesn't allocate memory at semi-random moments. Both Go and OCaml will fight you on that requirement. (IIRC, Go is designed to allocate memory the moment your stack grows too deep - which is usually a good idea, but not here.) Of course, very few Unices actually survive out-of-memory - Linux runs an OOM killer by default, OpenBSD tends to crash the kernel, etc. Apparently Solaris does have a good story here. (Of course, you'd have to ensure that the system doesn't spend all its time swapping, regardless.)
  - rakoo 11y ago
    Erlang would look be a very interesting choice here, seeing how any Erlang system is basically a miniature OS. It even has an init already.
vezzy-fnord 11y ago
cgroups are overkill for process tracking, per se. The Linux kernel has the Netlink proc connector for that purpose. Subscribing to cgroupfs entails a much higher cognitive and resource load in having to deal with a hierarchical resource management subsystem altogether. Upstart is much more readable even though it has various idiosyncrasies.
- digi_owl 11y ago
  I get the impression that the primary reason for systemd using cgroups was "security". This in that it provided the means of namespace isolating daemons. This in turn because if you follow Poetterings project history it starts with him creating Pulseaudio to handle moving between sound devices while in use, then crated Avahi to provide a means of Pulseaudio equipped computers to find each other on a network, and then came Systemd based on what he learned about daemon security while writing Avahi. Sadly i can't shake the feeling that the security in systemd is all too often leaning towards "security theater".

by _yy 11y ago

pjmlp 11y ago

Not only that, it is a nice example of using Go in a role that many would use C for, so it might convince a few to try their hands to safer programming languages. Next step, bare metal runtime! :)

lmm 11y ago
Is there even any concurrency in this case? Wouldn't e.g. OCaml be a better choice?
- commentzorro 11y ago
  What benefit would adding the overhead of learning OCaml be to this project? It's not like a functional or immutable language would add any value here, would it?!
  - lmm 11y ago
    Even at this 3-line stage, the stateful log.SetOutput construct is ugly and error-prone. So I'd say a functional/immutable language would already be adding value, and that would only increase as the amount of code grows. At a minimum an init is going to involve parsing config and something similar to a state machine, both good use cases for functional languages.
    - groovy2shoes 11y ago
      Init's job is to start the init scripts and then hang around to foster orphan processes. Ideally, it should not be parsing configs, but should spawn another process to do that sort of work. A good PID 1 is very, very minimal.
      - lmm 11y ago
        This project isn't just a PID1 though, it's a full system. (Well at the moment it's a hello world, but that's the intent)
  - jerf 11y ago
    When C is taken as the baseline, there's a very long list of languages that look better for this sort of program. I don't see a huge reason that init has to be C, or even particularly benefits from it. (Specific init implementations may have the advantage of being battle-tested, but that's a characteristic of the program and time, not implementation language per se.)
  - davexunit 11y ago
    Using high-level languages for init systems is a great idea. In fact, we do this for the Guix System Distribution. Our init system is called GNU Shepherd, and it's written in Guile Scheme. It's great because you write services as Scheme code. For example, I have a number of Ruby web servers that I run for development at work that are nearly identical. Since services are first-class Scheme objects, I wrote a simple function that returns a service object for running a Ruby web server, specialized for a given application. For this workflow, I run Shepherd as an unprivileged user and additionally manage all of my user services like gpg-agent, emacs daemon, offlineimap, etc. No crappy external domain specific language to learn; data is code. Highly recommended. http://www.gnu.org/software/shepherd/ http://www.gnu.org/software/shepherd/
- pjmlp 11y ago
  Personally I would use OCaml over Go, as I prefer expressive languages. However given Oberon's influence on Go, I find positive other devs that like Go, do use it for such purposes. OCaml already has MirageOS advertising it for system level coding. :) Edit: Regarding concurrency, even systems programming languages older than C have built in support for concurrency. C and C++ are probably the outsiders in terms of built-in support for concurrency, language or std libs.
- JoachimSchipper 11y ago
  If you want to build a system that can survive out-of-memory conditions, you need to implement init so that it doesn't allocate memory at semi-random moments. Both Go and OCaml will fight you on that requirement. (IIRC, Go is designed to allocate memory the moment your stack grows too deep - which is usually a good idea, but not here.) Of course, very few Unices actually survive out-of-memory - Linux runs an OOM killer by default, OpenBSD tends to crash the kernel, etc. Apparently Solaris does have a good story here. (Of course, you'd have to ensure that the system doesn't spend all its time swapping, regardless.)
- rakoo 11y ago
  Erlang would look be a very interesting choice here, seeing how any Erlang system is basically a miniature OS. It even has an init already.

vezzy-fnord 11y ago

cgroups are overkill for process tracking, per se. The Linux kernel has the Netlink proc connector for that purpose. Subscribing to cgroupfs entails a much higher cognitive and resource load in having to deal with a hierarchical resource management subsystem altogether. Upstart is much more readable even though it has various idiosyncrasies.

digi_owl 11y ago
I get the impression that the primary reason for systemd using cgroups was "security". This in that it provided the means of namespace isolating daemons. This in turn because if you follow Poetterings project history it starts with him creating Pulseaudio to handle moving between sound devices while in use, then crated Avahi to provide a means of Pulseaudio equipped computers to find each other on a network, and then came Systemd based on what he learned about daemon security while writing Avahi. Sadly i can't shake the feeling that the security in systemd is all too often leaning towards "security theater".