Dyson OS Is Trying To Pair Debian With The Illumos Kernel

[Ibidem]

I guess you are referring to the usage of logind.

Even if we rule out that any other service will ever implement the logind interface, there is no reason to believe that GNOME would not support an alternative if one exists.

After all they did support ConsoleKit before it became unmaintained.

Yesterday someone on the Devuan ml started a lengthy thread by requesting that the developers not waste their time on packaging/supporting anything gnome-related beyond gtk.
Downthread, Olav Vitters wrote this:

I mainly wanted to make clear that it is possible to discuss. I'm
indifferent if that's taken up or not. If you want to offer GNOME
there's various options for the session support:
- shim (seems to still require logind)
- ConsoleKit (or the ConsoleKit2 fork)
+ then add back the suspend stuff and figure out UPower 1.0 situation

There's still ConsoleKit support, but not sure for how long that will be
kept. With shim and systembsd there might not be a real need for it
anymore as pretty much most will be using GNOME with those APIs.

That was the first I'd heard of ConsoleKit2; it's a fork by Eric Koegel (of Xfce fame).

[andyprough]

Yesterday someone on the Devuan ml started a lengthy thread by requesting that the developers not waste their time on packaging/supporting anything gnome-related beyond gtk.

Seems like a very wise idea. Slackware doesn't officially support Gnome. Seems to be working fine for them.

[chimpy]

The distro with "the proper suction".

I just had to throw that out there.

[Xaero_Vincent]

I just had to throw that out there.

Last time I looked, Consumer Reports seemed to think Dyson vacuum cleaners sucked at sucking.

[curaga]

"Nothing sucks like Electrolux"

"We suck more -Microsoft"

[jonnor]

Except how some upstream projects may begin to depend on Linux-only systemd interfaces--future Gnome, for instance. I don't think the problem with systemd ever had to do with it's service launch and management system but what everything else it does and how it impacts things when upstream developers decide to rely on it for their projects.

Then the people who want to use it on non-systemd projects need to step up and maintain the non-systemd codepaths upstream, or create compatible implementations of the interfaces.

Nothing new here. This is the way it has always worked in FOSS.
You can always eat someone elses cake for free, but you only get the cake of your chosing if you are willing to bake.

[Delgarde]

I guess you are referring to the usage of logind.

Even if we rule out that any other service will ever implement the logind interface, there is no reason to believe that GNOME would not support an alternative if one exists.

After all they did support ConsoleKit before it became unmaintained.

Yes, but they didn't support ConsoleKit as an alternative to logind - they supported it because that was the code that was being used before logind came along, and supporting the old code was useful in the short term for migration.

I suspect that going forward, GNOME *would* refuse to support an alternative API, because doing so would be a bunch more work for them... effort in writing the code, extra complexity to deal with long-term... there'd need to be be a pretty compelling reason to do it. In the case of logind, it provided that compelling reason - the framework it provided was so much better than the CK-based code it replaced, allowed them to do things they couldn't easily do without it. Any alternative to logind would need to clear the same bar - it would need to be so superior to logind as to outright displace it...

[leech]

Yes, but they didn't support ConsoleKit as an alternative to logind - they supported it because that was the code that was being used before logind came along, and supporting the old code was useful in the short term for migration.

I suspect that going forward, GNOME *would* refuse to support an alternative API, because doing so would be a bunch more work for them... effort in writing the code, extra complexity to deal with long-term... there'd need to be be a pretty compelling reason to do it. In the case of logind, it provided that compelling reason - the framework it provided was so much better than the CK-based code it replaced, allowed them to do things they couldn't easily do without it. Any alternative to logind would need to clear the same bar - it would need to be so superior to logind as to outright displace it...

I find it rather pathetic that so many people are pissed off at the GNOME project for using an existing API rather than writing their own like so many others do. I bet if all the other various *nix platforms create a compatible API with it, there probably wouldn't be as much bitching.

Most of the things I've seen so far with systemd are good benefits. I will say I have ran into a bit of nastiness with it on Debian Jessie though.

Apparently, if you have networking.service enabled, it takes an extra ~30 seconds to boot. So at some point I disabled it, so NetworkManager could just handle everything. Unfortunately NetworkManager only semi-supports setting up a Bridge. Or I should say it sets one up, just not correctly. Virt-Manager breaks, so if you're only using NetworkManager's bridge, it just won't use it correctly. And you can't create a bridge through virt-manager without networking.service enabled, because it's the one that creates /run/network folder. So I had to either A) manually create that folder each time I booted. B) enable networking.service.

[MoonMoon]

Apparently, if you have networking.service enabled, it takes an extra ~30 seconds to boot. So at some point I disabled it, so NetworkManager could just handle everything. Unfortunately NetworkManager only semi-supports setting up a Bridge. Or I should say it sets one up, just not correctly. Virt-Manager breaks, so if you're only using NetworkManager's bridge, it just won't use it correctly. And you can't create a bridge through virt-manager without networking.service enabled, because it's the one that creates /run/network folder. So I had to either A) manually create that folder each time I booted. B) enable networking.service.

HAven't tried it on Debian, but on my Gentoo systems systemd-networkd can set up my network, including bridges for the containers, just fine. Maybe you should try that.

[leech]

HAven't tried it on Debian, but on my Gentoo systems systemd-networkd can set up my network, including bridges for the containers, just fine. Maybe you should try that.

Yeah, that would be the equivalent of the networking.service file under Debian. It isn't so much that it isn't working (it is the part that does) it's that Network Manager (which is supposed to be the easy way to do it) does not.

But with networking.service enabled, it takes much longer to boot, but if I let just Network Manager do it, it is extremely fast.

Bridging, (the way it usually works) has br0 interface with the IP, and it's bridged to eth0, but Network Manager doesn't do that, and sticks the IP on eth0, and br0 just sits there being useless, which is why it's not working.