One year of postmarketOS
One year of postmarketOS
Posted Jun 10, 2018 5:54 UTC (Sun) by amehaye (guest, #113206)In reply to: One year of postmarketOS by marcH
Parent article: One year of postmarketOS
Using an upstream kernel with open source usermode components should theoretically grant you much longer support.
Posted Jun 10, 2018 16:59 UTC (Sun)
by marcH (subscriber, #57642)
[Link] (2 responses)
Posted Jun 12, 2018 0:29 UTC (Tue)
by khim (subscriber, #9252)
[Link] (1 responses)
That's what they were doing anyway AND actually sensible thing to do from security standpoint... The only people who lose are FOSS guys, but nobody thinks about them.
Posted Jun 14, 2018 1:10 UTC (Thu)
by lsl (subscriber, #86508)
[Link]
You forgot the part where the purpose of those small kernel patches is to just export unrestricted control over some device to these huge userspace blobs, preferably in the form of a world-accesible device file (though the latter seems to have gone out of fashion lately).
Not sure about these security gains.
Posted Jun 11, 2018 18:18 UTC (Mon)
by hkario (subscriber, #94864)
[Link] (16 responses)
Something I wouldn't be able to do for a 5 times shorter amount of time without installing Firefox on a flagship Android phone.
It's absurd that we need to replace our smartphones every 2 years for them to be even remotely secure.
Posted Jun 12, 2018 2:26 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (6 responses)
Not really considering most consumers are (were?) replacing them every 2-3 years anyway because of how quickly the *hardware* is (was?) becoming obsolete anyway. Very different from PCs.
Posted Jun 12, 2018 2:35 UTC (Tue)
by marcH (subscriber, #57642)
[Link]
In some cases "obsolete" is an understatement. "Disposable" seems more accurate
https://www.xda-developers.com/nexus-5x-bootloop-fix-boot...
Posted Jun 12, 2018 12:08 UTC (Tue)
by hkario (subscriber, #94864)
[Link] (4 responses)
and, people are changing phones so often because they are on plans that give them the phones for "free" and plans laps in 1 to 2 years, not because people have to switch to new phones
and just because some of the phones die early doesn't mean that they have to die early, my Nokia N900 still lasts 4-5 days on a charge.
Posted Jun 12, 2018 14:28 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (3 responses)
Not every country works like the US (and even in the US it's been changing), example:
Even 2-3 years-old smartphone that are not falling apart look nothing like today's phones at the same price. Yes they could still be useful with updated software but newer phones appeal to a large number of people. If not then it's probably because the person doesn't even have a smartphone in the first place. The phone market is one that actually works well (at least outside the US = the country of free oligopolies) and where consumers drive.
Progress is slowing down though.
Posted Jun 12, 2018 21:42 UTC (Tue)
by Wol (subscriber, #4433)
[Link] (2 responses)
Fortunately.
I had a Galaxy Ace, which I replaced about four years ago. I didn't have much choice - with 2MB of RAM I was in the following catch 22 ...
In order to run the apps I wanted I needed to upgrade them. In order to upgrade the apps, I needed to update Google Play. In order to update Google Play I had to delete the apps to make space ...
At least with 16MB that's no longer that serious a problem, but even then, as the apps "we won't let you delete even if you never use them" grow bigger, I can see 16 MB being too small at some point :-(
That's why cheap phones die - they skimp on RAM, and then the junk crowds out everything else.
Cheers,
Posted Jun 12, 2018 23:12 UTC (Tue)
by anselm (subscriber, #2796)
[Link] (1 responses)
It's a matter of priorities. I have had a Jolla phone for the last 2,5 years or so – not cutting-edge technology, hardware-wise, even when it originally came out, but it works reasonably well, is way better for my privacy than anything with “Google” or “Apple” on it, and gets a new and improved version of Sailfish OS every few months. Jolla are planning a major-version-number upgrade of Sailfish OS for later this year and apparently even old phones like mine will still be supported by that.
I've had various Android phones before the Jolla phone and am still using an Android phone provided by my employer for work, but none of those have the same sort of commitment from the manufacturer when it comes to software updates. That's presumably because Samsung etc. would rather sell me a new phone than upgrade my old one; since Jolla is no longer in the hardware business itself, supporting the existing customer base of their software product has a higher priority to them.
Posted Jun 13, 2018 21:39 UTC (Wed)
by Wol (subscriber, #4433)
[Link]
Samsung/Apple/Motorola may well want you to buy a new phone, but until the apps break users mostly couldn't care less. High end phones are like cars from a user view-point. Some customers just want the latest and newest. Others prefer to buy a good new one and run it into the ground. That latter is what I've tried to do with my latest phone - a Motorola G5.
Cheers,
Posted Jun 12, 2018 2:42 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (8 responses)
Stable APIs are ironically a major feature of... closed-source systems (e.g. for PCs: Wintel).
The good thing with open-source is the freedom for anyone to change anything. The bad thing about open-source is... the freedom for anyone to change anything.
Posted Jun 12, 2018 12:36 UTC (Tue)
by hkario (subscriber, #94864)
[Link] (3 responses)
you mean things like
Yes, there are libraries that abandon ABI compatibility like it's a hot potato (looking at you libpng), but neither glibc nor Linux kernel is one of them
Posted Jun 12, 2018 14:07 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (2 responses)
Posted Jun 12, 2018 17:29 UTC (Tue)
by excors (subscriber, #95769)
[Link] (3 responses)
I think they're largely orthogonal issues. E.g. Android has a fairly stable API in its SDK and NDK (which are open source), so apps (usually closed source) will remain compatible with future Android versions. But its HAL interfaces (open source) often aren't stable (though I think Treble is fixing / has fixed that), so HAL implementations (closed source) might need updating or rewriting on each upgrade.
The HAL implementations also rely on syscalls to standard kernel APIs (open source), which are stable, and calls to firmware (closed source) via proprietary kernel drivers (open source though not in spirit), which probably don't have stable APIs. The proprietary kernel drivers themselves rely on unstable internal kernel APIs. It's all a mixture - there seems to be no clear correlation between openness and stability.
Conway's law is probably a bigger factor: software architecture mirrors organisational structure. API stability is very expensive to maintain, so it's only worthwhile for APIs between people who cannot make coordinated changes. Kernel developers can coordinate easily with each other, so Linux doesn't need a stable internal API; but they cannot coordinate with application developers, so they do need stable external APIs. On Android devices, there is typically one company (Samsung, Sony, Huawei, etc) who controls the entirety of the software (except for apps) and can easily coordinate between bootloader and kernel and Android platform and HAL and firmware etc - those are probably all managed in the same Gerrit/Perforce/etc server by the same developers with a single CI system - so it makes sense to avoid the expense of stable APIs even for their kernel drivers. (Even if some of that code is blobs from other vendors, that one company is responsible for integrating it all and can apply patches atomically across the entire system.)
But that makes it hard for Google to take back control of part of the device's software - that's changing the organisational structure so that it no longer matches the software architecture, and it takes a lot of effort to rearchitect it with the new boundaries. So Android devices have largely remained under control of a single company, for better or worse. (In terms of security, usually worse, since those companies care much less about security than Google does.)
Posted Jun 12, 2018 19:38 UTC (Tue)
by marcH (subscriber, #57642)
[Link] (2 responses)
I don't think anyone said that interfaces to open-source components are automatically unstable. They CAN be unstable/forked more easily and frequently than interfaces to closed-source components and lead to a fragmentation mess like the one you described. Random example of forked kernel interface(s): https://elinux.org/Android_Binder
On the other hand, when an organization (hi Conway!) delivers a closed-source component to another organization then stability expectations are obviously higher otherwise things will just stop working.
I'm everything but a HAL expert but I thought changes to HAL interfaces were carefully versioned:
Posted Jun 12, 2018 20:48 UTC (Tue)
by excors (subscriber, #95769)
[Link] (1 responses)
From what I've seen on Android, it's not unusual for a vendor to provide a package containing a firmware blob, some kernel patches, and some userspace demo code that shows how to use the API, where that API is unstable between releases and there's no attempt at backward compatibility. You have to apply all three parts simultaneously, plus update your own code that uses the API, else you'll get build failures (if you're lucky) or crashes (if you're less lucky but still quite lucky). And that's okay, since the receiving organisation controls their entire software stack and can push all the patches at once.
The difference with Windows isn't that Windows is closed source, it's that no single organisation controls all the software on a Windows machine - some comes from Microsoft, some drivers come directly from third-party vendors, others provide applications and utilities that depend deeply on Windows internals, etc. That drives the need for stable APIs, which then makes long-term support more feasible since one component can be updated without touching anything else.
> I thought changes to HAL interfaces were carefully versioned
Camera API2 (aka camera2) is designed for Camera HAL3, and that HAL is fairly carefully versioned and sensibly extensible, with good documentation of the HAL API usage rules. But as the numbers suggest, there was a HAL2 (which I think might have been shipped in about one device, before it was considered an overly-complex failed experiment and evolved into the broadly similar but incompatible HAL3), plus the original and vastly different HAL1 (which was not extensible and suffered from plenty of vendor-specific hacks, and (if I remember correctly) often changed incompatibly between Android releases). So the camera seems alright now, but it took a lot of effort to reach this point.
Camera HAL2/3 was needed because cameras were adding sophisticated features that HAL1 was completely unsuitable for, and that redesign gave an opportunity to fix versioning and extensibility based on lessons learned. Other non-camera HALs never went through a similar redesign, so they didn't have an opportunity to fix the mistakes left over from Android's early history. I assume they've probably been fixed now as part of Project Treble, but I haven't paid much attention to recent changes.
Posted Jun 12, 2018 21:11 UTC (Tue)
by marcH (subscriber, #57642)
[Link]
OK, I think I understand the misunderstanding now. I tried to clarify but you seemed to have missed it:
If a single organization controls all the software and doesn't release any particular piece, just the whole product then who cares which APIs are used behind that doors? It's irrelevant.
One year of postmarketOS
One year of postmarketOS
One year of postmarketOS
One year of postmarketOS
Hell, my desktop CPU is nearing 4 years of age and is still the 6-th fastest desktop CPU for single-threaded workloads!
One year of postmarketOS
One year of postmarketOS
https://www.apple.com/iphone-battery-and-performance/
https://lwn.net/Articles/756909/
etc.
One year of postmarketOS
One year of postmarketOS
https://www.androidcentral.com/unlocked-phones-europe
One year of postmarketOS
Wol
One year of postmarketOS
One year of postmarketOS
Wol
One year of postmarketOS
One year of postmarketOS
http://www.bit-tech.net/reviews/gaming/pc/windows-7-games...
or
https://www.hardcoregames.biz/games-incompatible-with-win...
?
One year of postmarketOS
glibc isn't even used on phones. That was the point.
One year of postmarketOS
One year of postmarketOS
https://developer.android.com/reference/android/hardware/...
One year of postmarketOS
One year of postmarketOS
> ... when an organization (hi Conway!) DELIVERS a closed-source component to another organization...
When I wrote "closed-source API" I meant: *released* (and stable) closed-source API.