I'm mad about linux distros again today and I think I am realizing why this is so hard for me to write about systemically: I have a software engineer brain and so I try to model the various problems as technical problems.
-
In short, all the volunteer-based distributions need to have a gigantic conference where they all come together and *agree to stop working on about 99% of them*, to pool efforts to make a real Linux platform. A lot of people will need to put their egos aside and decide to acquiesce to solutions they believe to be technically inferior, in order to be able to address the diffusion of labor into pointlessly recreating basically the same toolchain a thousand times.
@glyph This is partly why I often joke, there are a lot more ‘religious’ arguments than ‘technical’ arguments in tech (yes, I know there *can* be objective, technical arguments, but often feels people argue their religion as ‘objective’ XD)
-
@cthos @miss_rodent I think I do have some nuanced structural critique of flatpak that I sadly don’t have time to get into right now, but if I am being honest most of my systems have a weird quirk where user data lives outside home directories on external media and this causes flatpak’s weird slightly-wrong but makes-things-mostly-work heuristics absolutely violently explode in ways which cause huge issues that contributes to an overall *immediate* negative impression
@glyph @cthos @miss_rodent i think flatpak (and AppImage, not snap) are the closest thing to standardization you are going to be able to convince linux devs to make. The desktop linux platform already has a lot which is close across distros, all the large ones use systemd and pipewire, mostly use Wayland graphics and KDE or GNOME, or a skin on top of those. GNOME especially expects a system to be set up in a more standard fashion, so distros have less flexability to pointlessly diverge in ways that break apps. Most gui apps are possible to flatpak, and run on almost any distro that is near standard (sorry for your systems which youve made difficult to support by accidently working at cross purposes to flatpak assumptions, but its hard to maintain compatibility when every computer-toucher wants to be their own ISV). Unfortunately its going to take a long time to convince Shuttleworth and Canonical that they are wasting everyones time with snaps, but Ubuntu isnt as popular as it once was. Its also going to take a long time to convince Debian, Fedora or Arch packagers that they should stop and target flatpak on the Freedesktop runtimes instead. There are a lot of devs who are personally offended by inefficiencies in the design of flatpak that leads to vendoring of libraries and duplication between runtimes, but i dont see any other way, the distro approach of deduplicating libraries creates bugs of its own and is unsustainable labor, the improvements to software build and integration that distro feedback brings to gui devs is probably not worth the effort it takes.
I dont think you are going to have much luck convincing volunteers to not work on what makes them happy, or for any existing distro to jump off a cliff for the good of the community, but you can make them irrelevant by inventing something better that the original gui dev community likes and can make work themselves. You can ask them to join your project if it looks successful and fun
-
@matt @cthos @miss_rodent flatpak does not address the deficiencies or the expense of interacting with a zillion different compositors, or for that matter different audio systems or GPS daemons. the kinds of apps that need to interact with the platform need an API shaped in terms of d-bus endpoints, and the problem that flatpak addresses is one of .so files. flatpak also requires manual management of filesystem permissions, which means apps are just slightly dysfunctional
@glyph i could see an effort around freedesktop and flatpak to define what dbus apis are expected to be provided by the distro/desktop to have full compatibility, and what might be outside those expectations. I dont think it makes sense to have flatpaks that only work on some distros/desktops because they depend on unique components, the baseline for running flatpak needs to declare what is required and provide reasonable errors if am amateur ISV tries to run it somehere impoverished
-
@cthos @matt @miss_rodent sorry I do not mean to be mean about this. but it seems like they’ve done some really good work here and are trying to snatch defeat from the jaws of victory. I have *heard* about bazzite and bluefin. at some length. i knew they were immutable distros. I had considered installing them. I did not even realize they were largely compatible let alone more or less the same thing
@glyph i think this is irreconcilable though because the software and out of the box config of an immutable distro is fixed, so you need to have different complete builds if you want different stuff in the base system. The compatability for apps is high though because the OS maker is pulling all the components out of the same pool. Like i dont think you want your general purpose desktop to boot into Steam, like Bazzite handheld builds do, but any of the flatpak apps will run just the same on all of the family, like the choice of specific flavor is driven by the hardware and purpose of the computer, but they can all run the same stuff outside the base os
-
@glyph i think this is irreconcilable though because the software and out of the box config of an immutable distro is fixed, so you need to have different complete builds if you want different stuff in the base system. The compatability for apps is high though because the OS maker is pulling all the components out of the same pool. Like i dont think you want your general purpose desktop to boot into Steam, like Bazzite handheld builds do, but any of the flatpak apps will run just the same on all of the family, like the choice of specific flavor is driven by the hardware and purpose of the computer, but they can all run the same stuff outside the base os
@raven667 The Bazzite desktop builds don't auto-boot steam, though (but you *can* tell it to do that)
-
@glyph @cthos @miss_rodent i think flatpak (and AppImage, not snap) are the closest thing to standardization you are going to be able to convince linux devs to make. The desktop linux platform already has a lot which is close across distros, all the large ones use systemd and pipewire, mostly use Wayland graphics and KDE or GNOME, or a skin on top of those. GNOME especially expects a system to be set up in a more standard fashion, so distros have less flexability to pointlessly diverge in ways that break apps. Most gui apps are possible to flatpak, and run on almost any distro that is near standard (sorry for your systems which youve made difficult to support by accidently working at cross purposes to flatpak assumptions, but its hard to maintain compatibility when every computer-toucher wants to be their own ISV). Unfortunately its going to take a long time to convince Shuttleworth and Canonical that they are wasting everyones time with snaps, but Ubuntu isnt as popular as it once was. Its also going to take a long time to convince Debian, Fedora or Arch packagers that they should stop and target flatpak on the Freedesktop runtimes instead. There are a lot of devs who are personally offended by inefficiencies in the design of flatpak that leads to vendoring of libraries and duplication between runtimes, but i dont see any other way, the distro approach of deduplicating libraries creates bugs of its own and is unsustainable labor, the improvements to software build and integration that distro feedback brings to gui devs is probably not worth the effort it takes.
I dont think you are going to have much luck convincing volunteers to not work on what makes them happy, or for any existing distro to jump off a cliff for the good of the community, but you can make them irrelevant by inventing something better that the original gui dev community likes and can make work themselves. You can ask them to join your project if it looks successful and fun
@glyph @cthos @miss_rodent thinking about this more as i read further down the thread that the immutable distros (Silverblue/Bluefin/Bazzite et al) do effectively define am api and runtime by what is in the distro and what is left out. While it is _possible_ to layer on a local filesystem image built out of rpms on top of ostree, nothing can rely on that and its not the primary or expected way to extend the system with more apps, flatpak or stuff installed in your homedir like AppImage or distrobox/toolbox containers are the primary way to add on local software, which is a robust layering.
-
@raven667 The Bazzite desktop builds don't auto-boot steam, though (but you *can* tell it to do that)
@cthos right, i run Bazzite on a laptop and a desktop, they start Steam on login, but not in big picture mode, but it was my understanding that the handheld builds *do* jump right into steam, just like steamos, eg on Lenovo Legion Go, including support for unique hardware in the base system that wouldnt be necessary or appropriate for a more general computing desktop, like motion sensors or rgb lighting
-
@cthos right, i run Bazzite on a laptop and a desktop, they start Steam on login, but not in big picture mode, but it was my understanding that the handheld builds *do* jump right into steam, just like steamos, eg on Lenovo Legion Go, including support for unique hardware in the base system that wouldnt be necessary or appropriate for a more general computing desktop, like motion sensors or rgb lighting
@raven667 @glyph @matt @miss_rodent they do, yes. I run Bazzite on a RoG Ally. That’s just a flag in a config file AFAIK though, i think there is a ujust script that can toggle the behavior.
-
@raven667 @glyph @matt @miss_rodent they do, yes. I run Bazzite on a RoG Ally. That’s just a flag in a config file AFAIK though, i think there is a ujust script that can toggle the behavior.
@raven667 @glyph @matt @miss_rodent the RGB stuff is handled by handheld companion which is installed by default on the handheld builds but not the PC builds
-
@matt @cthos @miss_rodent I have never seen an app do this in a way which appeared to work. my experience is limited though. glad to hear it at least exists though!
@glyph i had to look up what a powerbox was, but flatpak is built around the concept and wouldnt work without a functioning xdg file chooser that lives in the baseos outside the flatpak. Ive never had a problem with it, but ive only used flatpak on GNOME on Fedora, Silverblue and Bazzite, where its a first class citizen and well integrated. Flatpak can only be a universal app packaging runtime if it actually works on all the desktop systems without fuss and drama.
-
Fixing the problem involves driving a truck through that load-bearing "to some extent". Doing a big ugly multi-party negotiation to figure out how we can EOL Qt, to replace it with Gtk everywhere, and get all the Gtk devs on board with being *extremely* nice to the Qt people as we sunset their work. (Did you feel a little thrill because I picked Gtk instead of Qt? Well, I flipped a coin. Imagine I said Qt wins instead of Gtk. You're gonna be that mad about *big* parts of this, no matter what.)
@glyph there are problems, but I don't see the redundant efforts of various duplicated components as a core issue.
A lot of Linux is about avoiding monoculture. vim *and* emacs. Snap *and* flatpack.
It's something that emerges naturally from people trying to create a hackable platform.I think we'd be better off if people shared ideas and infrastructure without denigrating one another's work. We should have both Qt and Gtk so that they can cross pollinate.
-
@glyph there are problems, but I don't see the redundant efforts of various duplicated components as a core issue.
A lot of Linux is about avoiding monoculture. vim *and* emacs. Snap *and* flatpack.
It's something that emerges naturally from people trying to create a hackable platform.I think we'd be better off if people shared ideas and infrastructure without denigrating one another's work. We should have both Qt and Gtk so that they can cross pollinate.
@glyph To be clear, I agree with your complaint, as I read it. It's the twofold
- you aren't providing something non-developers can use
- you aren't providing something developers can easily targetCanonical is trying to make Ubuntu the desktop distro. And tons of software ships as .debs, whether or not that's really the best choice.
The wild English garden of Linux can continue to exist, alongside a TiVo-ized, consumer oriented Ubuntu. But if you lose the anarchy, it's not Linux.
-
@glyph Honestly, I think that is a reason to move further in the other direction, and become more diverse and hostile to corporate interests.
I think consolidating and trying to act more like the commercial-capitalist OSes is an ethical and social failure; the diversity and chaotic aspect of the ecosystem are a functional pillar of the community.
@miss_rodent @glyph and the more diverse and messy things get, the less time and energy will be put into making accessibility actually good, because it'll be reinvented a thousand times
-
@miss_rodent @glyph and the more diverse and messy things get, the less time and energy will be put into making accessibility actually good, because it'll be reinvented a thousand times
@freya @glyph It's not like the corporate consolidated model has made accessibility a major priority either?
In my own case, linux & BSDs have been more accessible than the proprietary OSes since I switched in the 00's.
I've known folks with other disabilities who prefer(ed) linux's accessibility options, but, that seems to vary quite a bit by person & disability.
It's definitely not great as-is, but, won't necessarily get worse or stop improving from more diversity and options existing. -
@freya @glyph It's not like the corporate consolidated model has made accessibility a major priority either?
In my own case, linux & BSDs have been more accessible than the proprietary OSes since I switched in the 00's.
I've known folks with other disabilities who prefer(ed) linux's accessibility options, but, that seems to vary quite a bit by person & disability.
It's definitely not great as-is, but, won't necessarily get worse or stop improving from more diversity and options existing.@freya @glyph To Clarify: My own case mainly being that my paws don't work very well - and have only gotten worse over time, I routinely can't use a mouse effectively, so being able to do basically everything from a command line, customize keyboard shortcuts & remap the keyboard easily, change settings in a text file instead of needing to navigate menus, etc. are all significant accessibility concerns on my end.
-
@glyph @miss_rodent I mean, I regularly come across Flatpak wrappers around software that the maintainers did not themselves package that also just works and is maintained by one person occasinally running a CI script though so I don't think this is necessarily true for all applications.
Also RE: filesystem permissions, it's now extremely rare that I have to fire up flatseal and make any changes at all for my normal software.
@cthos @glyph @miss_rodent I very much don't want to run applications packaged by Some Random Person In Kansas. I make a deliberate effort to avoid them! I want to run applications packaged by the author/ISV or, failing that, by a team that I can have some trust in to do work of a certain standard. A distribution maintainer team would be the paradigm example of the latter. The 'Snapcrafters' model is maybe borderline.
-
@cthos @glyph @miss_rodent I very much don't want to run applications packaged by Some Random Person In Kansas. I make a deliberate effort to avoid them! I want to run applications packaged by the author/ISV or, failing that, by a team that I can have some trust in to do work of a certain standard. A distribution maintainer team would be the paradigm example of the latter. The 'Snapcrafters' model is maybe borderline.
@willegible @glyph @miss_rodent the point was about the level of effort, not about the “who”
-
@willegible @glyph @miss_rodent the point was about the level of effort, not about the “who”
@cthos Ah, right. Fair enough!
-
@freya @glyph To Clarify: My own case mainly being that my paws don't work very well - and have only gotten worse over time, I routinely can't use a mouse effectively, so being able to do basically everything from a command line, customize keyboard shortcuts & remap the keyboard easily, change settings in a text file instead of needing to navigate menus, etc. are all significant accessibility concerns on my end.
@miss_rodent @glyph yeah, and for that it works great. unfortunately if you use a screenreader, it's somewhere between a trashfire and a disaster
-
In short, all the volunteer-based distributions need to have a gigantic conference where they all come together and *agree to stop working on about 99% of them*, to pool efforts to make a real Linux platform. A lot of people will need to put their egos aside and decide to acquiesce to solutions they believe to be technically inferior, in order to be able to address the diffusion of labor into pointlessly recreating basically the same toolchain a thousand times.
@glyph Sorry but this won't work. Some requirements are incompatible with each other.
There are distros that runs with a read-only rootfs from a CD and distros with daily upgrades. There are distros for 128 Go servers and distros for 64 Mo wifi routers. There are distros for machines that constantly sleep to preserve batteries and distros for servers with UPS that shall never go down. There are hardened distros and tinkerer-friendly distros. There are privacy-preserving distros, corporate-friendly remotely-managed distros and no-administration auto-upgrading distros. There are move-fast-break-compatibility distros and distros backward compatible with 10 years old software.
If you don't account for all of them then your unified solution will not gain broad adoption.
