Goals of current systemd development, what do you think?

Question

"System Vendors:
The toolbox approach of classic Linux distributions is fantastic for people who want to put together their individual system,
nicely adjusted to exactly what they need.
However, this is not really how many of today's Linux systems are built, installed or updated.
If you build any kind of embedded device, a server system, or even user systems, you frequently do your work based on complete system images, that are linearly versioned.
You build these images somewhere, and then you replicate them atomically to a larger number of systems.
On these systems, you don't install or remove packages, you get a defined set of files,
and besides installing or updating the system there are no ways how to change the set of tools you get.
The current Linux distributions are not particularly good at providing for this major use-case of Linux.
Their strict focus on individual packages as well as package managers as end-user install and update tool is incompatible with what many system vendors want."
- Source: http://0pointer.net/blog/revisiting-how … stems.html
What i wonder is if this something we really want? (and i do not mean that i see this as being our, or my call to make, but as a topic of gnu/linux discussion in general)
For my own part, Choosing Arch as my distro of choice, was largely just because of the "use-case" of being able to make my personal choice of use-case;
I.e to get some part of control over what packages i need, and how my workflow be it on my desktop machine, or on my server.
Pacman has largely been a great time-saving enabler for that, and of course the great work of the packagers on here.
Never has it felt easier to cherry-pick applications, and to have sane non-defaults (vanilla/upstream) configurations enabling me to take a self-educated guess
at how i want to set up my personal computing space (my system, my desktop (if any))
My view on the matter, however educated or not, is that choice and burden of control was the main thing that drew people towards linux as opposed to
other OS's (Win, MacOSX?) with a more, one-use-case-should-fit-all attitude.
It is also my personal experience that the more automatic assumptions that we allow the system to make,
the more trouble we will have when those assumptions prove wrong or collide with what we actually wanted.
Furthermore i have always felt that I save time by using more time to set something up, getting a slight know-how of how it works, and fine-tuning it,
to have it work the way i expect, and also to have a better understanding when it breaks
- Then when something is automatically set, configured, and tailored to some theoretic use-case, and not meant to be tinkered with when it breaks.
I Feel it takes more time fixing automatic stuff working against me, then setting it up the way i want in the first place.
I do not wish to make this an inflammatory thread with the usual back and forths of us against and for systemd as change in how we approach our linux systems,
But more like sitting down with a cup of tea (or any other neat beverage of choice) and discuss how we see our own situation in daily linux-usage,
and how we think our beloved distribution, or linux at large, might change in the future.
How do you all feel?
Last edited by PReP (2014-09-24 10:36:40)

Answer 1

blackout23 wrote:Who's going to oversee the app store? The people who develop software are responsible for their own software. I know that sounds pretty preposterous, because software is better when someone else compiles it (aka a package maintainer)... Ohh wait it isn't. In the end you have to trust the upstream developer anyway, since even now Arch devs don't do a full code audit when the package something up. So introducing unnecessary middle man is completely pointless.
There needs to be some medium between a collection of source files and the final installation. Someone needs to oversee that. It's unavoidable. Linux distributions are just that: Packaged distributions of *nix software, overseen by teams of people and deployed using a distribution platform. Without a distribution platform, and someone to operate it, none of the rest makes any sense.
Relationship between developers and users is going to be 1000x better. You know why? No unnecessary middle man. Devs can roll out new version to their users when THEY want it not when some package mainter feels like packaging up a new release and then wait for the new release cycle of the distro to include it. This is immensly better especially for the small FOSS app developer.
The myriad choices that go into developing a single application complicate things. Which versions of various librarires are being used in development? Which tools? What dependencies would the final product require? How are those dependencies handled----are they packaged along with the final package itself, with each application containing copies of its own dependencies? Am I gonna end up with a *nix system that mirrors my Windows installation, where every time I install some new game I have to install yet more identical copies of Visual C++ and DirectX, until my drive clogs up?
Here's another question to ponder: Where do developers get the tools they need to develop? As it is, they're available in packakge repositories, and can be installed on a whim. The proposed "App Store" model would require them to be obtained through the centralized distribution platform. But then how do they get to the platform? Someone packages them and puts them there. But then how do they get packaged and put there? Utilities are used to package them and put them in the distribution platform. But then where do those tools come from? And so on. IN the end, developers still need to jump through the same hoops that we have now. However, the gulf between the developer experience and user experience would be broadened, as users and developers rely on different means of obtaining the same things, and the expectations and persepctives of each are shaped by those different experiences. To quote the article in quesiton:
Many users are used to app markets like Android, Windows or iOS/Mac have. Markets are a platform that doesn't package, build or maintain software like distributions do, but simply allows users to quickly find and download the software they need, with the app vendor responsible for keeping the app updated, secured, and all that on the vendor's release cycle. Users tend to be impatient. They want their software quickly, and the fine distinction between trusting a single distribution or a myriad of app developers individually is usually not important for them.
In other words, it turns users into assholes that individual developers need to deal with on an individual basis---something many folks just aren't prepared to deal with (how many of us have seen a "I'll give you a five-star rating if you add feature x or fix bug y" review?).
Now, on distibutions such as Arch or Gentoo or Sorcerer or CRUX, which are used by many hobbyist and professional developers, the things necesary for development are in the package repositories, and the tools used by developers to build those things and distribute them, and by users to retrieve and install them, are one and the same. So the difference in expectations between end-users and developers is relatively small. Still, the impudence and entitlement of some users surfaces from time to time, and they need to be reminded that [insert distribution here] is developed and maintained by volunteers in their spare time, etc. But imagine that sense of entitlement, multiplied by the number of packages from individual developers in the central distribution platform.
You are aware two of the guys who worked this out use Arch and one of them (Tom Gundersen) is even an Arch Linux developer?
Yes. I read the article. Maybe there's something getting lost in translation here: What's essentially being talked about, near as I can tell, is a universal Linux distribution platform. It's been tried. It didn't work. Like I said, I won't argue over the technical aspects. I can't claim a deep understanding of them, and I'm sure the folks behind this proposal know the technical side of it very well. But the human element makes this all extremely dubious in my eyes.