6 ms·

yes the beautiful advantage of having some super-forked kernel. the solution is to get everyone on the same kernel, which is then updatable - not hack together

by fowl2 2y ago

yes the beautiful advantage of having some super-forked kernel. the solution is to get everyone on the same kernel, which is then updatable - not hack together something that kinda works on top of a never updated snowflake

cageface 2y ago
The Linux kernel team has been hostile to binary drivers in the past. Is that not still the case?
- Matl 2y ago
  Binary drivers are hostile, not the Linux kernel.
  - askonomm 2y ago
    Ok no problem, I'll just ideology to run things.
    - klabb3 2y ago
      You don’t have to go anywhere near ideological debate to argue against binary blobs in the OS. The blobs could be verbatim from Stallman himself and blessed in the holy waters of EFF, and they would still be bad for dozens of technical reasons.
- vetinari 2y ago
  The linux kernel team understandably does not want to maintain overcomplicated shims, keep multiple versions of the same subsystem and debug opaque problems so some can keep their precious binaries secret. You keep the binaries, you get to maintain them and solve their problems. Seems fair.
  - cageface 2y ago
    Ok but this is also going to mean people are going to keep long lived forks, like Android, that do support binary drivers.
    - bayindirh 2y ago
      Maybe then companies should stop hiding their bad code and binary hacks behind closed source drivers and write proper open source ones instead. If they are using 3rd party IP, they should work with the providers for compromises, or license the patents and re-implement them. AMD and Intel did great strides on these fronts, not counting the money-loving people called HDMI forum.
      - oblio 2y ago
        I'd agree with you, but ever since mobile devices have taken off, aren't we much worse than before? In the last peak PC years, say, before 2011, I was under the impression that hardware vendors were starting to play ball, but now things seem super locked down and Linux seems to be falling behind in this tug of war between FOSS - binary-only.
        bayindirh 2y ago
        I think the problem with mobile devices is not the software but the hardware. These devices are locked down partly because of business interests (planned obsolescence), but another part is personal identity security. A run-of-the-mill Android or iOS device carries more secrets inside, which have much more weight (biometric data, TOTP, serial numbers used as secure tokens/unique identifiers, etc). This situation makes them a "trusted security device," and allowing tampering with it opens an unpleasant can of worms. For example, during my short Android stint, I found out that no custom ROM can talk with the secure element in my SIM, and I'm locked out of my e-signature, which is not pleasant. If manufacturers can find a good way to make these secure elements trustworthy without the need to close down the platform and weld shut, I think we can work around graphics and Wi-Fi drivers. Of course, we also have the "radio security" problem. Still, I think it can be solved by moving the wireless radio to an independent IP block inside the processor with a dedicated postbox and firmware system. While I'd love to have completely open radio firmware, the wireless world is much more complex (I'm a newbie HAM operator, so I have some slight ideas). So, the reasons for closing down a mobile device are varied, but the list indeed contains the desire for more money. If one of the hardware manufacturers decides to spend the money and pull the trigger (like AMD did with its HDMI/HDCP block), we can have secure systems that do not need locking down. Still, I'm not holding my breath, because while Apple loves to leave doors for tinkerers on their laptops, iPhone is their Fort Knox. On the other hand, I don't have the slightest confidence in the company called Broadcom to do the right thing.
  - bmacho 2y ago
    > The linux kernel team understandably does not want to maintain overcomplicated shims, The linux kernel team should offer a fixed compatibility layer for drivers. And for user applications too, while we are at it.
    - fireflash38 2y ago
      You are free to implement it.
      - throw0101d 2y ago
        >> The linux kernel team should offer a fixed compatibility layer for drivers. […] > You are free to implement it. But would it be accepted? From what I see with both NVidia's and OpenZFS's compat layer, it seems to indicate that the Linux kernel folks are actively hostile against any such thing. (Contrast this with, say, the FreeBSD folks where both the kernel- and user-land API/ABI stays frozen over the life of a major version release.)
        jpc0 2y ago
        > NVidia's and OpenZFS's compat layer I think this is more related to GPL licensing than them not wanting to assist. If it's completely generic then maybe, but how do you argue that the closed source Nvidia license or the dubious license for zfs can be linked to the GPL licensed kernel without being invitation of one of those licenses. Specially concidering how vague the GPL is regarding what it even means to be using GPL licensed code. If I present an API anyone can use and Nvidia happens to target it it's a different ballgame than if I implemented and shim specifically targeted at Nvidia's binary blob. To my knowledge the latter is a violation of GPL should it be the inverse and therefore an explicit exemption would need to be put in place for the shim in the GPL and that is the showstopper.
        Dylan16807 2y ago
        The hostility doesn't seem to care if things are generic or not. Remember when they broke ZFS by marking the "save FPU state" function as GPL-only? Telling the kernel to save registers so they can be used for scratch space is one of the most implementation-independent things you can do.
  - kaba0 2y ago
    > You keep the binaries, you get to maintain them and solve their problems. Seems fair. And you get to use modern mobile hardware like what a pinephone has.. lose, lose. Especially that modems simply can’t be open-source for the most part due to governmental regulations, so this everything open-source fairy tale doesn’t make much sense in mobile hardware.
    - yjftsjthsd-h 2y ago
      Notice that it's only mobile where that's a problem; x86 machines have apparently been doing the impossible for ~30 years now. And no, modems aren't an excuse; the modem itself can't be FOSS (probably) but it's just a self-contained device running its own firmware; there's nothing stopping you communicating with it via FOSS drivers.
      - kaba0 2y ago
        Did you miss the first, say, 25 years of the 30? Because I have literally reset my video driver blindly from terminal once, because it just failed after an update, and similar stuff. Also, this is pretty much due to the oligopoly of a few entities in hardware space, making it easier to support said devices, and standards. Phones aren’t built from a small selection of devices, and they often have patented firmware that the phone manufacturer couldn’t even publish even if they want to. As I shown, look at the best attempt at building an open-source phone. It sucks majorly.
        yjftsjthsd-h 2y ago
        Although I have thoughts on the matter, I'm not actually arguing about the quality of drivers, I'm arguing that x86 linux has had minimal problems with keeping all drivers in-tree, and if vendors want to support linux they've generally had no problem working with that. It is for some reason only mobile and embedded vendors that find it impossible to upstream drivers and that insist on shipping hacked-up vendor forks of ancient kernels. And again, firmware is a separate matter; there's plenty of cases of linux shipping blobs for the device to run, so long as the driver to talk to that device is FOSS.
- fransje26 2y ago
  The linux kernel is full of binary blobs. For better or worse..
  - ungamedplayer 2y ago
    Do you mean the firmware repo? Because I don't remember seeing any in the source code... But ist be looking at the wrong place.
    - anthk 2y ago
      The TGZ it's full of blobs.
    - 1oooqooq 2y ago
      anti gpl bots don't know the difference. they usually can't read code either. you're correct, only firmware tree have binary blobs.
    - fransje26 2y ago
      Ah. That would depend on the definition of "Linux kernel" then, yes. You are right, in the firmware tree, not in the pure kernel itself.
- 1oooqooq 2y ago
  good. everyone should be hostile to binary drivers. you have to not understand the first thing about kernel drivers to even consider binary drivers upstream. for starters, who provides a new binary when the api change every every new kernel version?
izacus 2y ago
Android has been booting off mainline for awhile now, so what are you going on about?
- dezgeg 2y ago
  Mainline kernel tends to have only basic support (if at all) for many SoCs that actually get used in phones, especially full power management support has been lacking.
  - izacus 2y ago
    Right, but it doesn't seem SoC vendors are budging on that - maybe it's slowly time for Linux to figure out a better approach?
    - bayindirh 2y ago
      Stopping planned obsolescence via closed drivers is a start, no?
    - dvdkon 2y ago
      Most PC and server hardware has FLOSS drivers (with proprietary firmware), even Qualcomm is upstreaming support for the new Snapdragon Elite (maybe it's made by a different team?). I think phone SoCs are the odd ones out, which sadly doesn't mean they'll improve any time soon. Supporting an ABI for binary drivers in Linux might help phones, but it would give everyone else a chance to regress in their support, so I understand Linux kernel developers' position.
    - yjftsjthsd-h 2y ago
      Linux isn't budging - maybe it's time for SoC vendors to figure out a better approach?
- dvdkon 2y ago
  Android can boot from a mainline kernel, but all that gets you is that phones run a kernel forked from mainline, not forked from Google's fork.

by fowl2 2y ago

cageface 2y ago

The Linux kernel team has been hostile to binary drivers in the past. Is that not still the case?

Matl 2y ago
Binary drivers are hostile, not the Linux kernel.
- askonomm 2y ago
  Ok no problem, I'll just ideology to run things.
  - klabb3 2y ago
    You don’t have to go anywhere near ideological debate to argue against binary blobs in the OS. The blobs could be verbatim from Stallman himself and blessed in the holy waters of EFF, and they would still be bad for dozens of technical reasons.
vetinari 2y ago
The linux kernel team understandably does not want to maintain overcomplicated shims, keep multiple versions of the same subsystem and debug opaque problems so some can keep their precious binaries secret. You keep the binaries, you get to maintain them and solve their problems. Seems fair.
- cageface 2y ago
  Ok but this is also going to mean people are going to keep long lived forks, like Android, that do support binary drivers.
  - bayindirh 2y ago
    Maybe then companies should stop hiding their bad code and binary hacks behind closed source drivers and write proper open source ones instead. If they are using 3rd party IP, they should work with the providers for compromises, or license the patents and re-implement them. AMD and Intel did great strides on these fronts, not counting the money-loving people called HDMI forum.
    - oblio 2y ago
      I'd agree with you, but ever since mobile devices have taken off, aren't we much worse than before? In the last peak PC years, say, before 2011, I was under the impression that hardware vendors were starting to play ball, but now things seem super locked down and Linux seems to be falling behind in this tug of war between FOSS - binary-only.
      - bayindirh 2y ago
        I think the problem with mobile devices is not the software but the hardware. These devices are locked down partly because of business interests (planned obsolescence), but another part is personal identity security. A run-of-the-mill Android or iOS device carries more secrets inside, which have much more weight (biometric data, TOTP, serial numbers used as secure tokens/unique identifiers, etc). This situation makes them a "trusted security device," and allowing tampering with it opens an unpleasant can of worms. For example, during my short Android stint, I found out that no custom ROM can talk with the secure element in my SIM, and I'm locked out of my e-signature, which is not pleasant. If manufacturers can find a good way to make these secure elements trustworthy without the need to close down the platform and weld shut, I think we can work around graphics and Wi-Fi drivers. Of course, we also have the "radio security" problem. Still, I think it can be solved by moving the wireless radio to an independent IP block inside the processor with a dedicated postbox and firmware system. While I'd love to have completely open radio firmware, the wireless world is much more complex (I'm a newbie HAM operator, so I have some slight ideas). So, the reasons for closing down a mobile device are varied, but the list indeed contains the desire for more money. If one of the hardware manufacturers decides to spend the money and pull the trigger (like AMD did with its HDMI/HDCP block), we can have secure systems that do not need locking down. Still, I'm not holding my breath, because while Apple loves to leave doors for tinkerers on their laptops, iPhone is their Fort Knox. On the other hand, I don't have the slightest confidence in the company called Broadcom to do the right thing.
- bmacho 2y ago
  > The linux kernel team understandably does not want to maintain overcomplicated shims, The linux kernel team should offer a fixed compatibility layer for drivers. And for user applications too, while we are at it.
  - fireflash38 2y ago
    You are free to implement it.
    - throw0101d 2y ago
      >> The linux kernel team should offer a fixed compatibility layer for drivers. […] > You are free to implement it. But would it be accepted? From what I see with both NVidia's and OpenZFS's compat layer, it seems to indicate that the Linux kernel folks are actively hostile against any such thing. (Contrast this with, say, the FreeBSD folks where both the kernel- and user-land API/ABI stays frozen over the life of a major version release.)
      - jpc0 2y ago
        > NVidia's and OpenZFS's compat layer I think this is more related to GPL licensing than them not wanting to assist. If it's completely generic then maybe, but how do you argue that the closed source Nvidia license or the dubious license for zfs can be linked to the GPL licensed kernel without being invitation of one of those licenses. Specially concidering how vague the GPL is regarding what it even means to be using GPL licensed code. If I present an API anyone can use and Nvidia happens to target it it's a different ballgame than if I implemented and shim specifically targeted at Nvidia's binary blob. To my knowledge the latter is a violation of GPL should it be the inverse and therefore an explicit exemption would need to be put in place for the shim in the GPL and that is the showstopper.
        Dylan16807 2y ago
        The hostility doesn't seem to care if things are generic or not. Remember when they broke ZFS by marking the "save FPU state" function as GPL-only? Telling the kernel to save registers so they can be used for scratch space is one of the most implementation-independent things you can do.
- kaba0 2y ago
  > You keep the binaries, you get to maintain them and solve their problems. Seems fair. And you get to use modern mobile hardware like what a pinephone has.. lose, lose. Especially that modems simply can’t be open-source for the most part due to governmental regulations, so this everything open-source fairy tale doesn’t make much sense in mobile hardware.
  - yjftsjthsd-h 2y ago
    Notice that it's only mobile where that's a problem; x86 machines have apparently been doing the impossible for ~30 years now. And no, modems aren't an excuse; the modem itself can't be FOSS (probably) but it's just a self-contained device running its own firmware; there's nothing stopping you communicating with it via FOSS drivers.
    - kaba0 2y ago
      Did you miss the first, say, 25 years of the 30? Because I have literally reset my video driver blindly from terminal once, because it just failed after an update, and similar stuff. Also, this is pretty much due to the oligopoly of a few entities in hardware space, making it easier to support said devices, and standards. Phones aren’t built from a small selection of devices, and they often have patented firmware that the phone manufacturer couldn’t even publish even if they want to. As I shown, look at the best attempt at building an open-source phone. It sucks majorly.
      - yjftsjthsd-h 2y ago
        Although I have thoughts on the matter, I'm not actually arguing about the quality of drivers, I'm arguing that x86 linux has had minimal problems with keeping all drivers in-tree, and if vendors want to support linux they've generally had no problem working with that. It is for some reason only mobile and embedded vendors that find it impossible to upstream drivers and that insist on shipping hacked-up vendor forks of ancient kernels. And again, firmware is a separate matter; there's plenty of cases of linux shipping blobs for the device to run, so long as the driver to talk to that device is FOSS.
fransje26 2y ago
The linux kernel is full of binary blobs. For better or worse..
- ungamedplayer 2y ago
  Do you mean the firmware repo? Because I don't remember seeing any in the source code... But ist be looking at the wrong place.
  - anthk 2y ago
    The TGZ it's full of blobs.
  - 1oooqooq 2y ago
    anti gpl bots don't know the difference. they usually can't read code either. you're correct, only firmware tree have binary blobs.
  - fransje26 2y ago
    Ah. That would depend on the definition of "Linux kernel" then, yes. You are right, in the firmware tree, not in the pure kernel itself.
1oooqooq 2y ago
good. everyone should be hostile to binary drivers. you have to not understand the first thing about kernel drivers to even consider binary drivers upstream. for starters, who provides a new binary when the api change every every new kernel version?

izacus 2y ago

Android has been booting off mainline for awhile now, so what are you going on about?

dezgeg 2y ago
Mainline kernel tends to have only basic support (if at all) for many SoCs that actually get used in phones, especially full power management support has been lacking.
- izacus 2y ago
  Right, but it doesn't seem SoC vendors are budging on that - maybe it's slowly time for Linux to figure out a better approach?
  - bayindirh 2y ago
    Stopping planned obsolescence via closed drivers is a start, no?
  - dvdkon 2y ago
    Most PC and server hardware has FLOSS drivers (with proprietary firmware), even Qualcomm is upstreaming support for the new Snapdragon Elite (maybe it's made by a different team?). I think phone SoCs are the odd ones out, which sadly doesn't mean they'll improve any time soon. Supporting an ABI for binary drivers in Linux might help phones, but it would give everyone else a chance to regress in their support, so I understand Linux kernel developers' position.
  - yjftsjthsd-h 2y ago
    Linux isn't budging - maybe it's time for SoC vendors to figure out a better approach?
dvdkon 2y ago
Android can boot from a mainline kernel, but all that gets you is that phones run a kernel forked from mainline, not forked from Google's fork.