5 ms·

You can't tell people who are doing the work what to work on.. but considering there is a mountain of linux development for people with the expertise to be don

You can't tell people who are doing the work what to work on.. but considering there is a mountain of linux development for people with the expertise to be done for more open platforms. This work pretty much only helps one of the richest companies and Apple shows very little inclination to help by providing documentation or support (they let an alternative OS boot seems to be the extent of it).

colonwqbang 4y ago
Maybe it's the reverse engineering aspect that makes it interesting. Those of us in that line of work already spend our time at work turning docs into device drivers. It would be like working at Apple without getting paid.
jorvi 4y ago
And yet Linus used a MacBook Air as his daily driver for many many years. The XPS series might have caught up for a while, but until they flip over to ARM, Apple laptops simply blow anything else out of the water. What’s wrong with trying to run Linux on that?
- lmm 4y ago
  It sets the wrong incentives. Companies that are more developer-friendly, publishing specs and so on, should be rewarded for it.
  - _ph_ 4y ago
    In principle I would agree, but the world isn't black and white. First of all, in the PC world, there are few machines which are completely and well documented. That Linux runs on so much PC hardware is more due to the popularity than great documentation. NVidia just recently finally open sourced their drivers. Could Apple improve the documentation a lot? For sure! Bu on the other side, the ARM Macs are a very nice platform, so I can understand the desire to use it. There is no competition at the moment, so it would be wrong too, to not support Linux there.
- mnd999 4y ago
  I don’t like your implication that ARM is the only way to do this. The Apple chips are fast and low power because they are good designs built on a very modern fabrication process. It’s perfectly possible to build such chips with other designs and instruction sets, for example x86_64 or risc-v, in the same way it’s pretty common to build cheaper slower ARM processors. Plenty of folks at Intel and AMD are doing that right now.
  - cylon13 4y ago
    There are fundamental issues with x86 that make it impossible to match the efficiency of ARM. Variable length instruction coding for instance, which means a surprising amount of power is dedicated to circuitry which is just to find where the instruction boundaries are for speculative execution. Made sense in the 80s when memory was scarce and execution was straightforward, but now it’s a barrier to efficiency that’s baked right into the ISA.
    - POPOSYS 4y ago
      Thank you very much for this interesting comment! It would be great if you would like to provide an URL with a detailed analysis of this issue.
    - dontlaugh 4y ago
      And sadly this partly applies to RISC-V too. It only achieves competitive density with the (optional) instruction compression, which makes instructions vary in length. Not as big of a problem as on x86, but still a fundamental limitation.
      - snvzz 4y ago
        >sadly this partly applies to RISC-V too. Not in any way that has any relevance. >Not as big of a problem as on x86, but still a fundamental limitation. Huge understatement. Instructions being any size 1-16 (x86) vs being either 16bit or 32bit long (RISC-V). As with everything else in RISC-V, the architects did the weighting, and found that the advantage in code size overwhelms the (negligible by design) added decoding cost, for anything but the tiniest of implementations (no on-die cache + no builtin ROM). As it turns out, it would be difficult to even find a use for such a core, but in any event it is still possible to make one such very specialized chip, and simply not use the C extension. Such a use would be deeply embedded, and the vendor would be in control of the full stack so there would be no concerns of compatibility with e.g. mainstream Linux distributions. They would still get ecosystem benefits; they'd be able to use the open source toolchains, as they support even naked RV32E with no extensions.

colonwqbang 4y ago

Maybe it's the reverse engineering aspect that makes it interesting. Those of us in that line of work already spend our time at work turning docs into device drivers. It would be like working at Apple without getting paid.

jorvi 4y ago

And yet Linus used a MacBook Air as his daily driver for many many years. The XPS series might have caught up for a while, but until they flip over to ARM, Apple laptops simply blow anything else out of the water. What’s wrong with trying to run Linux on that?

lmm 4y ago
It sets the wrong incentives. Companies that are more developer-friendly, publishing specs and so on, should be rewarded for it.
- _ph_ 4y ago
  In principle I would agree, but the world isn't black and white. First of all, in the PC world, there are few machines which are completely and well documented. That Linux runs on so much PC hardware is more due to the popularity than great documentation. NVidia just recently finally open sourced their drivers. Could Apple improve the documentation a lot? For sure! Bu on the other side, the ARM Macs are a very nice platform, so I can understand the desire to use it. There is no competition at the moment, so it would be wrong too, to not support Linux there.
mnd999 4y ago
I don’t like your implication that ARM is the only way to do this. The Apple chips are fast and low power because they are good designs built on a very modern fabrication process. It’s perfectly possible to build such chips with other designs and instruction sets, for example x86_64 or risc-v, in the same way it’s pretty common to build cheaper slower ARM processors. Plenty of folks at Intel and AMD are doing that right now.
- cylon13 4y ago
  There are fundamental issues with x86 that make it impossible to match the efficiency of ARM. Variable length instruction coding for instance, which means a surprising amount of power is dedicated to circuitry which is just to find where the instruction boundaries are for speculative execution. Made sense in the 80s when memory was scarce and execution was straightforward, but now it’s a barrier to efficiency that’s baked right into the ISA.
  - POPOSYS 4y ago
    Thank you very much for this interesting comment! It would be great if you would like to provide an URL with a detailed analysis of this issue.
  - dontlaugh 4y ago
    And sadly this partly applies to RISC-V too. It only achieves competitive density with the (optional) instruction compression, which makes instructions vary in length. Not as big of a problem as on x86, but still a fundamental limitation.
    - snvzz 4y ago
      >sadly this partly applies to RISC-V too. Not in any way that has any relevance. >Not as big of a problem as on x86, but still a fundamental limitation. Huge understatement. Instructions being any size 1-16 (x86) vs being either 16bit or 32bit long (RISC-V). As with everything else in RISC-V, the architects did the weighting, and found that the advantage in code size overwhelms the (negligible by design) added decoding cost, for anything but the tiniest of implementations (no on-die cache + no builtin ROM). As it turns out, it would be difficult to even find a use for such a core, but in any event it is still possible to make one such very specialized chip, and simply not use the C extension. Such a use would be deeply embedded, and the vendor would be in control of the full stack so there would be no concerns of compatibility with e.g. mainstream Linux distributions. They would still get ecosystem benefits; they'd be able to use the open source toolchains, as they support even naked RV32E with no extensions.