Announcement

Collapse
No announcement yet.

Systemd-homed: Systemd Now Working To Improve Home Directory Handling

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

  • #51
    Originally posted by Cape View Post
    YES!
    Fuck Unix! That thing is long dead, and the sooner everybody gets it the better it would be!
    Next question being: Is Linux any better? It's nowadays pretty much 'buttboy' for commercial interests to do what they want to it..

    Comment


    • #52
      Originally posted by miabrahams View Post

      JSON is just fine for manual editing. I have no difficulty editing my VS Code config by hand. On top of the rich type system, there is a parsing library available, often included in the stdlib, for nearly every programming language.
      1. You can also edit XML by hand but nobody would say that it harmonizes with existing UNIX configuration file conventions. TOML is better at that than JSON is.
      2. TOML's type system is like JSON's but also adds a datetime type, so people hand-editing data containing dates don't have to manually mess around with human-unfriendly "seconds since the epoch" representations or typo-prone "timestamp as a string" representations.
      3. While not included with stdlibs, there are also TOML parsing libraries available for tons of different languages. (The "v0.5.0 compliant" section of their wiki lists parsers for C++, .NET, Elixir, Java, JavaScript, Objective-C, Python, R, Rust, Smalltalk, Swift, and Wren. If your schema doesn't need the features added in v0.5.0, the "v0.4.0 compliant" section takes that list and adds Clojure, Common Lisp, Crystal, Dart, Erlang, Fortran, Go, Haskell, LabVIEW, Lua, MATLAB, Nim, OCaml, Perl 5, Perl 6, PHP, Ruby, Chicken Scheme, Scala, and Shell.)

      Comment


      • #53
        Originally posted by aht0 View Post

        Next question being: Is Linux any better? It's nowadays pretty much 'buttboy' for commercial interests to do what they want to it..
        OFC not! Actually - with the FSF becoming a diversity hellhole - we should be very worried for the future of Free Software for all users!
        This doesn't mean we should carry on a 70yo OS.

        Ideally I'd like to see RMS founding a new organization with the intent of forking GNU and slowly transition it to the 21st century by incorporating piece after piece into systemd 🤗
        ​​​​

        Comment


        • #54
          I wonder how systemd-homed could solve the issue of home growing way to fast. Actually with flatpak and the likes of Steam that is a real issue to re-use your home on another system without first cleaning it up.

          Comment


          • #55
            This actually looks like a really interesting idea, though I'm curious to see how well it'd handle the combination of both local and shared storage.
            I'd love to have a base version of my homedir available on a flashdrive or just stored on my NAS so I could keep working on my various projects regardless of the system - and no longer have to manually track dotfiles between them, but on the other hand I'd really quite like to keep my various user-installed games and the like stored locally on only my desktop.

            Comment


            • #56
              Originally posted by frank007 View Post
              I'll never be using a feature that will potentially lock my data in case of bugs for ever.
              It just uses regular LUKS volumes that can be opened/mounted with the usual cryptsetup commands. Any of the bugs you refer to would be with LUKS not systemd-homed.

              Originally posted by waxhead View Post
              Am I understanding it correctly that homed don't allow for a standard directory anymore?
              Nope. The LUKS volume is just one of the available backends, standard directories are another.
              Last edited by Slithery; 09-21-2019, 06:13 AM.

              Comment


              • #57
                Originally posted by Slithery View Post
                It just uses regular LUKS volumes that can be opened/mounted with the usual cryptsetup commands. Any of the bugs you refer to would be with LUKS not systemd-homed.


                Nope. The LUKS volume is just one of the available backends, standard directories are another.
                The bug can be anywhere.

                Comment


                • #58
                  Originally posted by frank007 View Post

                  The bug can be anywhere.
                  You do realise that just doing a "ls /home" will touch several hundred of thousands of lines of code from fetching the data of the drive to writing it to your screen. So if you are afraid of potential bugs then you should not use software period.

                  Comment


                  • #59
                    Originally posted by Neraxa View Post
                    Another feature I would like to see is improved freezing to disk of single processes to disk, which can be later unfrozen, even after system reboot. Very interesting feature with interesting possibilities.
                    That'd be CRIU. And it's super damn hard to do properly.

                    Comment


                    • #60
                      Originally posted by polarathene View Post

                      I remember seeing some project(possibly russian maintainers) that was looking to do something like this. Although I think it did involve wrapping a process in a container like lxc or something..
                      Not exactly. You don't strictly have to containerize anything. However, it's impossible to properly checkpoint a process which shares resources or state with another process that is not being checkpointed (unless you can extract the state from that other process, which is out of scope for CRIU). Therefore, to guarantee a successful checkpoint and restore of a process, you will naturally need to limit which processes it can talk to, and then checkpoint the whole group.

                      (Source: briefly worked on CRIU)
                      Last edited by intelfx; 09-21-2019, 05:14 PM.

                      Comment

                      Working...
                      X