5 ms·

I mean, that seems to be the result, yes? The intent is to compel device manufacturers to release the source of their drivers, but at this point, I think we hav

by cwyers 6y ago

I mean, that seems to be the result, yes? The intent is to compel device manufacturers to release the source of their drivers, but at this point, I think we have to admit that's not a great description of what's happening in the mobile space.

DaiPlusPlus 6y ago
> The intent is to compel device manufacturers to release the source of their drivers I doubt that was the "intent"... perhaps a contributory argument in favour of a non-stable ABI, but I understand the reasons are far more pragmatic: maintaining a stable kernel ABI is a lot of work which could have strangled Linux in its early years.
- dathinab 6y ago
  > have strangled Linux in its early years. And likely would still do so toady. I mean we are speaking about the kernel internal API (not the syscall API, which is stable). Even systems which pride themself for internal kernel API stability do change the API every view years, while often having much less internal (feature/platform support) changes then Linux. Furthermore in android Linux LTS versions are often used which do support a long term stable ABI, potentially longer then certain other more niche systems priding themself with long support. The problem is when a device is sold the kernel (minus back ported security fixes) is often already multiple years old so even if you use a kernel with 7 years longtime support you still have a good chance to run into problem. And supporting any kernel internal API for more then that time is unrealistic.
  - cwyers 6y ago
    Why? WDDM drivers written for Windows Vista can still work on Windows 10. And Windows is not a "niche" system.
    - dathinab 6y ago
      Because Windows is a (very broken) Micro-Kernel system which did very little changes to it's kernel (as far as I know) in the last many years, in difference to that Linux is a macro kernel with constant changes and improvements to it. Are the improvements worth the cost? I don't know. (For server applications likely yes, but for desktop likely not). What I do know is that there are clear benefits of micro kernel architectures, even if they are kinda messed up (for a micro kernel) hybrids like windows has. Lastly the way the kernel API's are designed can also make a major difference independent of the rest. Honestly the Linux kernel API feels much more raw then the windows API, but I only have every written a single dummy driver for each platform and that was quite a while ago.
      - DaiPlusPlus 6y ago
        Windows NT is not a microkernel - Windows CE was, however. NT has been shifting towards running more driver-code in user-space, as has macOS as well, especially with UMDF (especially for USB devices) and for graphics drivers, which are historically the #1 cause of BSODs - however just because the kernel passes control to user-space for the bulk of the driver's number-crunching doesn't mean that architecturally the kernel is still responsible for huge swathes of the computer's functionality. With a true micro-kernel there isn't any third-party code in the kernel space - not even a stub.
        DaiPlusPlus 6y ago
        > however just because the kernel passes control to user-space for the bulk of the driver's number-crunching doesn't mean that architecturally the kernel is still responsible for huge swathes of the computer's functionality I typo'd that - it should be > however just because the kernel passes control to user-space for the bulk of the driver's number-crunching doesn't mean that architecturally the kernel isn't still responsible for huge swathes of the computer's functionality
      - kevingadd 6y ago
        This comment feels like it was written by someone who hasn't done much Windows development (which is fine!). The kernel changes a lot over time, introducing entirely new driver models (see https://en.wikipedia.org/wiki/Windows_Display_Driver_Model#History https://en.wikipedia.org/wiki/Windows_Display_Driver_Model#H... for an example), OS-wide features, etc. Things like thread scheduling or timer granularity can and will change (see https://randomascii.wordpress.com/2020/10/04/windows-timer-resolution-the-great-rule-change/ https://randomascii.wordpress.com/2020/10/04/windows-timer-r... for a recent example) Let's not forget about massive stuff like the whole Windows Subsystem For Linux, which was literally an entire separate process type alongside Win32 processes, with its own set of syscalls etc. Added and then deprecated (and probably eventually removed entirely) over the span of years. Maintaining a stable kernel ABI is no doubt a big investment, but it's possible and doesn't have much to do with whether your kernel is a microkernel or not. Lots of Windows drivers these days are user-space which helps maintain compatibility and stability.
- namibj 6y ago
  Granted, even ABI-stability to some extend is difficult. I remember that I have some cheap wifi adapters that aren't supported by in-tree code, but came with a CD (small diameter) that had the SDK on it. This was unfortunately for the old timespec or w/e the exact struct is called, and I could have ported it to use the new API, especially considering that there are in-tree and/or up-to-date versions for closely related chips, but honestly the lack of easily-accessible tooling for that discouraged me from doing so. The reason I got them initially is that, some about 2.5y back, they were sold on Aliexpress for 3.50 EUR (~5$) and could do dual-band with at least 40 MHz channels, iirc maybe even 80 MHz on 5GHz. They are just tiny USB-A dongles with a USB 2.0 HighSpeed host interface, but they could do station/softAP/station+softAP, obviously restricted to a single channel. There's a related issue of a rtl8812-au or rtl8821-au (or compatible) stick (Edimax EW-7822UAC) I got before that, with a USB 3.0 SuperSpeed host interface, intended for trying out a remote radio head point-to-point configuration using polarization-duplex with a recycled satellite-TV dish on each end, as it could do AP-mode on 80 MHz wide channels in the 5 GHz band on Linux, with a 867 Mbit/s link rate (assuming full polarization multiplexing based on the stick's 2x2 MIMO and a circular polarizing feed antenna).
- UncleMeat 6y ago
  There are many different reasons that all contribute. But Linux clearly can keep some form of stability, given their dedication to never breaking userspace, if they really want to.
admax88q 6y ago
I dunno, seems a stretch to blame the kernel for e-waste when theres tons of other well funded parties creating the waste in the first place with zero intention of supporting the device beyond a year, let alone enabling anyone else to support it. The android ecosystem is already better than the completely proprietary feature phones of before.
AnthonyMouse 6y ago
> The intent is to compel device manufacturers to release the source of their drivers, but at this point, I think we have to admit that's not a great description of what's happening in the mobile space. But it's still the thing we want, for that and a lot of other reasons. So presumably what we need to do is find a way to exert more leverage, so that we actually get what we want, instead of folding and letting the bad thing take root forever.

by cwyers 6y ago

DaiPlusPlus 6y ago

> The intent is to compel device manufacturers to release the source of their drivers I doubt that was the "intent"... perhaps a contributory argument in favour of a non-stable ABI, but I understand the reasons are far more pragmatic: maintaining a stable kernel ABI is a lot of work which could have strangled Linux in its early years.

dathinab 6y ago
> have strangled Linux in its early years. And likely would still do so toady. I mean we are speaking about the kernel internal API (not the syscall API, which is stable). Even systems which pride themself for internal kernel API stability do change the API every view years, while often having much less internal (feature/platform support) changes then Linux. Furthermore in android Linux LTS versions are often used which do support a long term stable ABI, potentially longer then certain other more niche systems priding themself with long support. The problem is when a device is sold the kernel (minus back ported security fixes) is often already multiple years old so even if you use a kernel with 7 years longtime support you still have a good chance to run into problem. And supporting any kernel internal API for more then that time is unrealistic.
- cwyers 6y ago
  Why? WDDM drivers written for Windows Vista can still work on Windows 10. And Windows is not a "niche" system.
  - dathinab 6y ago
    Because Windows is a (very broken) Micro-Kernel system which did very little changes to it's kernel (as far as I know) in the last many years, in difference to that Linux is a macro kernel with constant changes and improvements to it. Are the improvements worth the cost? I don't know. (For server applications likely yes, but for desktop likely not). What I do know is that there are clear benefits of micro kernel architectures, even if they are kinda messed up (for a micro kernel) hybrids like windows has. Lastly the way the kernel API's are designed can also make a major difference independent of the rest. Honestly the Linux kernel API feels much more raw then the windows API, but I only have every written a single dummy driver for each platform and that was quite a while ago.
    - DaiPlusPlus 6y ago
      Windows NT is not a microkernel - Windows CE was, however. NT has been shifting towards running more driver-code in user-space, as has macOS as well, especially with UMDF (especially for USB devices) and for graphics drivers, which are historically the #1 cause of BSODs - however just because the kernel passes control to user-space for the bulk of the driver's number-crunching doesn't mean that architecturally the kernel is still responsible for huge swathes of the computer's functionality. With a true micro-kernel there isn't any third-party code in the kernel space - not even a stub.
      - DaiPlusPlus 6y ago
        > however just because the kernel passes control to user-space for the bulk of the driver's number-crunching doesn't mean that architecturally the kernel is still responsible for huge swathes of the computer's functionality I typo'd that - it should be > however just because the kernel passes control to user-space for the bulk of the driver's number-crunching doesn't mean that architecturally the kernel isn't still responsible for huge swathes of the computer's functionality
    - kevingadd 6y ago
      This comment feels like it was written by someone who hasn't done much Windows development (which is fine!). The kernel changes a lot over time, introducing entirely new driver models (see https://en.wikipedia.org/wiki/Windows_Display_Driver_Model#History https://en.wikipedia.org/wiki/Windows_Display_Driver_Model#H... for an example), OS-wide features, etc. Things like thread scheduling or timer granularity can and will change (see https://randomascii.wordpress.com/2020/10/04/windows-timer-resolution-the-great-rule-change/ https://randomascii.wordpress.com/2020/10/04/windows-timer-r... for a recent example) Let's not forget about massive stuff like the whole Windows Subsystem For Linux, which was literally an entire separate process type alongside Win32 processes, with its own set of syscalls etc. Added and then deprecated (and probably eventually removed entirely) over the span of years. Maintaining a stable kernel ABI is no doubt a big investment, but it's possible and doesn't have much to do with whether your kernel is a microkernel or not. Lots of Windows drivers these days are user-space which helps maintain compatibility and stability.
namibj 6y ago
Granted, even ABI-stability to some extend is difficult. I remember that I have some cheap wifi adapters that aren't supported by in-tree code, but came with a CD (small diameter) that had the SDK on it. This was unfortunately for the old timespec or w/e the exact struct is called, and I could have ported it to use the new API, especially considering that there are in-tree and/or up-to-date versions for closely related chips, but honestly the lack of easily-accessible tooling for that discouraged me from doing so. The reason I got them initially is that, some about 2.5y back, they were sold on Aliexpress for 3.50 EUR (~5$) and could do dual-band with at least 40 MHz channels, iirc maybe even 80 MHz on 5GHz. They are just tiny USB-A dongles with a USB 2.0 HighSpeed host interface, but they could do station/softAP/station+softAP, obviously restricted to a single channel. There's a related issue of a rtl8812-au or rtl8821-au (or compatible) stick (Edimax EW-7822UAC) I got before that, with a USB 3.0 SuperSpeed host interface, intended for trying out a remote radio head point-to-point configuration using polarization-duplex with a recycled satellite-TV dish on each end, as it could do AP-mode on 80 MHz wide channels in the 5 GHz band on Linux, with a 867 Mbit/s link rate (assuming full polarization multiplexing based on the stick's 2x2 MIMO and a circular polarizing feed antenna).
UncleMeat 6y ago
There are many different reasons that all contribute. But Linux clearly can keep some form of stability, given their dedication to never breaking userspace, if they really want to.

admax88q 6y ago

I dunno, seems a stretch to blame the kernel for e-waste when theres tons of other well funded parties creating the waste in the first place with zero intention of supporting the device beyond a year, let alone enabling anyone else to support it. The android ecosystem is already better than the completely proprietary feature phones of before.

AnthonyMouse 6y ago

> The intent is to compel device manufacturers to release the source of their drivers, but at this point, I think we have to admit that's not a great description of what's happening in the mobile space. But it's still the thing we want, for that and a lot of other reasons. So presumably what we need to do is find a way to exert more leverage, so that we actually get what we want, instead of folding and letting the bad thing take root forever.