Hacker News Reader

Comment by alexey-salmin | Hacker News Reader

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.

View on HN

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.

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.

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)

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.

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.

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.

> 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?

I reckon at least as profitable (probably more) as every other forgettable model in the currently oversaturated market all trying to target the same segment in the race to the bottom. We don't care about cameras or games or ai. We are happy with last years specs (or older). The after-sales-support, maintenance, updates can be offloaded to the community. Sales will probably be online and not in brick-and-mortar stores since it would be difficult to market to regular people. So Marketing budget can be minimal. Just do a couple of talks at foss events. It might not be the kind of phone that gets Marques BrownLee excited but the FOSS community (which still has clout and influence among tech-elites) will be more than happy to do the evangelism for a phone that is 100% open-source and doesn't spy on you. Since sales are online it could be a kick-starter or pre-orders in batches. So 100% cash upfront before production. It could even be the halo phone for the next phone unicorn startup (ala OnePlus).

So, basically the Librem 5?

Yeah. Basically a Librem 5 with the useability of Android.

Nothing stops you from running Android on a Librem 5 if that's what you desire.

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?

Device tree is a file in /boot that can be decompiled. The missing artifact is open-source driver code.

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?

> 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.

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.

Isn't that precisely what the GPL is for? Are all these vendors violating the license?

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.

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.

> 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.

The Samsung s5 had a noticeable difference in camera quality between stock and AOSP.

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.

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.

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.

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.

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.

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.

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

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.

Reply on news.ycombinator.com