Poettering: Revisiting how we put together Linux systems

Posted Sep 5, 2014 16:14 UTC (Fri) by paulj (subscriber, #341)
In reply to: Poettering: Revisiting how we put together Linux systems by raven667
Parent article: Poettering: Revisiting how we put together Linux systems

The problem is that ABIs extend outside of the base distro, to state this proposals intends to share across the multiple installed distros. E.g., in $HOME, etc, and /var.

Poettering: Revisiting how we put together Linux systems

Posted Sep 5, 2014 17:07 UTC (Fri) by raven667 (subscriber, #5198) [Link] (11 responses)

I didn't think that was what dlang was referring to but maybe that's my confusion, there is definitely work to maintain compatibility for config data in /home and IPC protocols in /var, but that is a much smaller and more well defined set than /usr.

One thing if this proposal is worked on that it puts pressure on distros to define a subset as stable and it puts pressure on app makers to standardize on few runtimes so even if this proposal does not become the standard, it may create the discussion which that results in a new LSB standard for distros binary compatibility which is much more comprehensive than the weak-sauce LSB currently is. I think the discussion of what goes into /usr is very useful on its own even if nothing else comes out of this proposal.

Poettering: Revisiting how we put together Linux systems

Posted Sep 5, 2014 18:02 UTC (Fri) by paulj (subscriber, #341) [Link] (10 responses)

Yes, it'd be good if this kind of thing gave app/desktop-env an incentive again to think about the compatibility issues of their state, so that they'd eventually fix things and we could move towards an ideal world.

However, note that this is the "This is how the world should be, and we're going to change our bit to make it so, and if it ends up hurting users then that will supply the pressure needed to make the rest of the world so" approach. An approach to making progress which I think has been tried at least a few times before in the Linux world, which I'm not sure always helps in the greater scheme of things. The users who get hurt may not be willing to stick around to see the utopia realised, and not everything may get fixed.

Poettering: Revisiting how we put together Linux systems

Posted Sep 5, 2014 18:53 UTC (Fri) by raven667 (subscriber, #5198) [Link] (9 responses)

Well there is no real pressure to take this protocol on, it exists and people can work on it if they choose and they believe it solves problems for them, but there is no authority who can push such things, they only happen by consensus.

Poettering: Revisiting how we put together Linux systems

Posted Sep 6, 2014 10:40 UTC (Sat) by paulj (subscriber, #341) [Link] (8 responses)

Unless of course control of some important project is used to lever this idea into place. ;)

Poettering: Revisiting how we put together Linux systems

Posted Sep 7, 2014 15:17 UTC (Sun) by raven667 (subscriber, #5198) [Link] (7 responses)

You can build it and they still might not come, this proposal doesn't exist, even if systemd implements it, without an economy of /usr providers willing to package their runtimes and apps in this fashion. While I know you are just being funny but it still feeds into the trolls to think there is some magic evil power which compels and corrupts the distros, rather than they just independently coming to the conclusion that systemd is a good idea. Poettering can't be evil, I've seen pictures, he doesn't even have a moustache to twirl!

Poettering: Revisiting how we put together Linux systems

Posted Sep 8, 2014 9:30 UTC (Mon) by paulj (subscriber, #341) [Link] (6 responses)

Poettering isn't evil, no. He writes a lot of useful code. Though, he's not perfect either of course.

If I had to make a criticism, it wouldn't be of him specifically, but of an attitude common amongst Linux user-space devs, that holds that it is acceptable to burn users with breakage, in the quest for some future code or system utopia. So code gets written that assumes other components are perfect, so that if they are not breakage will expose them and those other components will eventually get fixed. Code gets rewritten, because the old code was ugly, and the new code will of course be much better, and worth the regressions.

The root cause of this seems to be because of the fractured way Linux works. There is generally no authority that can represent the users' interests for stability. There is no authority that can coördinate and ensure that if subsystem X requires subsystem Y to implement something that was never really used before, that subsystem Y is given time to do this before X goes out in the wild. Or no authority to coördinate rewrites and release cycles.

Instead the various fractured groups of developers, in a way, interact by pushing code to users who, if agitated sufficiently, will investigate and report bugs or even help fix them.

You could also argue this is because of a lack of QA resources. As a result of which the user has to help fill that role. However, the lack of resources could also be seen as being in part due to the Linux desktop user environment never having grown out of treating the user as QA, and regularly burning users away.

Poettering: Revisiting how we put together Linux systems

Posted Sep 8, 2014 10:59 UTC (Mon) by dlang (guest, #313) [Link]

The distro supposed to be the ones that make sure that Y is working before they ship X.

Poettering: Revisiting how we put together Linux systems

Posted Sep 8, 2014 11:59 UTC (Mon) by pizza (subscriber, #46) [Link] (4 responses)

> If I had to make a criticism, it wouldn't be of him specifically, but of an attitude common amongst Linux user-space devs, that holds that it is acceptable to burn users with breakage, in the quest for some future code or system utopia. So code gets written that assumes other components are perfect, so that if they are not breakage will expose them and those other components will eventually get fixed. Code gets rewritten, because the old code was ugly, and the new code will of course be much better, and worth the regressions.

I've been on both sides of this argument, as both an end-user and as a developer.

In balance, I'd much rather have the situation today; where stuff is written assuming the other components work properly, and where bugs get fixed in their actual locations rather than independently, inconsistently, and incompatibly papered over.

For example, this attitude is why Sound and [Wireless] Networking JustWork(tm) in Linux today.

The workaround-everything approach is only necessary when you are stuck with components you can't fix at the source -- ie proprietary crap. We don't have that problem, so let's do this properly!

The days where completely independent, underspecified, and barely-coupled components are a viable path forward have been over for a long, long time.

Poettering: Revisiting how we put together Linux systems

Posted Sep 8, 2014 12:33 UTC (Mon) by nye (subscriber, #51576) [Link] (1 responses)

>For example, this attitude is why Sound and [Wireless] Networking JustWork(tm) in Linux today

Except they don't.

A couple of examples:

My home machine has both the front channels and the rear channels connected, for a total of four audio channels. In Windows, I go in to my sound properties and pick the 'quadrophonic' option; now applications like games or VLC will mix the available channels appropriately so that I get sound correctly coming out of the appropriate speakers - not only all four channels, but all four channels *correctly*, so that, for example, 5.1 audio is appropriately remixed by the application without any configuration needed.

I had a look at how I might get this in OpenSuSE earlier this year, and eventually concluded either that PA simply can't do this *at all*, or that if it can, nobody knows how[0]. I did find some instructions for how to set up something like this using a custom ALSA configuration, though that would have required that applications be configured to know about it (rather than doing the right thing automatically), and I never got around to trying it out before giving up on OS for a multitude of reasons.

Another example:
I have a laptop running Kubuntu. Occasionally, I can persuade it to make a wireless connection, but mostly it just doesn't - no messages, just nothing happening. It also doesn't properly manage the wired network, especially if the cable is unplugged or replugged. NetworkManager is essentially just a black box that might work, and if it doesn't then you're screwed. I eventually persuaded it to kind-of work without NM, though it then required some manual effort to switch between wired and wireless networks.

A related example:
For several consecutive releases, the Ubuntu live CD images didn't have fully working wired networking out of the box, due to some DHCP cock-up. Sadly I no longer remember the specifics for certain, but I *believe* it was ignoring the DNS setting specified by the DHCP server, and manually disabling the DHCP client and editing resolv.conf fixed the problem. There may have been something more to it than that, like getting the default gateway wrong; I don't recall.

It's great that some people have more reliable wireless thanks to NM, but it's not great that this comes at the expense of fully-functional ethernet.

[0] Some more recent googling has turned up more promising discussion of configuration file options, but I no longer have that installation to test out.

Poettering: Revisiting how we put together Linux systems

Posted Sep 8, 2014 13:14 UTC (Mon) by pizza (subscriber, #46) [Link]

> My home machine has both the front channels and the rear channels connected, for a total of four audio channels. In Windows, I go in to my sound properties and pick the 'quadrophonic' option; now applications like games or VLC will mix the available channels appropriately so that I get sound correctly coming out of the appropriate speakers - not only all four channels, but all four channels *correctly*, so that, for example, 5.1 audio is appropriately remixed by the application without any configuration needed.

The last three motherboards I've had, with multi-channel audio, have JustWorked(tm) once I selected the appropriate speaker configuration under Fedora/GNOME. Upmixed and downmixed PCM output, and even the analog inputs are mixed properly too.

(Of course, some of the responsibility for handling this is in the hands of the application, even if only to query and respect the system speaker settings instead of using a fixed configuration)

> I have a laptop running Kubuntu. Occasionally, I can persuade it to make a wireless connection, but mostly it just doesn't - no messages, just nothing happening. It also doesn't properly manage the wired network, especially if the cable is unplugged or replugged. NetworkManager is essentially just a black box that might work, and if it doesn't then you're screwed. I eventually persuaded it to kind-of work without NM, though it then required some manual effort to switch between wired and wireless networks.

NM has been effectively flawless for me for several years now (even with switching back and forth), also with Fedora, but that shouldn't matter in this case -- I hope you filed a bug report. Folks can't fix problems they don't know about.

> For several consecutive releases, the Ubuntu live CD images didn't have fully working wired networking out of the box, due to some DHCP cock-up. Sadly I no longer remember the specifics for certain, but I *believe* it was ignoring the DNS setting specified by the DHCP server, and manually disabling the DHCP client and editing resolv.conf fixed the problem. There may have been something more to it than that, like getting the default gateway wrong; I don't recall.

I can't speak to Ubuntu's DHCP stuff here (did you file a bug?) but I've seen a similar problem in the past using dnsmasq's DHCP client -- the basic problem I found was that certian DHCP servers were a bit..special in their configuration and the result is that the DHCP client didn't get a valid DNS entry. dnsmasq eventually implemented a workaround for the buggy server/configuration. This was maybe three years ago?

> It's great that some people have more reliable wireless thanks to NM, but it's not great that this comes at the expense of fully-functional ethernet.

Come on, that's being grossly unfair. Before NM came along, wireless was more unreliable than not, with every driver implementing the WEXT stuff slightly differently requiring every client (or user) to treat every device type slightly differently. Now the only reason things don't work is if the hardware itself is unsupported, and that's quite rare these days.

Poettering: Revisiting how we put together Linux systems

Posted Sep 8, 2014 15:38 UTC (Mon) by paulj (subscriber, #341) [Link] (1 responses)

“For example, this attitude is why Sound and [Wireless] Networking JustWork(tm) in Linux today.”

While I agree this path has led to sound and wireless working well in Linux today, I would disagree it was the only possible path. I'd suggest there were other paths available that would have ultimately led to the same result, but taken more care to avoid regressions and/or provide basic functionality even when other components hadn't been updated to match some new specification.

What's the point of utopia, if you've burned off all your users getting there? Linux laptops were once well-represented at über-techy / dev conferences, now it's OS X almost everywhere.

Poettering: Revisiting how we put together Linux systems

Posted Sep 8, 2014 17:12 UTC (Mon) by pizza (subscriber, #46) [Link]

> While I agree this path has led to sound and wireless working well in Linux today, I would disagree it was the only possible path.

...perhaps you are correct, but those other paths would have taken considerably longer, leading to a different sort of user burning.

> What's the point of utopia, if you've burned off all your users getting there? Linux laptops were once well-represented at über-techy / dev conferences, now it's OS X almost everywhere.

These days, Linux just isn't a cool counterculture status symbol any more. It's part of the boring infrastructure that's someone else's problem.

Anyway. The technical ones basically boil down to the benefits of Apple controlling the entire hardware/software/cloud stack -- Stuff JustWorks(tm). As long as you color within the lines, anyway.