Submitted by Sailfish OS has moved into its fourth generation with the release of Sailfish OS 4.0.1 Koli.
On a high-level Sailfish 4 includes several security and functionality updates, the long-awaited browser update, redesigned daily usage flow of key applications, as well as a rebooted developer experience. In particular we’re proud to boast full-scale OS-level Mobile Device Management (MDM) to enable easy and manageable end-to-end trusted corporate and governmental sector deployments.
There are also a bunch of other new additions, including Android 9 app support, app sandboxing, and QR code scanning, along with improved notifications, events view, contact management and more.
While this is a great software achievement, when I looked at their supported hardware database, things are a bit less rosy. There is no single line that was entirely green (i.e.: supported all features):
https://wiki.merproject.org/wiki/Adaptations/libhybris
Granted some of them are missing in the hardware, nevertheless this shows a common issue across all embedded Linux applications.
I had the Nokia N800, before smartphones were a “thing”: https://en.wikipedia.org/wiki/Nokia_N800
However as soon as N810 came into picture, Nokia stopped supporting the device. Without kernel updates, it was essentially dead.
The root cause: lack of stable driver ABIs.
I know Linus is entirely opposed to this idea. However more and more device manufacturers just ignore GPL and distribute binary blobs instead of contributing to the kernel tree. This was not a big deal, when people were using an open PC platform, and users could vote with dollars. But when you buy a phone, from say Samsung, the situation is entirely different. Without both Samsung, and Qualcomm writing open source drivers, the phone would essentially be “stuck” on a kernel release. Remember when TI stopped developing OMAP, lots of phones lost ability to update, even when the manufacturer wanted to do it.
So, it might be time to convince Linux to have some ABI in the kernel, at least for embedded devices and between minor releases.
The real root cause is proprietary drivers.
Sure having proprietary drivers is a problem.
Can we convince Qualcomm to release the camera driver? no
Can we convince Samsung to ask Qualcomm to release the driver? again, no
Can we convince Google to ask Samsung to ask Qualcomm to release it? once again, no
Can we have a stable ABI in .point releases in kernel so we at least get security fixes? maybe
I would prefer to look at this from a practical position instead of trying to be pure but keep the status quo.
I have lived with too many Linux devices that became obsolete to stay the same course.
sukru,
Have you tried putting in a word to your employer? 😉
I think google is in a strong enough position to be able to address these issues if they really wanted to. It would be great for alternative platforms, but google themselves don’t have a pressing need. If anything, the bad driver situation on ARM helps keep google’s android competitors at bay (like Lineage).
Imagine if mainline linux worked as well on ARM as it does with x86…I can just picture all of the forks we would get once the technical barriers are gone:
https://distrowatch.com/dwres.php?resource=family-tree
Why is this Google’s problem? They use the open source Linux kernel, therefore really it’s Linux’s problem.
The123king,
That’s what I was saying, Google would be in a good position to get the ball rolling, but they don’t really care about the problem so long as they’ve got the user base to keep manufacturers interested in selling new android units. Deeply coupled proprietary drivers hurt 3rd parties most of all.
I see the winking emoji there but I just wanted to say that Google probably don’t do much if there’s no money in it and I don’t see any for them in this issue. What really would get the ball rolling would be if the US government put laws in place around this and Google were forced to lock Samsung and Qualcomm out if they didn’t comply. I’m thinking about the Huawei case here. But that’s not happening either.
Alfman,
(Writing this as an ordinary Android user, specifically a Note 9, about to become obsolete in 6 months).
I think there a lot of complexity in the issue, with different stakeholders having different priorities.
Us, users, prefer to have a high quality, stable, phone with lots of features. And being able to update it for many years is nice to have. Unfortunately most users no longer care about replaceable batteries, or extensible storage.
Google, I would guess, would prefer to have a stable software ecosystem, where most devices can be supported as long as possible.
Samsung would want to sell phones, but also wants to have customer satisfaction. So they, too, might want to support phones as much as reasonably possible. But they also want to support features, like Netflix (DRM), high end graphics (closed drivers), business customers (obscure secure enclosures).
Qualcomm, wants to sell chipsets. They like having Linux do the heavy work, but will not probably spend time open sourcing their firmware or drivers, since none of their customers (Samsung, etc) request that as a feature.
They also offer Aderno as their GPU offering, but they licensed the cores from AMD/Radeon (Radeon->Aderno, learned something new today). So even if they wanted to release the code, they need to have this signed off by AMD as well, which requires paying money for something their customers did not ask.
Overall the situation is needs a lot of improvement.
At the end of the day, open source drivers, are not requested by end users, Samsung, and Google would only slightly benefit (easier updates), is not a priority for Qualcomm, and AMD would be against it for *reasons*. Even Linus does not seem to care too much. Overall us wanting to have more open source are a minority 🙂
sukru,
IMHO that’s not entirely true. A lot of users are highly inconvenienced by devices that can’t easily be repaired or upgraded. A lot of this comes down to manufacturers who are more interested in their bottom lines than product longevity. And it’s not just phones, in the home appliance market entire washing machines get thrown out because a five dollar microcontroller breaks and the manufacture charges hundreds to replace it (happened to my parent’s whirlpool, twice). Things don’t need to be this way and they didn’t used to be this way. What changed is that corporations have become very proficient at optimizing profits by controlling the upgrade cycle. We see this happening everywhere, it’s just that companies like apple are ahead of the curve. A device breaks under warranty, no problem it’s cheap for the manufacturer to fix, but if it breaks out of warrant it’s “unfixable” or not worth fixing.
“Genius Bar caught ripping customer off ON CAMERA by CBC News”
http://www.youtube.com/watch?v=o2_SZ4tfLns
A $1200 repair quote for a broken $1 cable…it’s a pattern, things like this keep happening and it twists consumers into buying new stuff they don’t want or need. Things are only becoming worse with manufacturers releasing hardware that’s decided to fail. It’s sad to see, but the truth is this increases profits so I expect to see this more.
The problem is that “voting with one’s feet” becomes much less effective when the things we get frustrated by don’t show up until long after we’ve purchased a device. Somehow if there were mandatory disclaimers at the time of sale: “this device will only be supported for 2 years” and “the average lifetime for this device is X years” “the average cost of repair is $Y”, etc, it could help consumers be better informed before making a purchase. Unfortunately even knowledgeable consumers don’t have much leverage today.
It’s kind of a catch-22, a lot of the would be users don’t exist exactly because google has a defacto monopoly on proprietary android device drivers (in much the same way microsoft did with windows). We may not blame google and microsoft directly, but they are the beneficiary of such defacto driver monopolies. A lot of users struggled with FOSS operating systems for decades over hardware incompatibilities, if you were on the scene in the 90’s and early 00’s, then you know what I’m talking about. Thankfully this has gotten much better for linux on x86 in large part because linux reached critical mass. Linux is the dominant platform for servers/high performance scientific computing/etc and hardware vendors are forced to take it seriously.
While I admit that google isn’t directly responsible for all these problems, they have the dominant mobile platform and as such mobile manufacturers would come around if google’s policy was that drivers had to be mainlined. There’s no question that they would. Yet for it’s part google isn’t doing anything about the problem, why would they? Locked drivers only helps them like it did for microsoft.
So is it a blessing or curse for Linux once Google migrates to Fuchsia in production and “Linux” marketshare in mobile nosedives from 75 % to 0 % in about 12-24 months?
Because ABI instability is probably one of the leading reasons driving this move at Google. (Plus their veiled hatred towards open source.)
Why do you think Google does not like open source? Fuchsia is open source 🙂 And I have yet to see any engineer that does not speak positively about open source at Google.
sukru,
Some companies use an open source license while not fully committing to the open community spirit of it. Is google accepting 3rd party commits or are they just providing read-only dumps? Is anyone else able to contribute anything under the same license to google? I don’t know the answers, but there are different degrees of FOSS acceptance.
Alfman,
I think it depends on the project. I am not privy to all the details, but some would be just exporting of local repos, while others would be collaboration with big partners, while many other would be community driven.
For example, take ABSL (Alphabet Base ? Library?), base C++ / Python libraries: https://github.com/abseil/
Someone probably though “we have these nice C++ libraries, let’s share them with the outer community”, and with some effort is was available. But it also seems to have external contributors:
https://github.com/abseil/abseil-cpp/graphs/contributors
Open source and companies is a very interesting discussion.
Some are just read-only dumps as you said,
Some have license based differentiation (MySQL),
Some have delayed licensing (Ghostscript, but I think they changed)
Some have all sources available, but make it difficult to build (RedHat)
Some have all sources available, easy to build, but only support their own online services (Ubuntu MAAS: https://discourse.maas.io/t/rbac-status/574)
And many others are open collaboration (like .Net now)
But it takes a lot of internal effort to keep things open. For example, it took many years for Scott Gu and Scott Hanselman to convince Microsoft to have an open .Net. (And probably the departure of a few key people).
Sodki,
There’s both problems that compliment each other in an unfortunate way, haha.
With a stable ABI, proprietary drivers can be reused.
With open source drivers, they can be modified to support a new ABI.
When they are unstable AND proprietary, that’s when we get stuck with no good options.
Bollocks. I can get proprietary drivers written for an out-of-support proprietary OS (Windows XP and/or 7) working on the latest release of said OS, running on brand new hardware.
And i can do all that purely because it has a stable driver ABI
“Buht muh ohpen saurce!” just isn’t a good enough answer
But Windows had a very good foundation.
OS/2 NT, I mean Windows NT, was designed as a microkernel with platform independent driver architecture. They even had a portable abstraction layer (HAL).
Yes, they messed up during Vista by enabling kernel mode video and sound drivers. But I think they eventually got better.
@Sukru
This is the cause of a lot of problems and friction and people either binning Linux or binning the devices running on it. Nobody (i.e Linus) wants to discuss this take it or leave it deadlock. Personally, I’m not going to spend a single second more of my life with a wet behind the ears or diehard Linux zealout because it always ends up in the passive-anger control freak “Waaah. Manufacturers” argument. Then there’s the practical issues. Bad management of the Wayland project? Nvidia (who aren’t my favourite IHV for other reasons) produce a technical fix for a problem but do they get any credit? No. It’s back to “Waaah. Manufacturers!”
Windows Driver Model is a way we know to do it right. (No I’m not getting into point release “security” issues with someone who is trying to drag me into “Waah. Manufactures!”). The documentation is excellent. The driver development kit is excellent. For some devices producing a working generic driver is as simple as compiling the sample code. That’s how you do it.
The last word on this is TI marketing department wanted to release the drivers but needed a business case to sell the idea to management. I have no idea what the current state of play is with this. While managers can keep the show on the road management like a lot of things isn’t a rational but also a political process and as prone to ignorance and fashion as much as anything else. They may also need to justify spending money for expensive staff to clean up the code and check it for third party IP and clear the rights or find replacement code so it’s not a free exercise. And yes like the “Waah. Manufacturers” squad you get decisions made out of spite or as a power trip or just because.
HollyB,
It’s certainly an area where I think linux could improve.
Honestly I’ve had a fair share of troubles from the windows camp too, both in terms of proprietary drivers that stopped working after a windows upgrade and in terms of poor accessibility for indy development. Support for 3rd party open source file systems and FUSE were sore points on windows for decades (part of me suspects it was deliberate). I used to do windows kernel development back on XP, but come vista MS was doing it’s darnedest to turn FOSS developers like me away from windows. This was back in microsoft’s “linux is a cancer” years. They broke tons of our drivers and wanted us to start paying hundreds of dollars per year for corporate code signing certificates, yet a lot of us were doing it as a hobby. For me it was the last straw and was the moment I decided to commit to linux where at least we had free reign on our machines and my dev skills would be welcomed.
Every platform has got pros and cons. It’s a good thing that everyone gets to choose which is best for themselves without any judgement 🙂
@HollyB,
TI used to have very good technical documentation for their chips. I was able to write up a Ethernet driver for a class project by looking at NE1000/NE2000 specs (and also implementations from BSD and Linux, or course).
I am sure if they had provided the same level of open specs, Linux would now have open source OMAP drivers.