Announcement

Collapse
No announcement yet.

Systemd Change Allows For Stateless Systems With Tmpfs

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

  • Systemd Change Allows For Stateless Systems With Tmpfs

    Phoronix: Systemd Change Allows For Stateless Systems With Tmpfs

    A change made to systemd yesterday is working on the stateless Linux systems feature...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    It's pretty easy to set up a "factory reset" system already with aufs. systemd isn't "adding" that support.

    I hate that systemd announces all of these so called "improvements".

    Comment


    • #3
      Originally posted by duby229 View Post
      I hate that systemd announces all of these so called "improvements".
      'systemd' did not announce anything. A patch was applied (the contributor's third systemd patch FWIW), that's all: http://cgit.freedesktop.org/systemd/...8305de08985908

      Comment


      • #4
        Originally posted by duby229 View Post
        It's pretty easy to set up a "factory reset" system already with aufs. systemd isn't "adding" that support.

        I hate that systemd announces all of these so called "improvements".
        Aufs isn't a cross distribution supported filesystem since it isn't part of the upstream kernel. Any references you can provide on what you are talking about would be useful anyway. Systemd is merely adding support for the model it announced earlier.

        Comment


        • #5
          Originally posted by duby229 View Post
          It's pretty easy to set up a "factory reset" system already with aufs. systemd isn't "adding" that support.

          I hate that systemd announces all of these so called "improvements".
          It is unsurprisingly that systemd-haters hate all new systemd features. And of course, you are wrong too, probably because you haven't bothered to read what Lennart Poettering meant with "stateless boot".


          The point is that systemd is working towards stateless boots with empty /etc and /var directories that are populated "on the fly", not just copying populated /etc and /var into memory or unto an aufs "file system".

          And the goal is to do this in a generic way, so that all systemd distros can use such functionality if they want. So while normal server/workstation Linux distributions won't use stateless boot as default, they can be made into such stateless systems with minimal configuration fuzz.

          Comment


          • #6
            Originally posted by RahulSundaram View Post
            Aufs isn't a cross distribution supported filesystem since it isn't part of the upstream kernel. Any references you can provide on what you are talking about would be useful anyway. Systemd is merely adding support for the model it announced earlier.
            Well, I do understand that. Distributions need to provide a certain amount of quality control, so that makes sense. It's probably the best argument systemd supporters can make.

            Comment


            • #7
              Originally posted by interested View Post
              The point is that systemd is working towards stateless boots with empty /etc and /var directories that are populated "on the fly", not just copying populated /etc and /var into memory or unto an aufs "file system".
              so...
              instead of just copying or better yet untaring some defaults, they should be hardcoded into some executable ?
              if this is like that, that i doubt it is, then that's just plain stupid

              that makes me wonder where all dem .service configuration files are
              nvm, i googled it, they are in /usr/lib/systemd/system/



              anyway, to give a though that is not so... like that
              the only system related thing that should work without a default config is udev
              more over the kernel should do the only thing left that udev still does, making linux boot with without any extra care
              (and an init system should use /etc..., not /usr/lib, not even /lib that the kernel uses for some things)
              Last edited by gens; 24 March 2015, 12:36 PM.

              Comment


              • #8
                Originally posted by gens View Post
                (and an init system should use /etc..., not /usr/lib, not even /lib that the kernel uses for some things)
                Distro shipped defaults go into /usr/lib, user-overrides go into /etc with systemd. This way the distro can still update the defaults and the user can still ship their custom overrides. Whether they be whole .service files or just snippets to override a single declaration.
                All opinions are my own not those of my employer if you know who they are.

                Comment


                • #9
                  Originally posted by Ericg View Post
                  Distro shipped defaults go into /usr/lib, user-overrides go into /etc with systemd. This way the distro can still update the defaults and the user can still ship their custom overrides. Whether they be whole .service files or just snippets to override a single declaration.
                  /usr is for user related things
                  /etc is for system wide settings
                  $HOME/.config/ is for user specific configs

                  from the FHS "/usr : Secondary hierarchy for read-only user data; contains the majority of (multi-)user utilities and applications."

                  EDIT: user things that are system wide and the package manager for some reason can't just leave be can go into a subdirectory or idk "$THATCONFIGDIRNAME-user" or something
                  Last edited by gens; 24 March 2015, 12:48 PM.

                  Comment


                  • #10
                    Originally posted by gens View Post
                    /usr is for user related things
                    /etc is for system wide settings
                    $HOME/.config/ is for user specific configs

                    from the FHS "/usr : Secondary hierarchy for read-only user data; contains the majority of (multi-)user utilities and applications."

                    EDIT: user things that are system wide and the package manager for some reason can't just leave be can go into a subdirectory or idk "$THATCONFIGDIRNAME-user" or something
                    You can't use $HOME/.config/ for administrator-specific settings for system daemons since those daemons could not read from the user's home dir.
                    And /etc/ IS being used for system-wide settings, its just using /usr/lib as a backup-config location.

                    Also im reposting this link...



                    If distros want to ship a 'golden master' image or a cryptographically verifiable image then it can't include /etc/, /tmp, or /var/ since those directories would be machine-specific and would change the hash.
                    All opinions are my own not those of my employer if you know who they are.

                    Comment

                    Working...
                    X