8 ms·

This feels very right. The problem is there are few entities invested enough in Linux as a consumer platform, that have the motivation to push things forward. T

This feels very right. The problem is there are few entities invested enough in Linux as a consumer platform, that have the motivation to push things forward. To make the decisions on what their "Reference" system is. Valve is maybe the closest?

hackyhacky 1y ago
Ubuntu, for all their faults, were the first to make Linux really easy to install and made it "just work." That counts for a lot. Since then, their output has been disappointing. Part of the problem, is that "Linux/Unix culture" is very averse to coordination. When someone does try to establish a common baseline, there is inevitable pushback. The classic example is systemd, which fills a desperately needed hole in the Linux ecosystem, but is to this day criticized for being antithetical to the ethos of, I guess, gluing together an operating system with chewing gum and bits of string. The fact is that many users would rather have a pile of software that can be hand-assembled into an OS, instead of an actual cohesive, consistent platform. So I can't blame people too much for not trying to establish standards. If OSS had created LSP, there would be 20 different incompatible variations, and they would insist "We like it this way." EDIT: averse, not adverse
- clipsy 1y ago
  > The classic example is systemd, which fills a desperately needed hole in the Linux ecosystem If the hole is desperately needed, why would you want to fill it?
  - hackyhacky 1y ago
    > If the hole is desperately needed, why would you want to fill it? Good point. Let me rephrase: "Systemd fills a hole in the Linux ecosystem, which desperately needs to be filled." This version of the sentence is more correct and conveniently functions as a double entendre.
    - j16sdiz 1y ago
      systemd killed many projects and use cases along its way. Better integration for mainstream, sure. but at the end we have less choice.
      - hackyhacky 1y ago
        > but at the end we have less choice. This is exactly my point: you want "diverse choices", which is fundamentally at odds with "cohesive functionality." The article is about LSP, an imperfect standard, but nevertheless a standard. The prioritization of "choice" above all else is why the OSS world is incapable of creating standards. > systemd killed many projects The purpose of software is to fulfill a need. Creation of software projects is simply a side-effect of that process. It's good that systemd killed many projects, because those people who had worked on those projects can now work on a problem that hasn't already been solved.
      - shadowgovt 1y ago
        Sometimes the end user actually suffers from too much choice. Choice implies complexity, and there are some places less complexity is quite desirable. I still periodically, when setting up a new Linux machine, have to figure out why the audio frameworks are fighting, for example. The fact that "frameworks" is plural there makes everything harder for me, the end user. (I compare Python and Node environment management frequently here. Python standardized the protocol for setting up an environment. Wise, better than nothing, but now I have to care whether something is using conda or poetry or some several other options I don't know. Node has npm. If there's a package, it's in npm. To setup a Node service, use npm. One thing to know, one thing to get good at, one thing to use. Environment management with Node is much easier than in Python).
- Joel_Mckay 1y ago
  Indeed, "good" doesn't matter if the OS is a pain to use. The Driver support issues are essentially a theological war between FOSS ideals, and mystery OEM binaries. Most of the linux kernel code is still the driver modules, and board support packages. The desktop options have always been a mess of forks and bodged applets to make it useful. Ubuntu balances the purity of Debian with practical user experience (we could all write a book about UEFI shenanigans.) RedHat focuses more on hardened server use-cases. Is it worse than Win11 ? depends what you are doing, and what people consider is the low bar for messing with users. =3
- linguae 1y ago
  There is another factor at play: different users value different things. For example, there are some people who don't like systemd, not because they are enamored with classic startup scripts, but because they take issue with systemd's design. It's not that they dislike coherent, consistent platforms: they just take disagreement with the design decisions of that particular platform. For example, I like the classic Mac OS and Jobs-era Mac OS X, but I don't like GNOME. All of these are coherent platforms, but they have different philosophies. The difference between open source software versus proprietary software is that if users don't like the changes made to proprietary software, there choices are limited to the following: 1. Dealing with the changes even though they don't like it. 2. Sticking to an older version of the software before the changes took place (which can be difficult due to needing to deal with a changing environment and thus is only delaying the inevitable). 3. Switching to an alternative product, if available. 4. Writing an alternative product (which can be a massive undertaking). Open source software provides additional options: 5. Fork the older version of the software. If enough people maintain this fork, then this becomes a viable alternative to the changed software. 6. Use the new version of the software, but modify it to one's liking. This is the blessing and the curse of open source software; we have the power to make our own environments, but some software is quite labor-intensive to write, and we need to rely on other people's libraries, systems, and tools to avoid reinventing wheels, but sometimes those dependencies change in ways that we disagree with. I think the best way to mitigate this is making software easier to develop and more modular, though inevitably there are always going to be disagreements when using dependencies that we don't directly control.
charcircuit 1y ago
Google is the closest with Android. They were even able to get Adobe to port photoshop which other Linux operating systems have failed to have happen. Despite Android's success the rest of the consumer Linux distributions chose to ignore it and continue on with what they were already doing. Trying to have them coordinate around what is succeeding is seemingly impossible.
- hackyhacky 1y ago
  > Despite Android's success the rest of the consumer Linux distributions chose to ignore it and continue on with what they were already doing. Trying to have them coordinate around what is succeeding is seemingly impossible. I'm not sure I understand you here. What do you think other Linux distros should have done?
  - charcircuit 1y ago
    >What do you think other Linux distros should have done? Collectively contributing to getting AOSP running on desktops, and then also working on backwards compatibility to be able to package their preexisting apps into Android apps. This would allow for there to be a common app platform for developers to target Linux with.
    - hackyhacky 1y ago
      > Collectively contributing to getting AOSP running on desktops, and then also working on backwards compatibility to be able to package their preexisting apps into Android apps. This would allow for there to be a common app platform for developers to target Linux with. As a common target, AOSP isn't a very good one. AOSP ran on desktops. (Maybe it still does, haven't tried it in a while.) It was still a mobile OS, though, so it wasn't good on the desktop, but it ran. It also uses very old kernels. Other than the kernel, the Android UI is completely different from conventional Linux. Any Gnome or Qt app would have to be completely rewritten to support it, and would probably have to run in the JVM. Basically, if the Linux community followed your plan, they would have to commit a huge effort to port everything to what is essentially a completely different, incompatible OS in every respect except the kernel, and their reward would be to live in subservience to the whims of Google in supporting their product which Google themselves never had enough faith in to make it a proper desktop OS. It seems that the benefit does not justify the investment.
keyringlight 1y ago
Valve doesn't seem interested in doing much on the desktop, they seem to have constrained themselves (probably wisely) to working on areas directly related to their business and products.

hackyhacky 1y ago

Ubuntu, for all their faults, were the first to make Linux really easy to install and made it "just work." That counts for a lot. Since then, their output has been disappointing. Part of the problem, is that "Linux/Unix culture" is very averse to coordination. When someone does try to establish a common baseline, there is inevitable pushback. The classic example is systemd, which fills a desperately needed hole in the Linux ecosystem, but is to this day criticized for being antithetical to the ethos of, I guess, gluing together an operating system with chewing gum and bits of string. The fact is that many users would rather have a pile of software that can be hand-assembled into an OS, instead of an actual cohesive, consistent platform. So I can't blame people too much for not trying to establish standards. If OSS had created LSP, there would be 20 different incompatible variations, and they would insist "We like it this way." EDIT: averse, not adverse

clipsy 1y ago
> The classic example is systemd, which fills a desperately needed hole in the Linux ecosystem If the hole is desperately needed, why would you want to fill it?
- hackyhacky 1y ago
  > If the hole is desperately needed, why would you want to fill it? Good point. Let me rephrase: "Systemd fills a hole in the Linux ecosystem, which desperately needs to be filled." This version of the sentence is more correct and conveniently functions as a double entendre.
  - j16sdiz 1y ago
    systemd killed many projects and use cases along its way. Better integration for mainstream, sure. but at the end we have less choice.
    - hackyhacky 1y ago
      > but at the end we have less choice. This is exactly my point: you want "diverse choices", which is fundamentally at odds with "cohesive functionality." The article is about LSP, an imperfect standard, but nevertheless a standard. The prioritization of "choice" above all else is why the OSS world is incapable of creating standards. > systemd killed many projects The purpose of software is to fulfill a need. Creation of software projects is simply a side-effect of that process. It's good that systemd killed many projects, because those people who had worked on those projects can now work on a problem that hasn't already been solved.
    - shadowgovt 1y ago
      Sometimes the end user actually suffers from too much choice. Choice implies complexity, and there are some places less complexity is quite desirable. I still periodically, when setting up a new Linux machine, have to figure out why the audio frameworks are fighting, for example. The fact that "frameworks" is plural there makes everything harder for me, the end user. (I compare Python and Node environment management frequently here. Python standardized the protocol for setting up an environment. Wise, better than nothing, but now I have to care whether something is using conda or poetry or some several other options I don't know. Node has npm. If there's a package, it's in npm. To setup a Node service, use npm. One thing to know, one thing to get good at, one thing to use. Environment management with Node is much easier than in Python).
Joel_Mckay 1y ago
Indeed, "good" doesn't matter if the OS is a pain to use. The Driver support issues are essentially a theological war between FOSS ideals, and mystery OEM binaries. Most of the linux kernel code is still the driver modules, and board support packages. The desktop options have always been a mess of forks and bodged applets to make it useful. Ubuntu balances the purity of Debian with practical user experience (we could all write a book about UEFI shenanigans.) RedHat focuses more on hardened server use-cases. Is it worse than Win11 ? depends what you are doing, and what people consider is the low bar for messing with users. =3
linguae 1y ago
There is another factor at play: different users value different things. For example, there are some people who don't like systemd, not because they are enamored with classic startup scripts, but because they take issue with systemd's design. It's not that they dislike coherent, consistent platforms: they just take disagreement with the design decisions of that particular platform. For example, I like the classic Mac OS and Jobs-era Mac OS X, but I don't like GNOME. All of these are coherent platforms, but they have different philosophies. The difference between open source software versus proprietary software is that if users don't like the changes made to proprietary software, there choices are limited to the following: 1. Dealing with the changes even though they don't like it. 2. Sticking to an older version of the software before the changes took place (which can be difficult due to needing to deal with a changing environment and thus is only delaying the inevitable). 3. Switching to an alternative product, if available. 4. Writing an alternative product (which can be a massive undertaking). Open source software provides additional options: 5. Fork the older version of the software. If enough people maintain this fork, then this becomes a viable alternative to the changed software. 6. Use the new version of the software, but modify it to one's liking. This is the blessing and the curse of open source software; we have the power to make our own environments, but some software is quite labor-intensive to write, and we need to rely on other people's libraries, systems, and tools to avoid reinventing wheels, but sometimes those dependencies change in ways that we disagree with. I think the best way to mitigate this is making software easier to develop and more modular, though inevitably there are always going to be disagreements when using dependencies that we don't directly control.

charcircuit 1y ago

Google is the closest with Android. They were even able to get Adobe to port photoshop which other Linux operating systems have failed to have happen. Despite Android's success the rest of the consumer Linux distributions chose to ignore it and continue on with what they were already doing. Trying to have them coordinate around what is succeeding is seemingly impossible.

hackyhacky 1y ago
> Despite Android's success the rest of the consumer Linux distributions chose to ignore it and continue on with what they were already doing. Trying to have them coordinate around what is succeeding is seemingly impossible. I'm not sure I understand you here. What do you think other Linux distros should have done?
- charcircuit 1y ago
  >What do you think other Linux distros should have done? Collectively contributing to getting AOSP running on desktops, and then also working on backwards compatibility to be able to package their preexisting apps into Android apps. This would allow for there to be a common app platform for developers to target Linux with.
  - hackyhacky 1y ago
    > Collectively contributing to getting AOSP running on desktops, and then also working on backwards compatibility to be able to package their preexisting apps into Android apps. This would allow for there to be a common app platform for developers to target Linux with. As a common target, AOSP isn't a very good one. AOSP ran on desktops. (Maybe it still does, haven't tried it in a while.) It was still a mobile OS, though, so it wasn't good on the desktop, but it ran. It also uses very old kernels. Other than the kernel, the Android UI is completely different from conventional Linux. Any Gnome or Qt app would have to be completely rewritten to support it, and would probably have to run in the JVM. Basically, if the Linux community followed your plan, they would have to commit a huge effort to port everything to what is essentially a completely different, incompatible OS in every respect except the kernel, and their reward would be to live in subservience to the whims of Google in supporting their product which Google themselves never had enough faith in to make it a proper desktop OS. It seems that the benefit does not justify the investment.

keyringlight 1y ago

Valve doesn't seem interested in doing much on the desktop, they seem to have constrained themselves (probably wisely) to working on areas directly related to their business and products.