Originally posted by atari314
Announcement
Collapse
No announcement yet.
Systemd 215 Works On Factory Reset, DHCPv4 Server Support
Collapse
X
-
Originally posted by atari314Stateless systems... Factory reset... Rootkits... DRMs... I bet RedHat and Canonical are loving the lyrics...
Comment
-
Originally posted by stevenc View PostYou're not allowed to make such modifications. A user has no business doing this. systemd knows best.- sd auto-detects your basic layout
- if you have custom settings you want to keep, why would you do a factory reset ? I only factory reset my phone when it is not working or stuff like this... I could also see the use in my school where every student computer is a VM...
Comment
-
Originally posted by haplo602 View PostDoes it retain MY installation modifications (like fs layout) ? I mean this sounds like a useless feature. Why not just snapshot /etc after install and make user changes into the snapshot so you can revert back ? Restore points before upgrades/changes are more usefull since they are granular ... not all or nothing ....
Factory Resets (FR) as feature in it self isn't so important for individual people running a traditional desktop system, though a handy feature nonetheless. But the changes needed to get a stateless system are beneficial to all. It will make Linux a more robust system, especially when it comes to system upgrades and installations.
There are +100.000.000 devices running Linux (not counting Android and pc's), from routers, NAS', SmartTVs, Navigation and entertainment systems etc. Such systems can really benefit from a standard, easy way to do a Factory Reset.
Factory Resets, Reproducible Systems, Stateless Systems, Verifiable Systems, are now potentially possible because of Systemd. There are however still a long way to go to actually implement these features in distros, but when that work is done, Linux will be even better that it is now.
Poettering has a good overview here:
Comment
-
This factory reset SOUNDS like a good idea but I am just wondering how they'd handle rengenerating all this stuff. I can only speak as an arch user so I'd be doing it all manually i'm guessing but what about Fedora or the 'buntus. Would they have to develop distro specific additions to this just to regen everything correctly especially seeing how a lot of that "first time config" (like locale, timezone, system mountpoints) is handled on install and not after. The other concern I have is that as it leaves /usr untouched all the packages you installed will still be there but the records of them won't be, your system will think it's vanilla. So i'm either missing something or it doesn't seem well thought out
Comment
-
Originally posted by SpyroRyder View PostThis factory reset SOUNDS like a good idea but I am just wondering how they'd handle rengenerating all this stuff. I can only speak as an arch user so I'd be doing it all manually i'm guessing but what about Fedora or the 'buntus. Would they have to develop distro specific additions to this just to regen everything correctly especially seeing how a lot of that "first time config" (like locale, timezone, system mountpoints) is handled on install and not after. The other concern I have is that as it leaves /usr untouched all the packages you installed will still be there but the records of them won't be, your system will think it's vanilla. So i'm either missing something or it doesn't seem well thought out
To get to the final version of this, it requires changes to more than systemd.
The idea is that
1. all packages are installed to /usr (eg Fedora's UsrMove a few years back) - This is either mostly done or in the process for many distributions
2. the packagemanager stores the package database in /usr (as it is not configuration) - AFAIK This still needs to be done in most cases.
3. Packages put pristine unmodified packagemanager-managed config files in another location inside /usr (usr/etc?)
Then the installed packages in /usr will be known per /usr and if /etc is missing/deleted, it can be repopulated by the pristine package manager managed versions from the alternate location.
Comment
-
The use-case for these features, if I understand it correctly, is "kiosk mode", where the system is shipped ready for production and just needs to process information that is either fixed (like a real info kiosk) or that is accessed from other means, e.g. a node on a map-reduce large deployment. You feed it data and the task, it processes it and returns/forwards it somewhere else (maybe even to a Network-Attached Storage).
If you think about it, most server installations could run somewhat like this, if you consider NAS as "external state".
Comment
-
Originally posted by SpyroRyder View PostThis factory reset SOUNDS like a good idea but I am just wondering how they'd handle rengenerating all this stuff. I can only speak as an arch user so I'd be doing it all manually i'm guessing but what about Fedora or the 'buntus. Would they have to develop distro specific additions to this just to regen everything correctly especially seeing how a lot of that "first time config" (like locale, timezone, system mountpoints) is handled on install and not after. The other concern I have is that as it leaves /usr untouched all the packages you installed will still be there but the records of them won't be, your system will think it's vanilla. So i'm either missing something or it doesn't seem well thought out
Most systems will probably run a "configuration wizard" after a Factory Reset to enable the user to enter new config information, just like after or during an install.
For those users that running a Linux distro directly on metal in a non-office environment, a Factory Reset probably isn't a very important feature. It is the features (like the /usr merge) that makes a FR possible that are of general interest, since the new design and layout makes upgrades, installs and maintenance much more robust and secure. It will also make life easier for distro and package maintainers.
It also enables multi user systems, where thousands of users all share the same /usr, but each have their own /etc and /var, so it is perfect for "kiosk/thin/fat" clients that are booted and configured from network.
To me the most important new feature is that /usr can be strictly read-only and fully cryptographically verified as one unit. Systems needs to be as secure as possible by design and with as little user interaction as possible and still provide general use systems that aren't locked down so they are very secure but nothing of interest can be done.
Comment
Comment