3 ms·

As much as we laugh at IBM and Intel nowadays and praise the success of ARM, the x86-based IBM PC ecosystem with standardized BIOS that maintains compatibility

As much as we laugh at IBM and Intel nowadays and praise the success of ARM, the x86-based IBM PC ecosystem with standardized BIOS that maintains compatibility for decades is such a blessing, a huge breakthrough that we don't even notice anymore because we're so used to it. Before that the OS development was tightly coupled to hardware development. Booting an existing OS on a new device even with the same CPU required prior patching, configuration and re-implementation of the floppy drive driver. And it wasn't seen as odd because that's the way it was. I don't think the problem is a lack of OS enthusiasts, we probably have more of them than at the time Linux was born. The problem is they're fighting an uphill battle against a swarm of slightly different CPUs and device trees and uncooperative vendors that do anything they can to lock the device.

transpute 2y ago
> uphill battle against a swarm of slightly different CPUs and device trees Economic incentives for "differentiation", e.g. device tree with upstream Linux and uboot support for feature A, but non-upstream uboot blob enables feature A+B.
- mikrotikker 2y ago
  The Samsung s5 had a noticeable difference in camera quality between stock and AOSP.
pjmlp 2y ago
A lucky accident that IBM failed to prevent, they didn't want to have such a market, Compaq made it possible, with a clever way to prevent it legally.
dartos 2y ago
It’s even hard to find the uboot patches for clockworkpi hardware, and they open source almost everything.
AnthonyMouse 2y ago
The devices ship with a kernel that can use them. Is there anything we can do to make it easier to extract whatever device tree or other information from the compiled kernel it ships with, so it can be used with any other Linux kernel?
- transpute 2y ago
  Device tree is a file in /boot that can be decompiled. The missing artifact is open-source driver code.
  - AnthonyMouse 2y ago
    What stops someone from decompiling the closed source driver into barely legible "source code" and then grafting that onto a generic kernel so it can run on the device? It wouldn't be pretty but it would probably be a faster way to get running on the device than having to write a complete reverse-engineered driver from scratch before you can even boot, and then you have a starting point for writing an open source driver that doesn't suck as much. Could some change be made to the kernel to make that process easier? Do we need better tools to make it more practical?
    - transpute 2y ago
      > decompiling https://law.stackexchange.com/questions/101689/can-you-legally-look-at-decompiled-software-code-and-reverse-engineer-it https://law.stackexchange.com/questions/101689/can-you-legal... If you look at a decompiled code and are influenced in how you write your code by the decompiled code, this is probably a "derivative work" of the original program and not just "reverse engineering" from the way that the computer program works. Copyright for software protects the decompiled code that is written, as a literary work, and anything derived from that decompiled code is also protected.. [clean-room reverse engineering] One group examines the source to write the specs and rundown. Another to make the code again, with no people from group 1 taking to them but for the spec sheet > do we need better tools to make it more practical? Good question, perhaps others can comment. The challenge is likely economics, not tooling.
Too 2y ago
With the vendor/system split introduced by project Treble in Android, it should be easier than ever to build your own system against a rich set of hardware abstractions, that work on a wide range of devices. Assuming you are ok with still running a very thick slice of the stack as proprietary vendor image.
- zozbot234 2y ago
  Yes you can run a GSI (and project Droidian does that) but then you're dependent on a downstream kernel and Android-ish early boot environment, that will likely lead to pointless incompatibilities compared to a fully-upstreamed approach.
  - pjmlp 2y ago
    Upstream doesn't care about clang and Rust as much as Google does, so that isn't ever going to happen as much as people vouch for it.
    - zozbot234 2y ago
      The biggest hurdle to getting AOSP-kernel features into the upstream kernel is not clang or Rust, it's cleaning up hacked-together kernel code in a way that makes it long-term acceptable to upstream maintainers. (And getting rid of userspace blobs for things like graphics.) Always has been for as long as AOSP was a thing.
xattt 2y ago
One issue between then and now is that there’s a hell of a lot more people now that are aware what transpired then and what steps to take to prevent or sabotage a burgeoning clone market.
- smegger001 2y ago
  I wonder why google hasn't mandated some open standard like BIOS for all new arm based phones/tablet/smart-device that have the playstore and google services. I can't see it doing anything harmful to them and would make the whole ecosystem easier to develop for and may even make spread and make arm based laptops/desktop/servers more standardized which would be useful for data centers and such. it would probably help with the whole shitty driver situation on arm platforms. I honestly don't see a downside for anyone if everyone is having to do it which mandating it for android would essentially insure.
mozball 2y ago
It is very puzzling. We have a plethora of brands from chinese, korean, european and american companies to kickstarter-funded projects to reskinned odm designs in developing markets,- all vying and clawing at each other to stand out in an oversaturated market with more cameras, more pixels, more features like AI, and filters and what-not. Yet not one of these companies think to release a phone that proffers to give the best rooting experience or Lineage OS compatibility - or better yet, comes with LineageOS out-of-the-box.
- matejdro 2y ago
  I think OnePlus one comes the closest. It came with Cyanogen OS out of the box (a version of Cyanogen od, predecessor to the LineageOS)
- lodovic 2y ago
  I think one of the main reasons is that many apps such as banking or drm-protected apps, which are usually only offered through the official app stores, will refuse to work on a rooted or custom imaged phone. You'd have to go through youtube tutorials and have to download the software through third-party mirrors, and that's not a feature that will sell phones.
  - fensgrim 2y ago
    Another reason is that giving users the option to root and unlock is possible only after ditching whatever agremeent is in place with Google. So, no Play support for this vendor at all means no sales to normal markets. Going deeper in conspiracy theories, Google would drop Qualcomm/Mediatek from the ecosystem if they'll ever allow a single SoC licensee to do such phone.
- ossyrial 2y ago
  I believe Fairphone used to ship models with LineageOS out of the box—their new models optionally ship /e/OS, which I'm not familiair with but seems similar on the surface.
- raydev 2y ago
rldjbpin 2y ago
well, it was fun while it lasted at least. now with apple and arm pushing for an alternative platform via emulation at first, we are heading for a fragmented mess yet again.

transpute 2y ago

> uphill battle against a swarm of slightly different CPUs and device trees Economic incentives for "differentiation", e.g. device tree with upstream Linux and uboot support for feature A, but non-upstream uboot blob enables feature A+B.

mikrotikker 2y ago
The Samsung s5 had a noticeable difference in camera quality between stock and AOSP.

pjmlp 2y ago

A lucky accident that IBM failed to prevent, they didn't want to have such a market, Compaq made it possible, with a clever way to prevent it legally.

dartos 2y ago

It’s even hard to find the uboot patches for clockworkpi hardware, and they open source almost everything.

AnthonyMouse 2y ago

The devices ship with a kernel that can use them. Is there anything we can do to make it easier to extract whatever device tree or other information from the compiled kernel it ships with, so it can be used with any other Linux kernel?

transpute 2y ago
Device tree is a file in /boot that can be decompiled. The missing artifact is open-source driver code.
- AnthonyMouse 2y ago
  What stops someone from decompiling the closed source driver into barely legible "source code" and then grafting that onto a generic kernel so it can run on the device? It wouldn't be pretty but it would probably be a faster way to get running on the device than having to write a complete reverse-engineered driver from scratch before you can even boot, and then you have a starting point for writing an open source driver that doesn't suck as much. Could some change be made to the kernel to make that process easier? Do we need better tools to make it more practical?
  - transpute 2y ago
    > decompiling https://law.stackexchange.com/questions/101689/can-you-legally-look-at-decompiled-software-code-and-reverse-engineer-it https://law.stackexchange.com/questions/101689/can-you-legal... If you look at a decompiled code and are influenced in how you write your code by the decompiled code, this is probably a "derivative work" of the original program and not just "reverse engineering" from the way that the computer program works. Copyright for software protects the decompiled code that is written, as a literary work, and anything derived from that decompiled code is also protected.. [clean-room reverse engineering] One group examines the source to write the specs and rundown. Another to make the code again, with no people from group 1 taking to them but for the spec sheet > do we need better tools to make it more practical? Good question, perhaps others can comment. The challenge is likely economics, not tooling.

Too 2y ago

With the vendor/system split introduced by project Treble in Android, it should be easier than ever to build your own system against a rich set of hardware abstractions, that work on a wide range of devices. Assuming you are ok with still running a very thick slice of the stack as proprietary vendor image.

zozbot234 2y ago
Yes you can run a GSI (and project Droidian does that) but then you're dependent on a downstream kernel and Android-ish early boot environment, that will likely lead to pointless incompatibilities compared to a fully-upstreamed approach.
- pjmlp 2y ago
  Upstream doesn't care about clang and Rust as much as Google does, so that isn't ever going to happen as much as people vouch for it.
  - zozbot234 2y ago
    The biggest hurdle to getting AOSP-kernel features into the upstream kernel is not clang or Rust, it's cleaning up hacked-together kernel code in a way that makes it long-term acceptable to upstream maintainers. (And getting rid of userspace blobs for things like graphics.) Always has been for as long as AOSP was a thing.

xattt 2y ago

One issue between then and now is that there’s a hell of a lot more people now that are aware what transpired then and what steps to take to prevent or sabotage a burgeoning clone market.

smegger001 2y ago
I wonder why google hasn't mandated some open standard like BIOS for all new arm based phones/tablet/smart-device that have the playstore and google services. I can't see it doing anything harmful to them and would make the whole ecosystem easier to develop for and may even make spread and make arm based laptops/desktop/servers more standardized which would be useful for data centers and such. it would probably help with the whole shitty driver situation on arm platforms. I honestly don't see a downside for anyone if everyone is having to do it which mandating it for android would essentially insure.

mozball 2y ago

It is very puzzling. We have a plethora of brands from chinese, korean, european and american companies to kickstarter-funded projects to reskinned odm designs in developing markets,- all vying and clawing at each other to stand out in an oversaturated market with more cameras, more pixels, more features like AI, and filters and what-not. Yet not one of these companies think to release a phone that proffers to give the best rooting experience or Lineage OS compatibility - or better yet, comes with LineageOS out-of-the-box.

matejdro 2y ago
I think OnePlus one comes the closest. It came with Cyanogen OS out of the box (a version of Cyanogen od, predecessor to the LineageOS)
lodovic 2y ago
I think one of the main reasons is that many apps such as banking or drm-protected apps, which are usually only offered through the official app stores, will refuse to work on a rooted or custom imaged phone. You'd have to go through youtube tutorials and have to download the software through third-party mirrors, and that's not a feature that will sell phones.
- fensgrim 2y ago
  Another reason is that giving users the option to root and unlock is possible only after ditching whatever agremeent is in place with Google. So, no Play support for this vendor at all means no sales to normal markets. Going deeper in conspiracy theories, Google would drop Qualcomm/Mediatek from the ecosystem if they'll ever allow a single SoC licensee to do such phone.
ossyrial 2y ago
I believe Fairphone used to ship models with LineageOS out of the box—their new models optionally ship /e/OS, which I'm not familiair with but seems similar on the surface.
raydev 2y ago

rldjbpin 2y ago

well, it was fun while it lasted at least. now with apple and arm pushing for an alternative platform via emulation at first, we are heading for a fragmented mess yet again.