|
|
Subscribe / Log in / New account

Irrelevant is the word, unfortunately

Irrelevant is the word, unfortunately

Posted Jun 16, 2014 15:57 UTC (Mon) by pizza (subscriber, #46)
In reply to: Irrelevant is the word, unfortunately by Arker
Parent article: Questioning corporate involvement in GNOME development

> Now at the same time they openly scoff at wider *nix compatibility and feel it would 'hold them back'

At the level of systemd/etc, there is no such thing as "wider *nix compatibility" -- every Unix, BSD, and even Linuxes were already incompatible.

Even at a higher level, often the only way to get any sort of compatibility between those environments was to install the GNU tools everywhere.

But anyway.


to post comments

Irrelevant is the word, unfortunately

Posted Jun 16, 2014 18:52 UTC (Mon) by Arker (guest, #14205) [Link] (9 responses)

"At the level of systemd/etc, there is no such thing as "wider *nix compatibility" -- every Unix, BSD, and even Linuxes were already incompatible."

That's simply not true.

Each distribution might use their own init but these are still inits - they do that one job, not everything else, and you CAN easily swap them in and out to replace each other - on slack for instance we have a custom sysV init (but with BSD syntax) but that can be swapped out for e.g. runit, or OpenRC relatively easily. Each of these init systems is different but each performs the same role, and can fit in the same spot in the system.

Systemd does not work in that paradigm, you cannot pull out a standard init and replace it with systemd without replacing a lot of unrelated items as well, nor can you replace systemd with a standard init. A large section of the architecture of the system has simply been replaced en masse, by something with a different structure, a fundamentally different design from the mature design we are familiar with.

And of course personal experience is not statistical data, but I dont see you producing statistical data either and I know a great many programs will compile just fine on various linuces and unices with no more effort than ./configure, and I think the first program I ever ran into that broke that expectation was Gnome. Certainly Gnome and systemd/CoreOS is the first major project I remember taking such an openly contemptuous view towards anyone not eating the exact same dog food they prefer.

So the way I see it, we have a great big *nix ecosystem that includes the BSDs and the Linuces and anything else that wants to be compatible, but the bigger players (Redhat and Canonical) do not want to be compatible with it anymore. So what we are moving towards is a three-way schism. Slackware, Gentoo, and OpenBSD at least, along with some hobbyist projects, will continue to be *nix. Redhat and Debian will become CoreOS, a mostly incompatible fork that will continue to consciously move in the direction of less compatibility every release, while Ubuntu will continue to flog their own versions of the same idea creating yet another mostly incompatible fork, also likely to evolve in the direction of less compatible each iteration.

If that's what they really want to do fine, but I prefer *nix and I suspect most of their users would as well, at least if they understood the question.

Irrelevant is the word, unfortunately

Posted Jun 16, 2014 19:48 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link] (3 responses)

"Systemd does not work in that paradigm, you cannot pull out a standard init and replace it with systemd without replacing a lot of unrelated items as well, nor can you replace systemd with a standard init"

Sure, you can. The so called unrelated things are all optional. That is how distributions were able to move to systemd incrementally.

Irrelevant is the word, unfortunately

Posted Jun 16, 2014 20:50 UTC (Mon) by Arker (guest, #14205) [Link] (1 responses)

"Sure, you can. The so called unrelated things are all optional. That is how distributions were able to move to systemd incrementally."

Moving to it incrementally has the support of the development team. A stable state where systemd is expected to play nice with traditional components it prefers to replace is rather obviously not the same.

Of course it's always technically possible with some developers and time, if you dont mind to spend the time you can make just about anything work, but that's really not the point. It's all designed to be used as one big unit and if you use it otherwise and find a bug expect it to be marked Wont Fix because they... well 'do not care' actually appears to understate it, Poettering quotes I have seen indicate he is actively antagonistic on the point.

Irrelevant is the word, unfortunately

Posted Jun 16, 2014 22:09 UTC (Mon) by rahulsundaram (subscriber, #21946) [Link]

It's perfectly fine to use systemd without any of the optional features. If you want to claim otherwise cite your concrete evidence to back that up.

Irrelevant is the word, unfortunately

Posted Jul 9, 2014 2:20 UTC (Wed) by hitmark (guest, #34609) [Link]

Udev?

Seems like a unrelated thing to me, but still joined at the him thanks to forced surgery...

Irrelevant is the word, unfortunately

Posted Jun 16, 2014 21:05 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (4 responses)

> Each distribution might use their own init but these are still inits - they do that one job, not everything else, and you CAN easily swap them in and out to replace each other - on slack for instance we have a custom sysV init (but with BSD syntax) but that can be swapped out for e.g. runit, or OpenRC relatively easily.

With all the correct dependency resolution and handling of corner cases. Yeah, sure.

About the only thing you can do somewhat portably are simple daemons with no non-trivial dependencies.

> So the way I see it, we have a great big *nix ecosystem that includes the BSDs and the Linuces and anything else that wants to be compatible, but the bigger players (Redhat and Canonical) do not want to be compatible with it anymore.
There is too much difference for the sake of difference alone. As someone who packages a proprietary software for multiple distros I can only say 'kill them all with fire'. Or may be "nuke them from orbit, it's the only way to be sure".

There's a reason why distributions are switching to systemd in droves. And it's not because RedHat forces them to do this at gunpoint - it's because systemd is so damn useful. I've just switched my servers from Debian to RHEL7 and it's like day and night - systemd is so helpful that switching back to SysV is like descending into a stone age.

So 'hobbyists' can continue to slide into irrelevance or they can adapt. Either by creating something that can rival systemd or by working to make systemd acceptable for their use-cases.

Irrelevant is the word, unfortunately

Posted Jun 18, 2014 4:17 UTC (Wed) by Arker (guest, #14205) [Link] (2 responses)

"As someone who packages a proprietary software for multiple distros"

Well there's the problem! ;)

Packaging proprietary software is not a use-case that Free Software should be supporting to begin with.

Irrelevant is the word, unfortunately

Posted Jun 18, 2014 12:36 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

> Packaging proprietary software is not a use-case that Free Software should be supporting to begin with.

I think you need to read the four freedoms again. As opinionated as RMS is, he still allowed proprietary software use in there (even if he doesn't agree with it, he didn't blacklist it at that level).

As bad as some RPMs are, they're better (on the whole) than those installable tarball-in-a-shell-script things.

Irrelevant is the word, unfortunately

Posted Jun 18, 2014 13:40 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

Sure. And Free Software also doesn't need users. And hardware to run. And developers.

Irrelevant is the word, unfortunately

Posted Jul 9, 2014 2:31 UTC (Wed) by hitmark (guest, #34609) [Link]

Linking udev and systemd at the hip probably helped quite a bit...


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds