alexey-salmin
12 hours ago
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.
pjmlp
11 hours 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.
AnthonyMouse
11 hours 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?
zozbot234
10 hours ago
You can use the downstream kernel directly via Droidian (a Mobian-derived GSI image). But otherwise the downstream kernels and device trees tend to be useless from an upstream development perspective - too hacked together and not maintainable in practice. Your proposed approach can be used however to extract existing firmware blobs (that will run unchanged no matter what the booting OS), and Mobian is pursuing that approach.
transpute
11 hours ago
Device tree is a file in /boot that can be decompiled. The missing artifact is open-source driver code.
AnthonyMouse
11 hours 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
10 hours ago
> decompiling
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.
gomerspiles
10 hours ago
This is GPL code so decompiling isn't necessary or the problem.
Accepting over the wall low quality code and having a submitter for it who may know nothing about it makes it difficult to work any of this low quality code into the mainline kernel via its resource starved processes.
atq2119
10 hours ago
Isn't that precisely what the GPL is for? Are all these vendors violating the license?
transpute
10 hours ago
Possible, but sometimes vendor code isn't acceptable for upstream, even when public. Some vendors ship binaries with EULA restrictions to customers, who choose not to exercise their GPL rights.
A modern approach to working around the GPL is to move functions from open drivers to closed firmware.
mozball
8 hours 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.
raydev
44 minutes ago
> 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.
How profitable do you think this would be?
lodovic
7 hours 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
2 hours 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
7 hours 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.
matejdro
7 hours 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)
transpute
12 hours 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
9 hours ago
The Samsung s5 had a noticeable difference in camera quality between stock and AOSP.
xattt
10 hours 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
6 hours 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.
Too
11 hours 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
10 hours 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
9 hours 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
9 hours 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.
dartos
11 hours ago
It’s even hard to find the uboot patches for clockworkpi hardware, and they open source almost everything.