6 ms·

It wasn't long ago that Linux users fancied themselves the underdog being sidelined in favor of Windows. Now, the Linux users have become the Goliath flaunting

It wasn't long ago that Linux users fancied themselves the underdog being sidelined in favor of Windows. Now, the Linux users have become the Goliath flaunting their weight and key spokespeople even encouraging the rejection of all other platforms. It is a community defined by myopia, arrogance and a refusal to look outside its borders.

JoshTriplett 11y ago
Linux has many different communities, not all of whom share the same opinions (or level of snarkiness). Some Linux developers may feel as you suggest, or more charitably, perhaps they just want to conserve their limited development resources focusing on providing the most benefit to the most users. But I don't think that view has become universal or even a majority, and I still regularly see projects merging support for other platforms, especially other Free Software platforms. I've merged such patches myself, written portability libraries, and even gone out of my way to test software I've written on GNU/Hurd. I've also seen ideas from such platforms influence Linux, and vice versa. I certainly hope nobody views Linux and its community as consisting entirely of the kinds of people whose snarky remarks make the news. We could do with far less of those people. In my more idealistic moments, I wonder how much better we could do if we focused on making one kernel better rather than half a dozen. Then again, in those same moments, I also wonder how much better we could do if we focused on making one desktop environment or browser better, too. None of those seem likely to happen.
- deleted 11y ago
  [deleted]
- vu3rdd 11y ago
  While what you are saying is very true, recent developments around systemd seem to have changed a few people to target linux-kernel based systems than the BSDs. As the autoconf files suggest, a lot of GNU software was written in the most general way possible, targeting even the macos/osx/windows/aix/hpux etc. In this age of easy virtual machine installations, it seems odd that software authors of popular software are not targeting at least the BSDs.
  - JoshTriplett 11y ago
    > As the autoconf files suggest, a lot of GNU software was written in the most general way possible, targeting even the macos/osx/windows/aix/hpux etc. GNU software originally ran on proprietary UNIX systems by necessity (because no non-proprietary UNIX systems existed), hence their portability; even after Free Software systems existed, having such software available on proprietary UNIX systems provided a great advertisement for GNU (especially since the GNU software typically worked better, and users could obtain tools for free with full source that they previously had to purchase separately in binary form). More recent software (GNU and otherwise) doesn't typically include compatibility with obscure proprietary UNIX systems (especially long-dead ones), because such systems no longer particularly matter, and seem unlikely to gain new users. Portability to, for instance, HP-UX or Cray systems isn't even worth the time spent detecting and maintaining crazy build-time conditionals, or even the minor chance of introducing a bug. And, perhaps more importantly, the authors of the software don't particularly want to test on such systems, and a port you don't regularly test won't keep working. Even a back-of-the-envelope order-of-magnitude estimate of the total amount of developer time, system time, and power consumed running ./configure scripts that autodetect conditions nobody seems likely to ever use again produces some scary numbers. ./configure takes an obscenely long time to run, often far longer than make. > In this age of easy virtual machine installations, it seems odd that software authors of popular software are not targeting at least the BSDs. That doesn't seem odd to me at all. For most software, I wouldn't mind taking patches to support BSD, but that doesn't mean I'll go install a BSD system, try to figure out BSD conventions and policy, fix portability issues myself, and maintain continuous integration for BSD to make sure it keeps working. If I wanted to put time and effort into testing my software for portability to other systems, I'd first confirm that it built and ran on Fedora in addition to Debian; I've encountered issues with that due to Fedora's incompatible paths for 32-bit/64-bit libraries. There are exceptions: I went out of my way to do exactly that as part of making sure XCB ran on the Hurd. I did that partly for novelty (I knew nothing about the Hurd, and afterward I knew slightly more than nothing), and partly because XCB needs to run everywhere X and Xlib can. Even then, though, the resulting port got maintained by actual Hurd users. So while I'd take a patch to support BSD, I'd rely on the submitter of the patch to keep it working over time, and to let me know if it broke. (And if someone felt sufficiently dedicated to do so, I'd probably give them commit access to help maintain it.) But in the absence of a dedicated BSD developer interested in maintaining the port, I can definitely understand why people wouldn't go out of their way to target BSD.
- Sanddancer 11y ago
  The Unix community tried making one desktop environment better. It was called Motif, which mutated into CDE. Pushing monocultures leads to bland and a lack of creation, because you end up pissing off end users, like what happens when MS changes the start menu functionality, for example. One kernel is even worse. OS research is still very young, and different types of operations need very different sorts of kernels. For an example based on the original article, getting information from /proc requires three system calls. You have to open the pseudo-file, and in the process allocate memory for a file descriptor, you have to make another system call to get the information, and then a third to close the file after you're done. That's six jumps in and out of kernel space just for one operation. For some tasks, especially when you're starting to get into hard realtime systems, that can lead to unacceptable amounts of delay. After all, would you be satisfied if the one kernel people settled around was the windows kernel?
  - JoshTriplett 11y ago
    > One kernel is even worse. OS research is still very young, and different types of operations need very different sorts of kernels. For an example based on the original article, getting information from /proc requires three system calls. You have to open the pseudo-file, and in the process allocate memory for a file descriptor, you have to make another system call to get the information, and then a third to close the file after you're done. That's six jumps in and out of kernel space just for one operation. As it turns out, I'm working on a solution for that exact problem, within the Linux kernel. I don't see any particular obstacles to doing so. As far as I know, Linux and BSD don't drastically differ from an "OS research" perspective. People doing OS kernel research that needs a "very different sort of kernel" tend to build a custom kernel, or run on L4 or similar. And sometimes that research makes its way into production kernels. > After all, would you be satisfied if the one kernel people settled around was the windows kernel? No, because it isn't Free Software, and nobody outside of Microsoft can change it.
    - i336_ 11y ago
      > As it turns out, I'm working on a solution for that exact problem, within the Linux kernel. I don't see any particular obstacles to doing so. oooh. I'd be really interested to learn about this... what exactly are you doing? (What can you do?!)
vacri 11y ago
You're not going to win people to your cause by responding to overgeneralisation with overgeneralisation.

JoshTriplett 11y ago

Linux has many different communities, not all of whom share the same opinions (or level of snarkiness). Some Linux developers may feel as you suggest, or more charitably, perhaps they just want to conserve their limited development resources focusing on providing the most benefit to the most users. But I don't think that view has become universal or even a majority, and I still regularly see projects merging support for other platforms, especially other Free Software platforms. I've merged such patches myself, written portability libraries, and even gone out of my way to test software I've written on GNU/Hurd. I've also seen ideas from such platforms influence Linux, and vice versa. I certainly hope nobody views Linux and its community as consisting entirely of the kinds of people whose snarky remarks make the news. We could do with far less of those people. In my more idealistic moments, I wonder how much better we could do if we focused on making one kernel better rather than half a dozen. Then again, in those same moments, I also wonder how much better we could do if we focused on making one desktop environment or browser better, too. None of those seem likely to happen.

deleted 11y ago
[deleted]
vu3rdd 11y ago
While what you are saying is very true, recent developments around systemd seem to have changed a few people to target linux-kernel based systems than the BSDs. As the autoconf files suggest, a lot of GNU software was written in the most general way possible, targeting even the macos/osx/windows/aix/hpux etc. In this age of easy virtual machine installations, it seems odd that software authors of popular software are not targeting at least the BSDs.
- JoshTriplett 11y ago
  > As the autoconf files suggest, a lot of GNU software was written in the most general way possible, targeting even the macos/osx/windows/aix/hpux etc. GNU software originally ran on proprietary UNIX systems by necessity (because no non-proprietary UNIX systems existed), hence their portability; even after Free Software systems existed, having such software available on proprietary UNIX systems provided a great advertisement for GNU (especially since the GNU software typically worked better, and users could obtain tools for free with full source that they previously had to purchase separately in binary form). More recent software (GNU and otherwise) doesn't typically include compatibility with obscure proprietary UNIX systems (especially long-dead ones), because such systems no longer particularly matter, and seem unlikely to gain new users. Portability to, for instance, HP-UX or Cray systems isn't even worth the time spent detecting and maintaining crazy build-time conditionals, or even the minor chance of introducing a bug. And, perhaps more importantly, the authors of the software don't particularly want to test on such systems, and a port you don't regularly test won't keep working. Even a back-of-the-envelope order-of-magnitude estimate of the total amount of developer time, system time, and power consumed running ./configure scripts that autodetect conditions nobody seems likely to ever use again produces some scary numbers. ./configure takes an obscenely long time to run, often far longer than make. > In this age of easy virtual machine installations, it seems odd that software authors of popular software are not targeting at least the BSDs. That doesn't seem odd to me at all. For most software, I wouldn't mind taking patches to support BSD, but that doesn't mean I'll go install a BSD system, try to figure out BSD conventions and policy, fix portability issues myself, and maintain continuous integration for BSD to make sure it keeps working. If I wanted to put time and effort into testing my software for portability to other systems, I'd first confirm that it built and ran on Fedora in addition to Debian; I've encountered issues with that due to Fedora's incompatible paths for 32-bit/64-bit libraries. There are exceptions: I went out of my way to do exactly that as part of making sure XCB ran on the Hurd. I did that partly for novelty (I knew nothing about the Hurd, and afterward I knew slightly more than nothing), and partly because XCB needs to run everywhere X and Xlib can. Even then, though, the resulting port got maintained by actual Hurd users. So while I'd take a patch to support BSD, I'd rely on the submitter of the patch to keep it working over time, and to let me know if it broke. (And if someone felt sufficiently dedicated to do so, I'd probably give them commit access to help maintain it.) But in the absence of a dedicated BSD developer interested in maintaining the port, I can definitely understand why people wouldn't go out of their way to target BSD.
Sanddancer 11y ago
The Unix community tried making one desktop environment better. It was called Motif, which mutated into CDE. Pushing monocultures leads to bland and a lack of creation, because you end up pissing off end users, like what happens when MS changes the start menu functionality, for example. One kernel is even worse. OS research is still very young, and different types of operations need very different sorts of kernels. For an example based on the original article, getting information from /proc requires three system calls. You have to open the pseudo-file, and in the process allocate memory for a file descriptor, you have to make another system call to get the information, and then a third to close the file after you're done. That's six jumps in and out of kernel space just for one operation. For some tasks, especially when you're starting to get into hard realtime systems, that can lead to unacceptable amounts of delay. After all, would you be satisfied if the one kernel people settled around was the windows kernel?
- JoshTriplett 11y ago
  > One kernel is even worse. OS research is still very young, and different types of operations need very different sorts of kernels. For an example based on the original article, getting information from /proc requires three system calls. You have to open the pseudo-file, and in the process allocate memory for a file descriptor, you have to make another system call to get the information, and then a third to close the file after you're done. That's six jumps in and out of kernel space just for one operation. As it turns out, I'm working on a solution for that exact problem, within the Linux kernel. I don't see any particular obstacles to doing so. As far as I know, Linux and BSD don't drastically differ from an "OS research" perspective. People doing OS kernel research that needs a "very different sort of kernel" tend to build a custom kernel, or run on L4 or similar. And sometimes that research makes its way into production kernels. > After all, would you be satisfied if the one kernel people settled around was the windows kernel? No, because it isn't Free Software, and nobody outside of Microsoft can change it.
  - i336_ 11y ago
    > As it turns out, I'm working on a solution for that exact problem, within the Linux kernel. I don't see any particular obstacles to doing so. oooh. I'd be really interested to learn about this... what exactly are you doing? (What can you do?!)

vacri 11y ago

You're not going to win people to your cause by responding to overgeneralisation with overgeneralisation.