Linked by jessesmith on Wed 19th Nov 2014 21:22 UTC
Debian and its clones

Starting on November 5th the Debian developers went to the polls to vote on a general resolution which would determine how init software and dependencies are handled in the venerable open source distribution. The result of the resolution will determine whether software packaged for Debian can depend on a specific implementation of init software. The init process is the first to start on Linux and UNIX operating systems and is responsible for bringing the operating system up and managing services.

The general resolution stirred up quite a bit of controversy with some developers wishing to keep software uncoupled from any specific init implementation. Others felt packages and upstream developers should be able to depend on a specific init package for the sake of simplicity or convenience. In the end, the votes were counted and it was decided no resolution would be passed addressing coupling software to init. This means, essentially, it will be up to individual packagers and upstream developers to decide whether to depend on one specific init implementation.

Order by: Score:
Yay for the compromise!
by Vanders on Wed 19th Nov 2014 23:24 UTC
Vanders
Member since:
2005-07-06

Confusion can reign until the next time someone asks the question!

Reply Score: 4

So...
by tylerdurden on Wed 19th Nov 2014 23:28 UTC
tylerdurden
Member since:
2009-03-17

... they resolved it, by not resolving it?

Reply Score: 7

RE: So...
by ddjones on Thu 20th Nov 2014 00:25 UTC in reply to "So..."
ddjones Member since:
2014-10-28

... they resolved it, by not resolving it?


Not making a choice is in itself a choice. In this case, they resolved it by allowing developers to require systemd. In the near future, one or more vital packages will depend on systemd. The de facto result of the vote is that you will soon be unable to run a useful Debian installation without systemd. Systemd will be effectively required, even if you can theoretically get a Debian system booting without it.

Reply Score: 2

RE[2]: So...
by Vanders on Thu 20th Nov 2014 00:38 UTC in reply to "RE: So..."
Vanders Member since:
2005-07-06

Yes. The practical upshot will be similar to choosing between a GTK+ based DE or a Qt based DE. As soon as you want to install an application that requires the one you don't run, you're in a world of pain having to install a complex dependency tree that essentially will shadow your existing system for no good reason. Except this is worse, because only one init system can be PID 1.

I look forward to two different packages fighting over which init system they require.

Reply Score: 5

RE[3]: So...
by Valhalla on Thu 20th Nov 2014 04:22 UTC in reply to "RE[2]: So..."
Valhalla Member since:
2006-01-24


As soon as you want to install an application that requires the one you don't run, you're in a world of pain having to install a complex dependency tree


Let me invite you to the wonderful world of package managers, you do not need to manually resolve dependencies anymore.

It is interesting though how you seem to be against systemd which consolidates this very aspect that you describe as a 'world of pain'.


Except this is worse, because only one init system can be PID 1.


The functionality which systemd provides as part of it's core tools are not bound to systemd init being pid1, that functionality can be offered by other tools, such as the functionality provided by logind, which is what GNOME requires, in turn a result of Consolekit being unmaintained for a very long time.

Recently the XFCE project said they are working on a fork of said Consolekit, hopefully this will result in a maintained alternative to logind.

I look forward to two different packages fighting over which init system they require.


Which type of package would this be ?

As for the comparison to GNOME/KDE, unlike that situation where we have two very popular desktop environments with large dependency trees which spill over on their respective applications, upstream is firmly behind systemd, and so are the largest distros, which include RHEL, Debian, Ubuntu, Fedora, SUSE, Arch etc, I'd say it's the exact opposite of the Gnome/KDE situation:

RHEL/Fedora/Debian ships with Gnome, SUSE ships with KDE, Ubuntu ships Unity based off Gnome but is switching to being Qt/QML based, Arch ships with nothing, however they all are or will be running systemd as default.

Here's hoping we won't have all this drama all over again once Wayland starts replacing X .

Reply Score: 4

RE[4]: So...
by Vanders on Thu 20th Nov 2014 15:26 UTC in reply to "RE[3]: So..."
Vanders Member since:
2005-07-06

"
As soon as you want to install an application that requires the one you don't run, you're in a world of pain having to install a complex dependency tree


Let me invite you to the wonderful world of package managers, you do not need to manually resolve dependencies anymore.
"

Which doesn't change the fact I need both systems installed. Obviously having both installed always works and they interoperate perfectly; for example not like in 14.10 where Qt applications are using the default Qt theme rather than sharing the GTK+ theme. There'll definitely never be a similar problem with multiple applications requiring different bits of various init systems.

Recently the XFCE project said they are working on a fork of said Consolekit, hopefully this will result in a maintained alternative to logind.


Which is exactly my point. Xfce will use ConsoleKit, but something else will want logind. Do you think they'll always work perfectly with each other?

Reply Score: 5

RE[5]: So...
by Valhalla on Fri 21st Nov 2014 04:49 UTC in reply to "RE[4]: So..."
Valhalla Member since:
2006-01-24


Which doesn't change the fact I need both systems installed.


Which is different from any other dependency chain how ?

Obviously having both installed always works and they interoperate perfectly; for example not like in 14.10 where Qt applications are using the default Qt theme rather than sharing the GTK+ theme.


They are different toolkits with different theming engines, how could they 'interoperate perfectly' ?, they'd effectively be forced to develop their respective solutions in lockstep.

Again what you seem to argue for is a de facto standardisation around one solution, which is what we are actually seeing with systemd.

There'll definitely never be a similar problem with multiple applications requiring different bits of various init systems.


Who knows what the future holds, but given how the de facto standardisation around systemd as a cross-distro solution is progressing it seems less and less likely.

Which is exactly my point. Xfce will use ConsoleKit, but something else will want logind. Do you think they'll always work perfectly with each other?


Well, they don't actually work 'with eachother', they are alternative solutions that provide certain functionality, as long as the necessary functionality is there in both solutions then they will be easily supportable for projects needing that functionality, such as Gnome.

Of course this requires that the solutions are maintained so that they actually work, get bugfixes, are updated to support further needs, this is hopefully what the new fork of ConsoleKit achieves.

Reply Score: 4

RE[4]: So...
by anda_skoa on Sat 22nd Nov 2014 13:03 UTC in reply to "RE[3]: So..."
anda_skoa Member since:
2005-07-07

"
Except this is worse, because only one init system can be PID 1.


The functionality which systemd provides as part of it's core tools are not bound to systemd init being pid1
"
This seems to be overlooked, or intentionally kept unsaid/unwritten, a lot in these discussions.

How many of those allegedly systemd dependent programs actually depend on systemd being PID 1?

A lot of the often mentioned ones like GNOME (via logind) in fact only need systemd to be working, no matter whether it was started as init or anoher init started it.

Reply Score: 3

RE: So...
by Valhalla on Thu 20th Nov 2014 00:52 UTC in reply to "So..."
Valhalla Member since:
2006-01-24

The vote reflected that there was no need for a GR vote to begin with.

If upstream wants to target a specific solution, in this case functionality provided by systemd, then it's the choice of the Debian package maintainers to decide if they want to provide means to run said package against alternate solutions, if they even exist.

And lack of such alternate solutions will not block the package from inclusion into Debian.

This is how it was prior to this GR, and the vote shows that this is how the Debian developers want it to stay.

Which brings us full circle, the alternatives we have in FOSS do not exist because someone mandated that they should be supported (which Ian Jackson tried to do here in this GR), but because people step up and maintain those alternatives of their own free will, that is the FREEDOM in FOSS, the code is there, pick it up and do the work.

It's not, 'you owe it to me to support my favoured solution, else you take away my freedom' which is what some people have been trying to claim in this debate.

Upstream are those who create the software you are free to USE, you can certainly ask them to implement something, or take/not take a particular direction, but throwing tantrums when they disagree with you is a level of entitlement that is plain scary.

It's like being offered a free meal and demand that it should be your particular favourite dish.

Don't like what they serve you for free, go make your own meal (with a FORK even), or pay someone to make it exactly the way you want.

Reply Score: 9

RE[2]: Free meal?
by jessesmith on Thu 20th Nov 2014 03:36 UTC in reply to "RE: So..."
jessesmith Member since:
2010-03-11

>> "Upstream are those who create the software you are free to USE, you can certainly ask them to implement something, or take/not take a particular direction, but throwing tantrums when they disagree with you is a level of entitlement that is plain scary. It's like being offered a free meal and demand that it should be your particular favourite dish. "

I think this line of thinking has a flaw and is overlooking (and misinterpreting) a few facts. Specifically that many people in the open source community pay for their software (or donate funds, code, artwork, bug reports, etc). Projects like Debian, Mint, Mageia, etc survive in large part from the money and other contributions their users send them. Otherwise they would have trouble keeping the servers running. In short, any open source project of significant size (which Debian certainly is) relies a good deal on contributions from the community.

This means running Debian (for many of us) is less like receiving a free meal and more like frequenting a restaurant where we order (and pay for) a dish we like. Then, after several years of ordering our "usual" we discover the restaurant no longer carries the dish we usually buy. At which point we need to decide if we want to order something else or visit another restaurant.

You may assume open source users are free loaders, but I contribute code, money, forum assistence and bug reports to the distributions I run. For me running a distro is an exchange (my resources for their product). My time, skillset and money goes to the project that serves my needs best. The same is true of many people. After all the people who are Debian Developers today were all Debian users in the past.

Really, do you think it is a "scary" level of entitlement that some of us only contribute to projects we continue to find useful?

Reply Score: 5

RE[3]: Free meal?
by Valhalla on Thu 20th Nov 2014 05:41 UTC in reply to "RE[2]: Free meal?"
Valhalla Member since:
2006-01-24

Then, after several years of ordering our "usual" we discover the restaurant no longer carries the dish we usually buy. At which point we need to decide if we want to order something else or visit another restaurant.


No argument there.

You may assume open source users are free loaders, but I contribute code, money, forum assistence and bug reports to the distributions I run.


No certainly not, but unless the distro has stated that contributing code, money, forum assistance, bug reports, etc, gives you a say in which direction the project take, then you have no demands on said direction.

If we take Debian which is the topic here, I believe you could be a DD (Debian Developer) with the contributions you listed (even translator would suffice IIRC) which would have given you a vote in this GR, and thus be able to affect the direction of the project.

This is of course on a distro by distro basis, I as a Arch user had no say in the transition to systemd two years ago, and there were certainly some voices raised against the move, with the Arch leadership stating that if someone wants to maintain the old initscripts then they will continue to be supported, no one did, and that was that.

Now if we take Debian which is the topic here, they have a technical committee which handles the technical direction of a project, they decided through vote that they would go with systemd as the default init, over Upstart which was the closest contender (in fact the other options had no votes IIRC).

Ian Jackson was not happy with the result, tried to have the chairman kicked out, and then staged a GR which didn't pass, and then yet another which is the one we are discussing here. In this GR all DD's were given a vote, with a vast majority of the DD's favouring the already set path by the technical committee vote.

Really, do you think it is a "scary" level of entitlement that some of us only contribute to projects we continue to find useful?


No, I've always been a fan of the 'voting with your feet' principle, if you chose to contribute to a project under certain conditions, and that project no longer meets those conditions then there's nothing wrong in you no longer contributing.

However, again, unless the project states that your contributions (if any) give you a say in the direction of the project (or in this case, a say in what software developers/maintainers in that project must provide), then demanding that they do as you say is to me a 'scary level of entitlement'.

And just to make it clear, they are not doing this to be mean to you, they have a different opinion of where the project should be heading and what they should spend their volunteered time working on.

Reply Score: 5

RE: So...
by darknexus on Thu 20th Nov 2014 01:39 UTC in reply to "So..."
darknexus Member since:
2008-07-15

... they resolved it, by not resolving it?

Why not? It works for governments after all. ;)

Reply Score: 4

RE: So...
by Soulbender on Thu 20th Nov 2014 04:56 UTC in reply to "So..."
Soulbender Member since:
2005-08-18

It's the Debian way.

Reply Score: 3

Comment by gan17
by gan17 on Thu 20th Nov 2014 04:05 UTC
gan17
Member since:
2008-06-03

Sigh....

apt-cache depends mpd | grep systemd
Depends: libsystemd0

*facepalm

Reply Score: 3

RE: Comment by gan17
by Darkmage on Thu 20th Nov 2014 04:45 UTC in reply to "Comment by gan17"
Darkmage Member since:
2006-10-20

How the f--k does MPD need systemd? Seriously? This is basically going to result in Linux forking into Systemd/non systemd. There's been a lot of talk about people moving to FreeBSD, but I predict a larger split in Linux to a newer non-systemd/non-gnome distro. The lack of choice on whether you move to systemd or not is going to piss off a ton of people. Taking existing packages that don't depend on something and adding the dependancy is reason enough to ditch Debian. Never mind the fact that Debian still can't get a proper multi-lib setup working with wine. There's almost no reason to stay on the distro anymore.

Edited 2014-11-20 04:48 UTC

Reply Score: 3

RE[2]: Comment by gan17
by gan17 on Thu 20th Nov 2014 04:52 UTC in reply to "RE: Comment by gan17"
gan17 Member since:
2008-06-03

Fwiw, this was discovered on my Sid VM. Might be different by the time it hits Stable. Don't know for sure.

Reply Score: 2

RE: Comment by gan17
by Soulbender on Thu 20th Nov 2014 04:54 UTC in reply to "Comment by gan17"
Soulbender Member since:
2005-08-18

...what? Why would it even need that. At all. Ever.
systemd require no such thing so why do something such completely wrong-headed?
Just run it in the foreground, people. It's simple, reliable and efficient. Jesus, daemontools figured this out more than 10 years ago.

Edited 2014-11-20 04:55 UTC

Reply Score: 3

RE: Comment by gan17
by muep on Thu 20th Nov 2014 05:29 UTC in reply to "Comment by gan17"
muep Member since:
2006-03-19

Sigh....

"apt-cache depends mpd | grep systemd
Depends: libsystemd0

*facepalm
"

I took a quick grep at MPD sources, and it looks a bit like the software has at least support for socket activation. I guess libsystemd0 might include the easiest way to support that. Typically this kind of support is completely optional, so you should be able to run the software also on systems that do not run systemd as init.

But you need to have a copy of the library present even in cases where you run the application in a way that does not use any code from there. Otherwise, you would get an error from the dynamic linker when you try to start the program.

Reply Score: 2

RE: Comment by gan17
by zlynx on Thu 20th Nov 2014 21:45 UTC in reply to "Comment by gan17"
zlynx Member since:
2005-07-20

I have to ask if you know what libsystemd0 does.

Does it
- Provide easy to use but optional functions to integrate with systemd?

- Lock the program into using only systemd forever and ever.

Reply Score: 3

wut?
by Soulbender on Thu 20th Nov 2014 04:51 UTC
Soulbender
Member since:
2005-08-18

with some developers wishing to keep software uncoupled from any specific init implementation.


Uh, say what again? There is, to my knowledge, no init that *requires* software to work in any kind of non-standard way. Not even systemd.
Either you run the software in the foreground (which you should. Always.) or in the background (which you shouldn't. No. Just don't).
Admittedly software that can't be run in the foreground is broken by design but it will still work.

Reply Score: 3

Comment by twitterfire
by twitterfire on Thu 20th Nov 2014 08:15 UTC
twitterfire
Member since:
2008-09-11

They can try to switch to svchost.exe.

Reply Score: 3

RE: Comment by twitterfire
by darknexus on Thu 20th Nov 2014 20:52 UTC in reply to "Comment by twitterfire"
darknexus Member since:
2008-07-15

They can try to switch to svchost.exe.

Oh wow, that would be a show worth watching. Should they ever do this, beers on me. You got the popcorn?

Reply Score: 2

Comment by p13.
by p13. on Thu 20th Nov 2014 08:48 UTC
p13.
Member since:
2005-07-10

So ... all the packages will be compiled with systemd deps in the end.
The "choice" is but an illusion.

Reply Score: 4

RE: Comment by p13.
by zlynx on Thu 20th Nov 2014 21:51 UTC in reply to "Comment by p13."
zlynx Member since:
2005-07-20

They can link to a systemd support library. Or they can do a static link to it. Or they can just drop the source files from systemd into their program. Or they can write their very own functions to report startup success or do socket activation.

Out of those options the best one in my opinion is the shared library which makes it easy to fix bugs and uses less RAM.

But sure the software could use one of the other less good options just so the word "systemd" doesn't show up anywhere.

Reply Score: 4

RE[2]: Comment by p13.
by p13. on Thu 20th Nov 2014 21:55 UTC in reply to "RE: Comment by p13."
p13. Member since:
2005-07-10

Most repo packages are dynamically linked and will just come up with systemd as a dep.

Static linking is pretty rare and mostly used for portable and/or commercial software.
It's fine for a single application, but i can't see huge parts of the system compiling in or statically linking to their own versions of systemd. That would be horribly inefficient and a nightmare to maintain.

Reply Score: 3

RE[3]: Comment by p13.
by zlynx on Thu 20th Nov 2014 23:26 UTC in reply to "RE[2]: Comment by p13."
zlynx Member since:
2005-07-20

This isn't a dependency on systemd, the init daemon. libsystemd0 is a library with functions for communicating with systemd.

A static link of just the one library or dropping in the source files would only add a few KB.

Reply Score: 4

RE[4]: Comment by p13.
by p13. on Thu 20th Nov 2014 23:46 UTC in reply to "RE[3]: Comment by p13."
p13. Member since:
2005-07-10

16K a pop apparently, but the problem is more one of manageability and efficiency.

Just think of what would happen if there is a security hole in systemd.

Reply Score: 3

RE[4]: Comment by p13.
by p13. on Fri 21st Nov 2014 00:14 UTC in reply to "RE[3]: Comment by p13."
p13. Member since:
2005-07-10

Just did this very ugly thing out of curiosity:

for i in `ps -ef | awk '{if($8 ~ /\[/){gsub(/\[/,"",$8);gsub(/\]/,"",$8);gsub(/\/.*/,"",$8)}; print $8}'`;do j=$(which $i); if [[ $j != "" ]]; then ldd $j | grep systemd; fi; done
libsystemd-login.so.0 => /lib/x86_64-linux-gnu/libsystemd-login.so.0 (0x00007f6320266000)
libsystemd-daemon.so.0 => /lib/x86_64-linux-gnu/libsystemd-daemon.so.0 (0x00007f083061c000)
libsystemd-login.so.0 => /lib/x86_64-linux-gnu/libsystemd-login.so.0 (0x00007f86f77a5000)
libsystemd-login.so.0 => /lib/x86_64-linux-gnu/libsystemd-login.so.0 (0x00007fe7e0f6f000)
libsystemd-login.so.0 => /lib/x86_64-linux-gnu/libsystemd-login.so.0 (0x00007fb17848c000)
libsystemd-login.so.0 => /lib/x86_64-linux-gnu/libsystemd-login.so.0 (0x00007f97545c0000)
libsystemd-login.so.0 => /lib/x86_64-linux-gnu/libsystemd-login.so.0 (0x00007fe03e829000)
libsystemd-login.so.0 => /lib/x86_64-linux-gnu/libsystemd-login.so.0 (0x00007fc08e3bc000)
libsystemd-login.so.0 => /lib/x86_64-linux-gnu/libsystemd-login.so.0 (0x00007ff40b8a6000)
libsystemd-login.so.0 => /lib/x86_64-linux-gnu/libsystemd-login.so.0 (0x00007fc0f8bcd000)
libsystemd-login.so.0 => /lib/x86_64-linux-gnu/libsystemd-login.so.0 (0x00007f461341c000)
libsystemd-login.so.0 => /lib/x86_64-linux-gnu/libsystemd-login.so.0 (0x00007fd1bf3e4000)
libsystemd-login.so.0 => /lib/x86_64-linux-gnu/libsystemd-login.so.0 (0x00007f1800d9d000)
libsystemd-login.so.0 => /lib/x86_64-linux-gnu/libsystemd-login.so.0 (0x00007f0a606df000)

du -csh /lib/x86_64-linux-gnu/libsystemd-login.so.0.7.1
56K /lib/x86_64-linux-gnu/libsystemd-login.so.0.7.1

du -csh /lib/x86_64-linux-gnu/libsystemd-daemon.so.0.0.10
16K /lib/x86_64-linux-gnu/libsystemd-daemon.so.0.0.10

Reply Score: 3