Of course this goes to a General Resolution

Posted Feb 12, 2014 16:57 UTC (Wed) by joyuh (guest, #95216)
In reply to: Of course this goes to a General Resolution by viro
Parent article: The Debian technical committee vote concludes

What does intentionally breaking compatibility have to do with systemd?

Systemd promises to not break its own interfaces, just like the kernel, and they already even have a version number baked in, so that any breaking change is easily doable by adding Interface2 in addition to Interface1.

It also keeps compatibility as much as possible with sysvinit by supporting sysvinit initscripts (including LSB dependencies), the initctl command, etc.

The "rapid improvements" are about adding NEW functionality in a way that is full-featured out of the box without having to wait for each distribution to specifically integrate it, not about breaking compatibility.

For example, let's say SSD were invented today, and you add SSD TRIM functionality to the kernel, and decide that most systems will use it with a "cron job" running fstrim (because it's still too slow to be used on each delete, etc.)

At the moment, you can provide the kernel part to all users by adding it to Linus' kernel, but then you have to wait for Debian, Fedora, SuSE etc. to each individually add the fstrim job, with the risk that they fuck it up somehow.

With systemd, you just add the fstrim unit in the systemd repository, along with an announcement that systemd now requires fstrim, and all distributions will automatically acquire that behavior.

So, by just sending patches to Linux and systemd, you are now sure that all users have your feature working by default, without any need to involve the distributions.

Of course this goes to a General Resolution

Posted Feb 12, 2014 17:15 UTC (Wed) by joyuh (guest, #95216) [Link]

See http://www.freedesktop.org/wiki/Software/systemd/Interfac... for systemd's stability promise.

Of course this goes to a General Resolution

Posted Feb 13, 2014 2:11 UTC (Thu) by viro (subscriber, #7872) [Link] (1 responses)

Are you for real? I'm sorry, but do you really mean that you are running the latest-from-git kernel on production boxen? Or expect the majority
of people out there to do the same? The same for systemd, of course...

Stop trolling, really. No, Linus pulling into his tree does *NOT* deliver the modifications to all systems out there. And no, LP pulling into systemd tree will *NOT* do the same thing for systemd changes. Not on Fedora, not on SuSE, not on anything else. The things would be incredibly brittle if they worked that way; they do not.

Of course this goes to a General Resolution

Posted Feb 13, 2014 5:25 UTC (Thu) by joyuh (guest, #95216) [Link]

It does not do so immediately, but it will do so by default in the form you wrote in a bounded amount of time (usually in the next release or the release after that, which means 6-12 months for Fedora and Ubuntu, 2-5 years for RHEL).

On the other hand, if distributions are left to integrate something manually, then by default nothing will happen, and they may or may not do integrate it, possibly after years, and may do so in a way that differst from each other, requiring users to learn all the different dialects.

Also, most distributions have testing, unstable and/or experimental branches where there it might indeed show up very fast (perhaps even immediately if they have buildbots packaging git HEAD continuously)

Of course this goes to a General Resolution

Posted Feb 13, 2014 21:04 UTC (Thu) by jonabbey (guest, #2736) [Link] (12 responses)

> With systemd, you just add the fstrim unit in the systemd repository, along with an announcement that systemd now requires fstrim, and all distributions will automatically acquire that behavior.

You're arguing in favor of systemd here? I'm a big fan of systemd myself, I like the design and all, but making systemd a meta-distribution to rule them all is not going to win it that many friends.

Of course this goes to a General Resolution

Posted Feb 13, 2014 22:47 UTC (Thu) by viro (subscriber, #7872) [Link]

Give man a cigar... That's exactly why I mentioned "a troll" as a possibility.

I don't know who she/he/it is and quick search hasn't turned up anything other than recent lwn posts, so I've no way to tell which variant is more likely. But yes, "the *whole* point of $X is $SOMETHING_INFLAMMATORY and I'm an $X supporter [so surely I can't be just trying to cause a dislike of $X developers]" from anonymous poster certainly can be a troll.

BTW, "pro-$X troll" (or "anti-$X troll") doesn't imply anything about sympathies of the poster - the goal of a troll is amusement from provoked flamefest and assumed position is a matter of tactics...

Of course this goes to a General Resolution

Posted Feb 14, 2014 1:44 UTC (Fri) by joyuh (guest, #95216) [Link] (10 responses)

Well, making distributions more uniform is an explicit current goal of systemd and I think the ultimate goal will indeed be to get rid of distributions altogether and that's why some people are resisting it.

But it is good, because distributions are horrible, and are what is holding the Linux desktop back.

Due to distributions, we have the absurd situation where it is impossible to release software for Linux, since we have two package formats, each distribution calls dependencies what it wants, etc., and you have to go through an ill-defined manual procedure to get your package included in all distributions.

Once distributions are finally eliminated, then developers will be able to release their own packages without going through the distribution maintainers, and decide themselves how they should work and integrate into the system, and deliver them immediately to users upon release.

The question is of course whether systemd will achieve this in time before Ubuntu makes all distributions irrelevant and adds an app store, or Android somehow takes over desktops too, which are the other paths to having a single relevant distribution.

Of course this goes to a General Resolution

Posted Feb 14, 2014 2:08 UTC (Fri) by mgb (guest, #3226) [Link] (5 responses)

This one and only true ultimate non-distribution that you envisage ...

Will it be stable like Debian or bleeding edge like Fedora?
Will it be a rolling release like Gentoo or a versioned release like Slackware?
Will it be free like Ubuntu or $$$ like RHEL?

Is it possible, do you think, that different Linux users have different preferences, and that different distributions cater to those distinct preferences?

Of course this goes to a General Resolution

Posted Feb 14, 2014 2:50 UTC (Fri) by joyuh (guest, #95216) [Link] (4 responses)

In that model, upstreams would necessarily release directly to users, so it would probably work like Firefox on where you choose whether you want releases, betas, alphas or nightlies and automatically get the latest one of what you choose (unless you disable updates).

Which is, you know, what happens on all OSes except on Linux distributions.

Of course this goes to a General Resolution

Posted Feb 14, 2014 3:23 UTC (Fri) by vonbrand (subscriber, #4458) [Link] (1 responses)

Great idea! That way nobody will be able to try to reproduce your particular problem unless you give the exhaustive list of what exact branches of each piece of relevant software is on your system. That will certainly boost QA productivity sky-high...

Of course this goes to a General Resolution

Posted Feb 14, 2014 4:23 UTC (Fri) by joyuh (guest, #95216) [Link]

That's correct.

But you can trivially automate both the process of giving a list of the exact versions of each piece of software, and the process of building a filesystem that precisely corresponds to such a list.

Currently it's even worse because most distributions, due to their ancient packages and not including all software, force users to install some software on their own, sometimes in a way that isn't tracked by the package manager, which means you can't even produce the list at all.

Of course this goes to a General Resolution

Posted Feb 14, 2014 3:45 UTC (Fri) by viro (subscriber, #7872) [Link] (1 responses)

And there, gentlemen, we have a revelation of the decade. *BSD are Linux distributions. Thus the horrible secrets are coming out - *BSD folks had managed to hide this one for a long time, but joyuh has finally exposed it.

Well, either that, or s/h/it is a bold-faced liar. Or has no idea what it's blathering about. But that wouldn't be anywhere near as interesting, would it? After all, one doesn't need to look further than splashsnot to find thousands of lying and clueless wankers, whereas such discoveries are much more rare. Inexistent, even...

Of course this goes to a General Resolution

Posted Feb 14, 2014 4:16 UTC (Fri) by joyuh (guest, #95216) [Link]

BSDs are mostly irrelevant as full OSes, their only relevant parts are the FreeBSD kernel (since it unfortunately empowers several wannabe-monopolists due to their incorrect license choice) and to some extent OpenSSH and perhaps some other offshoot projects.

They can indeed be considered Linux distributions for the purposes of this discussion, though.

But they are even worse than them, since they even cause fragmentation at the kernel level, making people a bit more reluctant to rely on advances in Linux.

And in fact, accelerating the death of the BSDs will likely be one of the (intentional) effects of systemd.

Of course this goes to a General Resolution

Posted Feb 14, 2014 7:49 UTC (Fri) by anselm (subscriber, #2796) [Link] (3 responses)

I think it is highly unlikely that systemd will get rid of the RPM/dpkg divide anytime soon, let alone Linux distributions.

On the other hand, there is no conceivable benefit in distribution X storing the system's host name in »/etc/HOSTNAME« while distribution Y is using »/etc/sysconfig/hostname«. If systemd's unified early-boot toolkit helps us achieve more cross-distribution consistency in those areas that can only be a good thing.

Of course this goes to a General Resolution

Posted Feb 14, 2014 10:50 UTC (Fri) by Wol (subscriber, #4433) [Link] (2 responses)

And doesn't systemd make that a configurable option :-)

So you can leave the distro default untouched for old packages that look for it directly, but new packages can query systemd and know that they'll get the answer, without having to worry about where it came from.

Certainly I've wasted enough time on various nixen (RiscOS, SCO, SuSE, Slack, gentoo) trying to hunt it down :-)

Cheers,
Wol

Of course this goes to a General Resolution

Posted Feb 14, 2014 11:16 UTC (Fri) by mchapman (subscriber, #66589) [Link] (1 responses)

> And doesn't systemd make that a configurable option :-)

No, it's hard-coded.

You could leave the old distro-specific file around, but it'd get out-of-sync with the file managed by hostnamed.

Of course this goes to a General Resolution

Posted Feb 14, 2014 12:42 UTC (Fri) by anselm (subscriber, #2796) [Link]

A distribution would be perfectly free to change hostnamed such that it writes the (static) hostname to the old distribution-specific file whenever the hostname is changed through its D-Bus interface.

(Of course that should be considered a temporary measure until the distribution is fixed.)