41–50 of 169 posts
google/android/apple/microsft are fighting for there lives, as there is no reason for there continued existance all the important types of comunications can be hard coded into chips and operate free of any external OS, everything else is two way media, 95% of which can be handled on local networks what big tech is trying to build is something alien to human needs, false promises and enticements, faked up ideals bases…
Earlier quoted context omitted.
> sideloading It's called installing. Language matters and I see no reason to concede this point in Google's favour.
I agree with the ethos but "banning installing" wouldn't have been correct here. There should be terminology for installing from the source of your choice which doesn't carry the marginal or sinister connotations of "sideloading" though. "Freeloading" would have been a good one but... yeah
'installing from beyond the walled garden' would be a nice fit here imo
Earlier quoted context omitted.
Doesn't feel like any conspiracy.. Isn't sideloading installing through adb instead of from the system itself? (by clicking on an APK or using an app Store like Xiaomi/Googled/Huawei/Fdroid) "Side" being.. from your computer
Yes but fdroid is facing restrictions while adb is not
It's a shame phones didn't get anything similar to BIOS back in a day. Imagine if every laptop manufacturer had not a couple of incompatible sensors, but a whole unique boot system only allowing you to boot a crippled version of Windows ME.
There's a lot of UEFI in the phone ecosystem, it's not the BIOS later that's missing - it's the ACPI layer.
The problem is... in the x86 world, even the most modern systems around still ship with decades of garbage. INT 10h and VBE, every x86 system still speaks it - either directly in the card, or emulated in BIOS/UEFI compatibility layers, so even a basic "hello world" can get video output, 09h/16h gives you keyboard input, 13h gives you disk I/O, 14h a serial port.
That means that at least the initial bringup for a second-stage bootloader is incredibly easy, less than 40 lines of assembler code [1]. And when you write a tiny operating system, as long as you're content with that basic foundation of 640x480 and text output, it will run on any x86 compatible PC or server.
On anything ARM, that's outright impossible to do and that is a large part of the problem. ARM is power efficient, but it comes at a serious cost. The low level bringup will be handled by the board's ROM, similar to PC BIOS/EFI, but after control is passed to the OS it gets different - all the OS gets is the devicetree stating "here's the memory addresses and interfaces of the hardware in the system", but you still need to write drivers for each and every individual thing from the bottom up, there is no framework for even most basic hardware interactions.
[1] https://gist.github.com/MyCatShoegazer/38dc3ee7db9627ff3a20e...
Earlier quoted context omitted.
There's a lot of UEFI in the phone ecosystem, it's not the BIOS later that's missing - it's the ACPI layer.
I've never seen UEFI in any mainstream Android device. The problem is... in the x86 world, even the most modern systems around still ship with decades of garbage. INT 10h and VBE, every x86 system still speaks it - either directly in the card, or emulated in BIOS/UEFI compatibility layers, so even a basic "hello world" can get video output, 09h/16h gives you keyboard input, 13h gives you disk I/O, 14h a serial port.…
Earlier quoted context omitted.
I've never seen UEFI in any mainstream Android device. The problem is... in the x86 world, even the most modern systems around still ship with decades of garbage. INT 10h and VBE, every x86 system still speaks it - either directly in the card, or emulated in BIOS/UEFI compatibility layers, so even a basic "hello world" can get video output, 09h/16h gives you keyboard input, 13h gives you disk I/O, 14h a serial port.…
What's 09h/16h ?
[1] http://www.techhelpmanual.com/106-int_09h__keyboard_interrup...
[2] http://www.techhelpmanual.com/228-int_16h__keyboard_services...
[3] http://www.techhelpmanual.com/58-keyboard_shift_status_flags...
Earlier quoted context omitted.
> Waydroid works also pretty good. Did you test apps that need sensors and notifications? If I want to run an OpenStreetmaps apk (there's no good way to run OMS on Linux natively), do I get GPS and compass heading? Do I get turn-by-turn navigation? Even if the app is in the background?
Organic Maps has a flatpak, though oddly they don't refer to a desktop app on their website anywhere so idk how trustworthy this is. Unfortunately CoMaps doesn't seem to have desktop client builds at all yet.
But it's less full-featured than the mobile-only versions.
Earlier quoted context omitted.
Or manual install.
How about calling the other one "installing from the play store"? installing was there first.
So we can rewrite the story to something like: Google wants to prohibit app installation on Android phones. The only way to get an app would be through playstoring.
Earlier quoted context omitted.
You can also install through the Play store. Sideloading is more specific.
I can install on my Fedora laptop through dnf. I've never felt like I needed a new word to describe downloading and running an AppImage. Why would phones be different?
google has control on their android ecosystem behave, same reason why its not allowed in playstation or xbox or ios