Systemd's Plan For Stateless Systems, Factory Resets

[FLHerne]

You're not everyone, my friend. This crap isn't useful to me in the slightest. The only thing that systemd would change for me is that I would have to run twice as fast just to stay where I am now with sysvinit.

Do you ever install Linux distros? This will make installers simpler and massively reduce the possibility of getting an unbootable system out.

I'm guessing no, but whatever. If you do, this is useful to you and, like, everyone else who uses Linux.

Do you run Linux in VMs, whether to play with new things or in production? This is useful to you.
Do you have multiple devices with the same OS image? This is useful to you.
Do you ever need a default config file, but have to dig through things because the distro one is buried in a package script or installer? This is useful to you.

etc.

[prodigy_]

Do you ever install Linux distros? This will make installers simpler and massively reduce the possibility of getting an unbootable system out.

Even with custom kernels I really had to go out of my way to end up with an unbootable system. And systemd won't fix a broken kernel anyway.

I'm guessing no, but whatever. If you do, this is useful to you and, like, everyone else who uses Linux.

One more time: you really, really should stop talking on behalf of everyone.

Do you run Linux in VMs, whether to play with new things or in production? This is useful to you.

In VM this isn't useful because VMs already have this functionality. In production this isn't useful because sane people don't push untested changes to production. Period.

Do you have multiple devices with the same OS image? This is useful to you.

Because I can't simply reapply the image...

Do you ever need a default config file, but have to dig through things because the distro one is buried in a package script or installer? This is useful to you.

Never happened to me. Guess that's because I carefully pick distros I use.

[danwood76]

One more time: you really, really should stop talking on behalf of everyone.

Re-read the quote you made, you missed a word!

So many posts from you and not one single valid argument.

[TheBlackCat]

It's because the reality where people believe that utter s..t like systemd can be useful is pretty scary...

I am still waiting for your explanation why practically all major distros and desktop environments, including those not affiliated with Red Hat, are using systemd.

[prodigy_]

So many posts from you and not one single valid argument.

So many posts from systemd fanboys and they can all be summarized in one line: "if you're against systemd your point of view and your arguments aren't valid."

[psychoticmeow]

So many posts from systemd fanboys and they can all be summarized in one line: "if you're against systemd your point of view and your arguments aren't valid."

Just because you have an opinion does not mean that opinion reflects reality.

Time and time again you've been asked to show your workings and all you've come up with are a) conspiracies b) misunderstandings c) lies.

This is why people reject your position, because it is indistinguishable from bullshit.

[jonnor]

That makes a lot of sense. So, system wide apps get installed through the package manager to somewhere on / and sandboxed apps go to /home. However, will these sandboxed apps get to make any use of the system-wide installed libraries?

Current thinking is that sandboxed applications will be developed against a profile, containing a set of libraries and services that must be present on system claiming to support this profile. These will be more high-level and much more coarse grained than package library dependencies.
Yes, at least the libraries that are part of the profile it targets. I actually hope that libraries that are on available on a given system, but not part of the target profile.

Could it be made so Gnome's libraries and KDE's Frameworks (which always come with an explicit minimum version of Qt that can be used) be made the SDK? Sort of how the Free Desktop Standards expects Qt and GTK to both be parts of the "Free Desktop" (which is what we all should refer to these desktops collectivitly, it's why the standard is there). This way, each sandboxed app does not have to include all of these libraries AND these important libraries will be sandbox ready.

The proposed profiles so far are something like "libc" (just kernel API + libc), "LSB" (all libraries in Linux Standard Base) and "GNOME" (everything part of the GNOME platform). If consensus can be made, no reason we cannot define ever wider profiles. Though the more packages it includes, the harder to agree on versions etc.
Personally, I hope the mechanism used to implement a profile will make it easy to expose different libraries in the profile compare to what is used as part of the core OS. This would simplify agreeing on versions, because core OS needs will not be in conflict with profile needs. And hopefully make it easy for third-parties to add profile support to an OS when the OS vendor has not.

Though that makes me wonder; can Javascript apps like Dropbox and Gmail actually read my files at any given moment, or just the ones I chose using the file chooser?

JavaScript applications that run in the browser, only have access to the things that a regular website does. Which means no filesystem, no raw network sockets, no direct access to device drivers.
They cannot even programmatically access servers different from the one they are served from, unless the server has enabled CORS.

However, JS can be used to develop native apps to, with Node.js or GJS (used in Gnome Shell and some apps), and there browser restrictions do not apply. Chrome, Firefox also offer additional APIs with more access to apps which come from their app stores. This can include filesystem and raw network traffic.

[TheBlackCat]

So many posts from systemd fanboys and they can all be summarized in one line: "if you're against systemd your point of view and your arguments aren't valid."

No, they can all be summarized in one line: "if you arguments are all baseless conspiracy theories, unsupported dogma, misunderstandings, misrepresentation, and baseless fear of change, your arguments aren't valid". Or, to put it more simply, "you are entitled to your own opinions, but you aren't entitled to your own facts".

[jonnor]

Also, if your line of argument is "the problems this solution attempts to solve is invalid, hence the solution is invalid", you should be specific about which problems you consider invalid, and why.
And "invalid" here would mean, invalid for the people creating the solution. You can't expect other people to stop trying to solve their own problems because you don't happen to have the same problem right now.

For instance, problems which systemd is helping to solve that I care about
* Atomic, fault-tolerant upgrade of the OS on embedded devices. A state-free core OS helps massively
* A safe way of running applications from third-parties. Not requiring root to install them is a huge step forward, allowing to selectively give them access to my personal data and services running under my user is another
* Linux applications that are portable across distributions. High-level API profiles and dependency bundling tools, and a predictable run-time environment helps massively

Are these things I should not care about?

[prodigy_]

Are these things I should not care about?

You should care about whatever is relevant for you. (For me none of those things is even remotely significant, sorry.)

But everything comes for a price. The price of systemd is... Linux as we know it. All the things we were promised, such as "freedom of choice" and "Linux is not a corporation" are flying completely out of the window right now - do you feel it?

So may I suggest that we stop calling it "Linux" and call it Red Hat OS instead? Simply to avoid confusion.