4 ms·

It seems to be my understanding that Linux will allow supporting any hardware or software API as long as at least a few people care about it. It doesn't matter

It seems to be my understanding that Linux will allow supporting any hardware or software API as long as at least a few people care about it. It doesn't matter how old or impractical it is. This is not a criticism, but I would like to deeply understand, what does Linux leadership want it to be? An OS that just runs on anything for the sake of it? It already seems true that Linux aspires to be much more than what UNIX is. It can be a dumping ground of sorts for your ideas and research projects. As long as the code does something useful enough without corrupting the entire system, it seems to be fair game. That is kind of freeing and it would stand to benefit the project to be communicated more directly. These are my observations.

zozbot234 7y ago
> It seems to be my understanding that Linux will allow supporting any hardware or software API as long as at least a few people care about it. It doesn't matter how old or impractical it is. It's not quite like that, there's quite a bit of hardware support that has been dropped along the way. It's not enough for people to care about stuff, they have to care about it enough that they maintain that support in line with kernel devs' expectations. That's not always easy.
sansnomme 7y ago
A counterexample would be that most other open source Unixes' "MVP-level" of hardware support meant that none of them gained much traction and market share. The real world does not run entirely on Thinkpads.
- msla 7y ago
  More to the point, the real world doesn't run entirely on Real Computers. It happens again and again: There's a plateau of Real Computers, where Real People do Real Work, because they wouldn't deign to deal with the oddities and lack of performance peasants put up with on their Bitty Boxes. Then something nasty happens, and those Bitty Boxes become more capable without becoming correspondingly more expensive. All of a sudden, the companies selling Real Computers no longer have a value proposition: Their stuff may not be hugely more capable, but at least it's massively more expensive! Eventually, not even the Real People can continue to ignore the fact the Toys are smoking them in every benchmarkable metric aside from cool factor. It happened to DEC when minicomputers fell to PCs, and it happened to Sun and SGI when the "workstation" category got folded into the "somewhat-more-expensive-than-usual PC" category. Linux originally ignored the extreme low-end PCs, but in 1991, it was pretty clear than 16-bit x86 CPUs were more trouble than they were worth in the Unix-like world and it wasn't a good move to mutilate the kernel to fit on a kind of system which was rapidly becoming obsolete. However, Linux is not ignoring the current Bitty Boxes, the SBCs which can run the kernel with no compromises once you navigate the weirdness of ARM-based hardware. (Yes, there is a project to run Linux on 16-bit x86 chips and other MMU-less CPUs. It's called ELKS and it was never very active.) https://github.com/jbruchon/elks https://github.com/jbruchon/elks
stefan_ 7y ago
That makes it sound like Linux is just a big dump of code. In reality, if you want to add some sort of device support, it's expected that your code will fit in with the rest of it, e.g. use device tree and all the other infrastructure, and use it correctly. Some subsystems have stricter guidelines yet, e.g. if you want to add support for graphics hardware to DRM, the graphics subsystem, there must be a corresponding, fully featured open source userland implementation for it.
newnewpdro 7y ago
It's definitely not a dumping ground, try get a new feature merged into Linux and see how easy it is. The inclusive attitude is exceptional for drivers and new architecture support. The kernel is intended to be portable, the more architectures supported the more mature the abstractions become. So as long as there's existing hardware capable of running the kernel for the new architecture, you probably won't meet much resistance landing support, provided it's not a disaster.
- etaioinshrdlu 7y ago
  This part seems pretty special: > the more architectures supported the more mature the abstractions become.
  - asveikau 7y ago
    It's become trendy to say that supporting more things means only new work and a big waste of time. The "validating the abstraction" thing is overlooked. The OpenBSD guys also used to write about this for why they support obsolete hardware and compiling itself on said hardware. That it surfaces bugs.
kick 7y ago
You're acting as if a kernel can only have one aim. This is not a criticism, but I would like to deeply understand, what does Linux leadership want it to be? An OS that just runs on anything for the sake of it? NetBSD falls under this, for example, but NetBSD also has many other benefits and aims than "Can run on your Burroughs P100." Linux has ~5k people a year contributing patches to the kernel; it can have many aims, because "Linux leadership" doesn't mean "Linux dictatorship."
kjs3 7y ago
It can be a dumping ground of sorts for your ideas and research projects. I don't think so. I mean, yes, there's some pretty obscure things in there. But to be part of the mainline kernel means that you're code must pass all sorts of gatekeepers. The code has to meet a number of quality and appropriateness checks. A good number of eyeballs have to sign off, or at least no object.

zozbot234 7y ago

> It seems to be my understanding that Linux will allow supporting any hardware or software API as long as at least a few people care about it. It doesn't matter how old or impractical it is. It's not quite like that, there's quite a bit of hardware support that has been dropped along the way. It's not enough for people to care about stuff, they have to care about it enough that they maintain that support in line with kernel devs' expectations. That's not always easy.

sansnomme 7y ago

A counterexample would be that most other open source Unixes' "MVP-level" of hardware support meant that none of them gained much traction and market share. The real world does not run entirely on Thinkpads.

msla 7y ago
More to the point, the real world doesn't run entirely on Real Computers. It happens again and again: There's a plateau of Real Computers, where Real People do Real Work, because they wouldn't deign to deal with the oddities and lack of performance peasants put up with on their Bitty Boxes. Then something nasty happens, and those Bitty Boxes become more capable without becoming correspondingly more expensive. All of a sudden, the companies selling Real Computers no longer have a value proposition: Their stuff may not be hugely more capable, but at least it's massively more expensive! Eventually, not even the Real People can continue to ignore the fact the Toys are smoking them in every benchmarkable metric aside from cool factor. It happened to DEC when minicomputers fell to PCs, and it happened to Sun and SGI when the "workstation" category got folded into the "somewhat-more-expensive-than-usual PC" category. Linux originally ignored the extreme low-end PCs, but in 1991, it was pretty clear than 16-bit x86 CPUs were more trouble than they were worth in the Unix-like world and it wasn't a good move to mutilate the kernel to fit on a kind of system which was rapidly becoming obsolete. However, Linux is not ignoring the current Bitty Boxes, the SBCs which can run the kernel with no compromises once you navigate the weirdness of ARM-based hardware. (Yes, there is a project to run Linux on 16-bit x86 chips and other MMU-less CPUs. It's called ELKS and it was never very active.) https://github.com/jbruchon/elks https://github.com/jbruchon/elks

stefan_ 7y ago

That makes it sound like Linux is just a big dump of code. In reality, if you want to add some sort of device support, it's expected that your code will fit in with the rest of it, e.g. use device tree and all the other infrastructure, and use it correctly. Some subsystems have stricter guidelines yet, e.g. if you want to add support for graphics hardware to DRM, the graphics subsystem, there must be a corresponding, fully featured open source userland implementation for it.

newnewpdro 7y ago

It's definitely not a dumping ground, try get a new feature merged into Linux and see how easy it is. The inclusive attitude is exceptional for drivers and new architecture support. The kernel is intended to be portable, the more architectures supported the more mature the abstractions become. So as long as there's existing hardware capable of running the kernel for the new architecture, you probably won't meet much resistance landing support, provided it's not a disaster.

etaioinshrdlu 7y ago
This part seems pretty special: > the more architectures supported the more mature the abstractions become.
- asveikau 7y ago
  It's become trendy to say that supporting more things means only new work and a big waste of time. The "validating the abstraction" thing is overlooked. The OpenBSD guys also used to write about this for why they support obsolete hardware and compiling itself on said hardware. That it surfaces bugs.

kick 7y ago

You're acting as if a kernel can only have one aim. This is not a criticism, but I would like to deeply understand, what does Linux leadership want it to be? An OS that just runs on anything for the sake of it? NetBSD falls under this, for example, but NetBSD also has many other benefits and aims than "Can run on your Burroughs P100." Linux has ~5k people a year contributing patches to the kernel; it can have many aims, because "Linux leadership" doesn't mean "Linux dictatorship."

kjs3 7y ago

It can be a dumping ground of sorts for your ideas and research projects. I don't think so. I mean, yes, there's some pretty obscure things in there. But to be part of the mainline kernel means that you're code must pass all sorts of gatekeepers. The code has to meet a number of quality and appropriateness checks. A good number of eyeballs have to sign off, or at least no object.