Announcement

Collapse
No announcement yet.

Systemd 215 Works On Factory Reset, DHCPv4 Server Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #31
    Originally posted by haplo602 View Post
    Since when would embedded systems where space is usualy a premium item use a bloated thing like systemd is quickly heading to ?
    First, systemd isn't bloated by any reasonable definition of bloat. It is impressively small, even with all features turned on. It also replaces a lot of other programs like Cron, syslog etc. making to total system size very comparable depending on which features are needed.

    systemd is also very modular, so you can remove most features with compile options, making the effective size of systemd very small.

    Basically, if the embedded system has too little permanent storage for systemd, Linux itself is only a marginally fit.

    Secondly, embedded are much more than routers with only 4mb flash storage. There are probably millions of SmartTV's sold every month, and most of them runs Linux. Systemd is a prefect fit for such systems and probably much better that any internally maintained toolboxes that the SmartTV developers use.

    systemd can also offer much better stability and robustness to embedded systems. It has a total supervising chain; a hardware watchdog supervises systemd itself, while systemd supervises all processes; if a process hang, it can be restarted automatically without user intervention. I think the many router owners who are used to restart their hanging routers once in awhile would appreciate such supervision.

    Also, systemd is also easily capable of only running services when needed, so it only launches e.g. sshd or the http Web GUI when the user actually needs it, reducing overall drain on system resources.

    All in all, systemd easily out-competes any other init systemd for embedded devices, and it enables advanced COTS features that are supported upstream, which reduce developer cost (time to market, maintenance) compared to in-house developed toolboxes.

    Originally posted by haplo602 View Post
    It is either a generaly used and usefull feature, ot it should have a dedicated implementation. I still fail to see the benefit of integrating this feature into systemd. Any kind of reproducible system has 2 requirements:

    1. Non-volatile and non-modifiable storage for base system (i.e. read-only /usr)
    2. Appendable configartion area (you simply cut the addon modifications during a reset)

    Systemd does not serve either ....
    I must say I not sure exactly what you are talking about here. What feature do you think is being integrated into systemd? Is it Factory Resets or Reproducible Systems? Have you actually read Poettering's blog explaining this? It seems not by the look of it.

    I will provide the link again for your perusal:
    "Factory Reset, Stateless Systems, Reproducible Systems & Verifiable Systems"

    Comment


    • #32
      How about using this to sandbox browsers?

      Originally posted by DrYak View Post
      It also makes possible, when combined with LXC and all the facilities that systemd has for lxc, to create very light-weight and quickly initiated containers.
      Think about a way to quickly jail anything you want inside a separate chroot. (like jails, etc.)

      Excpet that, thanks to systemd, you get that chroot completely filled up and indistinguishable from the inside from any actual machine.

      You don't trust skype ? These kind of facilities in systemd will create quickly a stateless linux container in which to run your skype. you only keep your skype installation and skype configuration, everything is ephermal single-use throw away environment.
      This sort of sandboxing could be used to defeat browser-borne attacks that read hardware information such as any port of the FBI's CIPAV spyware programs to Linux. Also would
      confine privilige escalation attacks to write to the system unless the attacker is good enough to first recognize that they are "in jail," then manage to break out of the chroot.

      Yet another use is attack-proofing public computers, so a simple reboot kills any problems from a previous user. One community college whose Internet access I used to poach somehow managed to do this in Windows as though they were running from live disks, I was very impressed with that. Was good for privacy too: just mash the button if you needed to remove your work and all software you had added, due to this they were able to allow a lot of user software to be installed if it did not require driver installation privilige levels.
      Last edited by Luke; 10 July 2014, 11:59 PM.

      Comment

      Working...
      X