You are not logged in.

#1 2014-09-24 10:34:52

PReP
Member
From: Sweden
Registered: 2010-06-13
Posts: 359
Website

Goals of current systemd development, what do you think?

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


. Main: Intel Core i5 6600k @ 4.4 Ghz, 16 GB DDR4 XMP, Gefore GTX 970 (Gainward Phantom) - Arch Linux 64-Bit
. Server: Intel Core i5 2500k @ 3.9 Ghz, 8 GB DDR2-XMP RAM @ 1600 Mhz, Geforce GTX 570 (Gainward Phantom) - Arch Linux 64-Bit
. Body: Estrogen @ 90%, Testestorone @ 10% (Not scientific just out-of-my-guesstimate-brain)

Offline

#2 2014-09-24 11:55:50

lolilolicon
Member
Registered: 2009-03-05
Posts: 1,722

Re: Goals of current systemd development, what do you think?

IKEA vs Apple. Both options have their applications.
Most of us Archers like to put pieces together, at least when it comes to our OS. But most of us, I suppose, would like a finely engineered, polished, and fully packaged car.
Arch Linux surely is not going to become an Android. But there is no problem to enable others with a different objective to produce a Porsche.
Now, where is my cup of tea?


This silver ladybug at line 28...

Offline

#3 2014-09-24 12:45:37

PReP
Member
From: Sweden
Registered: 2010-06-13
Posts: 359
Website

Re: Goals of current systemd development, what do you think?

lolilolicon wrote:

IKEA vs Apple. Both options have their applications.
Most of us Archers like to put pieces together, at least when it comes to our OS. But most of us, I suppose, would like a finely engineered, polished, and fully packaged car.
Arch Linux surely is not going to become an Android. But there is no problem to enable others with a different objective to produce a Porsche.
Now, where is my cup of tea?

I think i can agree with your point, if the point is that someone doing X, should not interfer with another doing Y?
(I.e, this theoretical change should not effect us going about our bussiness/system as usual)
If that ends up being the case, i am of course without objections, others should have the same possibility to have their way as i would want to have mine.

I suppose it is just the still somewhat lingering fear that the aim for current development of things like systemd,
have a much more different end goal and intended user base then one might feel to belong in.

(I,e, there are systems taking care of guessing and setting automatic standards for what you use to mixed results,
       but i hope to still have access to the practice of having a bit more personalisation and tinkering the way arch has
       provided, much because of the great contributions and hard work of the devs here, which i appreciate more then i can say)

I suppose hope this won't all change to fit all mobile devices, all embedded systems, all different types of users in a single pre-made automatic image,
somewhere down the road.


Oh and yes, i find nothing wrong with your honest input so a cup is coming! smile


. Main: Intel Core i5 6600k @ 4.4 Ghz, 16 GB DDR4 XMP, Gefore GTX 970 (Gainward Phantom) - Arch Linux 64-Bit
. Server: Intel Core i5 2500k @ 3.9 Ghz, 8 GB DDR2-XMP RAM @ 1600 Mhz, Geforce GTX 570 (Gainward Phantom) - Arch Linux 64-Bit
. Body: Estrogen @ 90%, Testestorone @ 10% (Not scientific just out-of-my-guesstimate-brain)

Offline

#4 2014-09-24 13:32:36

lolilolicon
Member
Registered: 2009-03-05
Posts: 1,722

Re: Goals of current systemd development, what do you think?

PReP wrote:

I suppose it is just the still somewhat lingering fear that the aim for current development of things like systemd,
have a much more different end goal and intended user base then one might feel to belong in.
... ...
I suppose hope this won't all change to fit all mobile devices, all embedded systems, all different types of users in a single pre-made automatic image,
somewhere down the road.

That would be a nightmare.
Indeed, I believe the culture of our community relies on the modularity of the OS. I can't imagine one day we will all pass around an entire OS image to share a tiny bit of bug fix or customization. "ROMs" for arcade games are generally passed around this way; you don't do this to open source software.
I believe the "finished product" way of doing things will by its own nature be restricted to where it belongs, i.e. where finished products belong. As there will always be developers, builders and hackers, for whom using a finished product will only impede understanding and communication, I'm positive the culture of our community will live on.


This silver ladybug at line 28...

Offline

#5 2014-09-24 13:42:34

progandy
Member
Registered: 2012-05-17
Posts: 5,184

Re: Goals of current systemd development, what do you think?

Systemd is still modular,  except for the the system (=service/boot/device) manager.  It hides it very well since it uses dbus for communication and provides functionality as libraries instead of separate binaries connected with simple stdio. As a result you have to learn and use a completely new ecosystem that is incompatible with "older" components. We might yet see some genius who shocks us all with a more modular reimplementation. Personally I like the idea of the dependency management and service files, but systemd still feels a bit clumsy and cumbersome if you want to do just a bit more than it was designed for. There is this great dependency system available, but as soon as you want to define something more complex like mutually exclusive services you get problems.

PS: Arch helps this image since it ships all of systemd in a single package. I believe with a bit of careful planning split packages could be created for e.g. networkd, journald, ...

Last edited by progandy (2014-09-24 13:47:19)


| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |

Online

#6 2014-09-24 14:08:18

blackout23
Member
Registered: 2011-11-16
Posts: 781

Re: Goals of current systemd development, what do you think?

If I could get all my applications directly from the developers just as fresh as on Arch with what the systemd cabals has in mind I would use it in a heartbeat. At least the application would be guaranteed to work since it comes with the same runtime which was used for development. This also makes it a lot easier for upstream developers to reproduce your bug. Often your distro has a wired library combination which hits some corner case and there is no way for the developer to reproduce it unless he goes through the hassle to install your distro. Let's face doing distro packaging and fixing distro specific bugs isn't a very exciting task. Applications should not have to be curated and fixed and packaged by dozens of distro maintainers. It's not like one person packages chromium. Dozens of people do pretty much the same thing. So much redundancy. It would make rolling distros much better than they are now. You could update applications without touching your system or risking breakage with other applications. You could downgrade something without kicking off some downgrade avalanche due to how everything is updated in lockstep and interdependent and shared at the moment.

I would still use Arch Linux for my base system to install the kernel, drivers and desktop environment. These are things that actually make sense to be part of a distro, since you can't independently redistribute the nvidia driver and have it work with all kernels. Other distros like Ubuntu could finally focus on the user experience they want to provide which is what a distro should be about.

Last edited by blackout23 (2014-09-24 14:13:30)

Offline

#7 2014-09-24 14:41:27

lolilolicon
Member
Registered: 2009-03-05
Posts: 1,722

Re: Goals of current systemd development, what do you think?

@blackout23 are you suggesting that applications should ship libraries with them? Doesn't that mean you will get a thousand copies of the same library on your system? I would be very displeased with that... A current example of this is the sage-mathematics package -- look at the size of it, and how many packages it ships with it (see, we put this thing in /opt); sure, this thing is huge and maybe they're justified in this case... but this is generally a bad thing to do; it drastically reduces the usefulness of libraries / modules which are supposed to be reused.

More importantly, allowing applications to ship their own copy of common libraries would encourage fragmentation. Some application developers would simply stick with old libraries, some would ship a slightly modified version of a library, etc. Soon it'll be Windows all over again -- applications will ship their own versions of DLL and shit. No, we have something better, we have Unix, we have standards, well defined and generally stable APIs, we do not need to have applications take dumps all over our system.

Last edited by lolilolicon (2014-09-24 14:41:55)


This silver ladybug at line 28...

Offline

#8 2014-09-24 15:50:13

blackout23
Member
Registered: 2011-11-16
Posts: 781

Re: Goals of current systemd development, what do you think?

lolilolicon wrote:

@blackout23 are you suggesting that applications should ship libraries with them? Doesn't that mean you will get a thousand copies of the same library on your system? I would be very displeased with that... A current example of this is the sage-mathematics package -- look at the size of it, and how many packages it ships with it (see, we put this thing in /opt); sure, this thing is huge and maybe they're justified in this case... but this is generally a bad thing to do; it drastically reduces the usefulness of libraries / modules which are supposed to be reused.

More importantly, allowing applications to ship their own copy of common libraries would encourage fragmentation. Some application developers would simply stick with old libraries, some would ship a slightly modified version of a library, etc. Soon it'll be Windows all over again -- applications will ship their own versions of DLL and shit. No, we have something better, we have Unix, we have standards, well defined and generally stable APIs, we do not need to have applications take dumps all over our system.

No if you read the proposal by the systemd cabal applications would not ship everything they need. They'd use runtimes, which covers most of the libraries your typical program needs. If you need a special library you ship it yourself which marginally increases the program size. If you'd install the same program on a traditional distro model it would take up exactly the same space. One runtime can be used by many applications of course. The disk space argument is purely academic these days anyway. No one really cares if your install is 10 GB or 30 GB when pretty much any hard drive these days is 1 TB and even big SSDs are cheap. That's a small price to pay for immense benefits.

We have stable APIs on Linux? You probably mean the kernel API. Anything else, not so much.

Last edited by blackout23 (2014-09-24 15:58:28)

Offline

#9 2014-09-24 15:52:40

Scimmia
Fellow
Registered: 2012-09-01
Posts: 11,461

Re: Goals of current systemd development, what do you think?

blackout23 wrote:

The disk space argument is purely academic these days anyway. No one really cares if your install is 10 GB or 30 GB when pretty much any hard drive these days is 1 TB and even big SSDs are cheap. That's a small price to pay for immense benefits.

disk space argument, maybe, but not the memory it takes to load each and every version. Nor the load time.

Last edited by Scimmia (2014-09-24 15:54:25)

Offline

#10 2014-09-24 15:56:27

blackout23
Member
Registered: 2011-11-16
Posts: 781

Re: Goals of current systemd development, what do you think?

Scimmia wrote:
blackout23 wrote:

The disk space argument is purely academic these days anyway. No one really cares if your install is 10 GB or 30 GB when pretty much any hard drive these days is 1 TB and even big SSDs are cheap. That's a small price to pay for immense benefits.

disk space argument, maybe, but not the memory it takes to load each and every version.

Never heard complains from Windows or Mac users that they're constantly running out of memory. You can get 8 GB RAM for 30 bucks these days.

Offline

#11 2014-09-24 15:57:51

Scimmia
Fellow
Registered: 2012-09-01
Posts: 11,461

Re: Goals of current systemd development, what do you think?

Then you haven't been around very long.

Offline

#12 2014-09-24 16:20:53

blackout23
Member
Registered: 2011-11-16
Posts: 781

Re: Goals of current systemd development, what do you think?

Scimmia wrote:

Then you haven't been around very long.

Care to provide examples that this is a major problem on these two operating systems? The really is that the people who care about the applications should package them. The person who cares the most is the upstream developer himself. People who care about the security of libraries that applications link against should provide the runtimes. The people who care about the set of default apps and user experience should put together the distro.

Last edited by blackout23 (2014-09-24 16:21:25)

Offline

#13 2014-09-24 16:44:35

lolilolicon
Member
Registered: 2009-03-05
Posts: 1,722

Re: Goals of current systemd development, what do you think?

blackout23 wrote:

No if you read the proposal by the systemd cabal applications would not ship everything they need. They'd use runtimes, which covers most of the libraries your typical program needs. ... ...

You got me; I didn't really RTFA. Apparently the cabal have put some thoughts in it. I suppose they have a point.
But my gut feeling is that their proposed setup is inherently more complex than the Arch Linux configuration, where most things are on one and only one version: the newest and greatest. We're simply bleeding edge. We move fast. If we had dominated the world, we wouldn't be talking about this sticky stuff. Maybe we should do that.

Last edited by lolilolicon (2014-09-24 16:45:06)


This silver ladybug at line 28...

Offline

#14 2014-09-24 17:03:45

blackout23
Member
Registered: 2011-11-16
Posts: 781

Re: Goals of current systemd development, what do you think?

lolilolicon wrote:
blackout23 wrote:

No if you read the proposal by the systemd cabal applications would not ship everything they need. They'd use runtimes, which covers most of the libraries your typical program needs. ... ...

You got me; I didn't really RTFA. Apparently the cabal have put some thoughts in it. I suppose they have a point.
But my gut feeling is that their proposed setup is inherently more complex than the Arch Linux configuration, where most things are on one and only one version: the newest and greatest. We're simply bleeding edge. We move fast. If we had dominated the world, we wouldn't be talking about this sticky stuff. Maybe we should do that.

Nothing forces you to keep multiple versions of some application around, but it's nice that you can if you really are more happy with SomeOfficeSuite v3 than v4. You'd probably get your new version of some application even faster than you do know, since upstream just creates the app bundle when they release a new version. No need to wait for another middle man (package maintainer) to take action.

Offline

#15 2014-09-24 17:34:49

lolilolicon
Member
Registered: 2009-03-05
Posts: 1,722

Re: Goals of current systemd development, what do you think?

Technically, it's indeed more flexible. But how this will turn out depends on "human factors", such as descipline. I still maintain this tends to encourage fragmentation. I like the system we already have.


This silver ladybug at line 28...

Offline

#16 2014-09-24 19:22:24

ANOKNUSA
Member
Registered: 2010-10-22
Posts: 2,141

Re: Goals of current systemd development, what do you think?

I assume this will remain relegated to embedded and server systems, since it's logistically impossible for desktop distributions.

Offline

#17 2014-09-24 19:41:42

blackout23
Member
Registered: 2011-11-16
Posts: 781

Re: Goals of current systemd development, what do you think?

ANOKNUSA wrote:

I assume this will remain relegated to embedded and server systems, since it's logistically impossible for desktop distributions.

Care to elaborate?

Distributing distro updates as incremental btrfs subvolume diffs is trvial and already works.
https://plus.google.com/117537647502636 … RwAuuTHGov

The whole system-update tool is just a handful of lines of bash.

Apps aren't shipped by distros so the logistics are dramatically easier for distros than what we have today.

Last edited by blackout23 (2014-09-24 20:18:56)

Offline

#18 2014-09-24 23:58:10

ANOKNUSA
Member
Registered: 2010-10-22
Posts: 2,141

Re: Goals of current systemd development, what do you think?

Implementing something like this makes sense if your're creating an embedded or server image, and sure, you could use it for a pre-made workstation image. But how would it work for desktop users? How could it work? The author keeps referring to the Android/ChromeOS/iOS model, conveniently overlooking the multi-million-dollar companies behind those projects. Who would oversee this new Linux "app store?" How big are these multi-os images going to be? How would a rolling-release system like Arch make use of them? How do individuals with their own small-time FOSS projects participate in something like this? What might happen to the relationship between users and developers (have a look at the Google Play Store for a possible answer)? How great is the demand for having multiple operating systems installed in a desktop/laptop, and if everything's using a shared resource pool what would it even mean to have multiple operating systems installed (remember, these folks are trying to "solve" the "problem" of different distributions having different software versions and different packaging models).

It seems to me that a group of guys got together and said "Know what would be cool?" and then spent their time answering that question, never asking whether implementing that idea would actually be feasible. You can go on about technical feasability, and all the technical variables, that you want; the human variable will always have an exponentially greater effect on the outcome of any proposition.

Offline

#19 2014-09-25 00:37:01

Trilby
Inspector Parrot
Registered: 2011-11-29
Posts: 29,441
Website

Re: Goals of current systemd development, what do you think?

Different sofware versions and different packaging models?  Nooooo.  We'll have to fix that.


"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" -  Richard Stallman

Offline

#20 2014-09-25 12:03:33

blackout23
Member
Registered: 2011-11-16
Posts: 781

Re: Goals of current systemd development, what do you think?

ANOKNUSA wrote:

Implementing something like this makes sense if your're creating an embedded or server image, and sure, you could use it for a pre-made workstation image. But how would it work for desktop users? How could it work? The author keeps referring to the Android/ChromeOS/iOS model, conveniently overlooking the multi-million-dollar companies behind those projects. Who would oversee this new Linux "app store?" How big are these multi-os images going to be? How would a rolling-release system like Arch make use of them? How do individuals with their own small-time FOSS projects participate in something like this? What might happen to the relationship between users and developers (have a look at the Google Play Store for a possible answer)? How great is the demand for having multiple operating systems installed in a desktop/laptop, and if everything's using a shared resource pool what would it even mean to have multiple operating systems installed (remember, these folks are trying to "solve" the "problem" of different distributions having different software versions and different packaging models).

It seems to me that a group of guys got together and said "Know what would be cool?" and then spent their time answering that question, never asking whether implementing that idea would actually be feasible. You can go on about technical feasability, and all the technical variables, that you want; the human variable will always have an exponentially greater effect on the outcome of any proposition.


Pretty simple.

First. Nobody proposed multi-OS images. They proposed shipping the distro as a /usr snapshot, since systemd recommends moving things into /usr anyway like default configs (instead of shipping them in /etc). So you can boot with just a /usr directory which is essentially the entire distro. How big is it going to be? Exactly as big as your Fedora 21 /usr directory for example. Instead of populating it with hundreds of packages you deploy it as one image. If the distro gets an update the difference between both versions is shipped in one image instead of dozens of package updates which can fail half way through the update process.
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. 
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. You know who a small FOSS app developer is? Linus Torvalds and his divelog application. Even he acknowledges that the current model just fucking sucks. https://www.youtube.com/watch?v=1Mg5_gxNXTo#t=359 
Who forces you to install multiple distros with this model? Today if you want to install two distro you install two distro. If you only want to use one distro you just use one distro?
How would a rolling distro like Arch make use of this? Easy, since nothing dictates you to have the distro rolled out as read only images you simply use the runtimes and apps and keep updating the base distro with pacman. Only difference is that distro developers have way more time to focus on important stuff, rather than bumping version numbers in thousands of upstream application build scripts over and over and over again.

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?

Last edited by blackout23 (2014-09-25 12:10:48)

Offline

#21 2014-09-25 12:15:08

progandy
Member
Registered: 2012-05-17
Posts: 5,184

Re: Goals of current systemd development, what do you think?

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.

You make a good point. Still, this might encourage developers to create their own convoluted and undocumented build systems. Then it will be difficult to compile the software in case you want to add some patches. When the build and package process are not the responsibility of the developer, then (s)he is forced to provide enough documentation for the maintainer.

Last edited by progandy (2014-09-25 12:17:30)


| alias CUTF='LANG=en_XX.UTF-8@POSIX ' |

Online

#22 2014-09-25 12:22:40

blackout23
Member
Registered: 2011-11-16
Posts: 781

Re: Goals of current systemd development, what do you think?

progandy wrote:
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.

You make a good point. Still, this might encourage developers to create their own convoluted and undocumented build systems. Then it will be difficult to compile the software in case you want to add some patches. When the build and package process are not the responsibility of the developer, then (s)he is forced to provide enough documentation for the maintainer.

Since the compiler toolchain is part of the framework and the application declares which runtime it uses you know what framework to use to recompile the app with a patch. A framework is the runtime (all the necessary libs) plus header files and build tools.

framework:<vendorid>:<architecture>:<version> -- This is very similar to a vendor runtime, as described above, it contains just a /usr tree, but goes one step further: it additionally contains all development headers, compilers and build tools, that allow developing against a specific runtime. For each runtime there should be a framework. When you develop against a specific framework in a specific architecture, then the resulting app will be compatible with the runtime of the same vendor ID and architecture. Example: framework:org.gnome.GNOME3_20:x86_64:3.20.1
From: http://0pointer.net/blog/revisiting-how … stems.html

The Gnome project already put together a framework (SDK) and runtime (platform).
https://mail.gnome.org/archives/gnome-o … 00015.html 
https://mail.gnome.org/archives/gnome-o … 00000.html

Last edited by blackout23 (2014-09-25 12:25:23)

Offline

#23 2014-09-25 18:11:01

ANOKNUSA
Member
Registered: 2010-10-22
Posts: 2,141

Re: Goals of current systemd development, what do you think?

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.

Offline

#24 2014-09-25 18:18:10

falconindy
Developer
From: New York, USA
Registered: 2009-10-22
Posts: 4,111
Website

Re: Goals of current systemd development, what do you think?

blackout23 wrote:

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?

Aha, a lie of omission. Tom is a RedHat employee. He hasn't done anything for Arch for over a year now.

actual content: I skimmed Lennart's blog post. I didn't see anything that I felt was applicable to Arch. If anything, said new functionality has only caused me problems.

Last edited by falconindy (2014-09-25 18:50:49)

Offline

#25 2014-09-25 19:03:13

blackout23
Member
Registered: 2011-11-16
Posts: 781

Re: Goals of current systemd development, what do you think?

falconindy wrote:
blackout23 wrote:

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?

Aha, a lie of omission. Tom is a RedHat employee. He hasn't done anything for Arch for over a year now.

Ahh thanks. I thought I saw some e-mails on arch-dev-public from him in the last 1-2 months.

But then how do they get to the platform? Someone packages them and puts them there.

Nothing about this proposal says there needs to be one giant FTP server where everything is uploaded. People could have their own repos. Like a Gnome repo, which supplies the Gnome runtime and framework. All of that could still be connected via a store which is just a directory pointing to the individual repos. Just like the AUR basically only points to some code on Github or *.deb file on Googles Server for Google Chrome.

Last edited by blackout23 (2014-09-25 19:14:15)

Offline

Board footer

Powered by FluxBB