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

[ssokolow]

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.)

[Cape]

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 🤗

[R41N3R]

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.

[Ananace]

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.

[Slithery]

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.

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.

[Guest]

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.

[F.Ultra]

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.

[intelfx]

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.

[intelfx]

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)

[Guest]

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.

You really dont know what software is.