4 ms·

Kind of wild to think that you can run a newer Linux version in Scratch than on a lot of physical devices. Also gives "Linux From Scratch" a new meaning.

by xnzakg 3y ago

yjftsjthsd-h 3y ago
In fairness, a lot of the friction on real devices is from it being a real device; VMs have fewer and simpler drivers to deal with. (And nobody cares about stability in a PoC)
- charcircuit 3y ago
  A lot of friction also comes from kernel modules not having a stable API they can target meaning they need to be updated for new versions.
  - josephcsible 3y ago
    There doesn't need to be a stable API. They should just upstream their drivers into the kernel tree.
    - FreeFull 3y ago
      Someone has to actually maintain the driver in the tree. Drivers that don't have maintainers end up being removed from the kernel.
      - josephcsible 3y ago
        Yes, but that's way less work than maintaining an out-of-tree one is. Since fixes for kernel API changes are then the responsibility of whoever changed the API, instead of the driver's maintainer, it's basically the same amount of work it would be if the kernel did have a stable API.
    - charcircuit 3y ago
      That is not always possible due to licensing like OpenZFS's kernel module. There may also be trade secrets in a kernel module that they do not want to reveal by upstreaming. Upstreaming code takes time and it is not guarenteed that your patches will be accepted where an out of tree module can be created instantly. It may not be needed, but in practice kernel modules will exist and make upgrading Linux harder than it needs to be. A stable API is about providing value and saving time for driver developers and end users. It is no coincidence that successful operating systems like Windows, Mac, and Android have stable ABIs that you can use to make drivers.
      - josephcsible 3y ago
        > That is not always possible due to licensing like OpenZFS's kernel module. Aren't these sorts of hardware drivers generally written in-house by the company who makes the hardware? Can't they pick whatever license they want since they own the copyright? > There may also be trade secrets in a kernel module that they do not want to reveal by upstreaming. A company that asserts the existence of "trade secrets" in kernel modules deserves to have to do the extra work. All kernel modules should be open source.
        charcircuit 3y ago
        >Aren't these sorts of hardware drivers generally written in-house by the company who makes the hardware? Can't they pick whatever license they want since they own the copyright? I gave you an example of OpenZFS where this is not the case. The code in hardware drivers may not be owned entirely by the company. It could have even been done entirely by a third party which may not even still be in business. Even if they were willing to license there would be extra costs in making the code into a state that can be upstreamed. Even then it might just never be accepted. >A company that asserts the existence of "trade secrets" in kernel modules deserves to have to do the extra work. This is an unreasonable stance that hurts end users. If no one exists to maintain the kernel module end users will get stuck on old, insecure, kernel versions. Even if they get updated it prevents people from upgrading until there is a version all drivers support. >All kernel modules should be open source. That is your opinion. It is not true in practice meaning there is utility in having a stable ABI.
- freedomben 3y ago
  Indeed, for people who have never had to work with real hardware before, it is shocking how complex it is and the level of hackiness it sometimes takes to make it "work" (I say "work" because often times drivers are doing insanely hacky things to make it seem like it's working, even though it's duct tape and bubble gum under the hood). Not just when things are going right, but also when they go wrong (which can involve real-world physical things that break expectations, like damn voltage fluctuations or a physically damaged component for example!). When you only have "virtual" hardware to control, things are much, much, much more simple.

Kind of wild to think that you can run a newer Linux version in Scratch than on a lot of physical devices. Also gives "Linux From Scratch" a new meaning.

by xnzakg 3y ago

Kind of wild to think that you can run a newer Linux version in Scratch than on a lot of physical devices. Also gives "Linux From Scratch" a new meaning.

yjftsjthsd-h 3y ago

In fairness, a lot of the friction on real devices is from it being a real device; VMs have fewer and simpler drivers to deal with. (And nobody cares about stability in a PoC)

charcircuit 3y ago
A lot of friction also comes from kernel modules not having a stable API they can target meaning they need to be updated for new versions.
- josephcsible 3y ago
  There doesn't need to be a stable API. They should just upstream their drivers into the kernel tree.
  - FreeFull 3y ago
    Someone has to actually maintain the driver in the tree. Drivers that don't have maintainers end up being removed from the kernel.
    - josephcsible 3y ago
      Yes, but that's way less work than maintaining an out-of-tree one is. Since fixes for kernel API changes are then the responsibility of whoever changed the API, instead of the driver's maintainer, it's basically the same amount of work it would be if the kernel did have a stable API.
  - charcircuit 3y ago
    That is not always possible due to licensing like OpenZFS's kernel module. There may also be trade secrets in a kernel module that they do not want to reveal by upstreaming. Upstreaming code takes time and it is not guarenteed that your patches will be accepted where an out of tree module can be created instantly. It may not be needed, but in practice kernel modules will exist and make upgrading Linux harder than it needs to be. A stable API is about providing value and saving time for driver developers and end users. It is no coincidence that successful operating systems like Windows, Mac, and Android have stable ABIs that you can use to make drivers.
    - josephcsible 3y ago
      > That is not always possible due to licensing like OpenZFS's kernel module. Aren't these sorts of hardware drivers generally written in-house by the company who makes the hardware? Can't they pick whatever license they want since they own the copyright? > There may also be trade secrets in a kernel module that they do not want to reveal by upstreaming. A company that asserts the existence of "trade secrets" in kernel modules deserves to have to do the extra work. All kernel modules should be open source.
      - charcircuit 3y ago
        >Aren't these sorts of hardware drivers generally written in-house by the company who makes the hardware? Can't they pick whatever license they want since they own the copyright? I gave you an example of OpenZFS where this is not the case. The code in hardware drivers may not be owned entirely by the company. It could have even been done entirely by a third party which may not even still be in business. Even if they were willing to license there would be extra costs in making the code into a state that can be upstreamed. Even then it might just never be accepted. >A company that asserts the existence of "trade secrets" in kernel modules deserves to have to do the extra work. This is an unreasonable stance that hurts end users. If no one exists to maintain the kernel module end users will get stuck on old, insecure, kernel versions. Even if they get updated it prevents people from upgrading until there is a version all drivers support. >All kernel modules should be open source. That is your opinion. It is not true in practice meaning there is utility in having a stable ABI.
freedomben 3y ago
Indeed, for people who have never had to work with real hardware before, it is shocking how complex it is and the level of hackiness it sometimes takes to make it "work" (I say "work" because often times drivers are doing insanely hacky things to make it seem like it's working, even though it's duct tape and bubble gum under the hood). Not just when things are going right, but also when they go wrong (which can involve real-world physical things that break expectations, like damn voltage fluctuations or a physically damaged component for example!). When you only have "virtual" hardware to control, things are much, much, much more simple.