71–80 of 467 posts
Earlier quoted context omitted.
> I'm not knowledgeable enough -- what would it take to escape the Apple/Google duopoly? At this point? Reliable emulation that can run 99% of Android apps, to provide a bridge until the platform is interesting enough for people to develop for it "natively". I think the easiest way to do that would be to run Android in a VM.
You can go the waydroid style with namespacing, or native containers if using the linux kernel. No need to do a full vm
https://tbot.substack.com/p/grapheneos-new-oem-partnership > GrapheneOS has officially confirmed a major new hardware partnership—one that marks the end of its long-standing Pixel exclusivity. According to the team, work with a major Android OEM began in June and is now moving toward the development of a next-generation smartphone built to meet GrapheneOS’ strict privacy and security standards.
Why was it that in the early PC days, IBM was unable to keep a lid on 'IBM compatible', allowing for the PC interoperability explosion, yet today, almost every phone has closed drivers, closed and locked bootloaders, and almost complete corporate control over our devices? Why are there not yet a plethora of phones on the market that allow anyone to install their OS of choice?
Earlier quoted context omitted.
> I'm not knowledgeable enough -- what would it take to escape the Apple/Google duopoly? At this point? Reliable emulation that can run 99% of Android apps, to provide a bridge until the platform is interesting enough for people to develop for it "natively". I think the easiest way to do that would be to run Android in a VM.
You can go the waydroid style with namespacing, or native containers if using the linux kernel. No need to do a full vm
If you expect to be "essentially android, but a little different", containers make sense. If you want to build an entirely different mobile OS, but provide Android compatibility, I think a VM is much more likely to give you the flexibility to not defer to Android design decisions.
Earlier quoted context omitted.
I don't believe that's the true problem. Booting operating system is not a problem. There's no standardized hardware abstraction layer in PC either, every OS brings their own set of drivers. My guess is that modern hardware is too complicated for one hacker to write reliable drivers. That wasn't the case back in the 90-s, when Linux matured. So we are at mercy of hardware manufacturers and they happened to not be int…
In the ARM world, there isn't even a standard way to boot, and there are no standard hardware interfaces - except maybe the interrupt controller, since it's part of the CPU and only ARM designs the CPUs. On any PC, you can still use BIOS/UEFI services to get a basic framebuffer and keyboard input. You cannot do that on embedded ARM devices - you need to get several layers into the graphics stack to have a framebuffer…
Having basic framebuffer in BIOS/UEFI is neat for toy OSes, but not very relevant for something practical. You gotta need proper driver for GPU. And if you're just starting, UART console is actually more preferable way to interact with board, IMO.
Earlier quoted context omitted.
That comparison shows "Deblobbed? Yes" for GrapheneOS. That implies they've replaced (most of) the blobs for wifi, bluetooth, 5g chips etc. Is that actually true? It's such a big deal, and I see little to no work being done on this front. Anyone have any idea what GrapheneOS actually deblobbed?
They can because they essentially support Google chipsets, which are not blobby like MediaTek or Qualcomm because Google for all its faults is still relatively open (except their recent change in release schedules is why the Pixel 10 series still only has experimental GrapheneOS support).
Nobody, including Graphene, is getting away with building their own modem firmware. The reduced blobs are on userspace and some HAL components.
Earlier quoted context omitted.
You might also be interested in Jolla Phone https://news.ycombinator.com/item?id=46162368
If you're stateside and want a shipping Linux phone today, [FuriLabs]( http://furilabs.com ) is another option. Graphene is in a class of its own compared to both of these though and there's frankly no reason to bother unless you're trying to improve those ecosystems.
In case others, like me, weren't aware.
Earlier quoted context omitted.
Most ARM devices don't have UEFI or a standardized hardware abstraction layer as x86/x64 does, a prerequisite for having a choice of OSes.
I don't believe that's the true problem. Booting operating system is not a problem. There's no standardized hardware abstraction layer in PC either, every OS brings their own set of drivers. My guess is that modern hardware is too complicated for one hacker to write reliable drivers. That wasn't the case back in the 90-s, when Linux matured. So we are at mercy of hardware manufacturers and they happened to not be int…
Modern hardware has turned our operating systems into isolated "user OS" nodes in the schematics, completely sandboxed away from the real action. Our operating systems don't really operate systems anymore.
https://tbot.substack.com/p/grapheneos-new-oem-partnership > GrapheneOS has officially confirmed a major new hardware partnership—one that marks the end of its long-standing Pixel exclusivity. According to the team, work with a major Android OEM began in June and is now moving toward the development of a next-generation smartphone built to meet GrapheneOS’ strict privacy and security standards.
Why was it that in the early PC days, IBM was unable to keep a lid on 'IBM compatible', allowing for the PC interoperability explosion, yet today, almost every phone has closed drivers, closed and locked bootloaders, and almost complete corporate control over our devices? Why are there not yet a plethora of phones on the market that allow anyone to install their OS of choice?
These days things are way slower and the are no exponential growth in users. Plus fast cellular networks made the speed of local hardware much less relevant. So the software became way more important and so its control.