However, the base it runs on - Mer - is open source, and there is an alternative open UI (Glacier UI). Unfortunately this further limits the applications that can run on it.
IMHO, with Russians being paranoic about western "spying" and Russians committing their code to upstream, it's likely that there will be something to see in a couple of years.
Willingness and ability are different things. Samsung never tried to push Tizen on mobile phones.
Samsung put itself in a position where the company simply cannot walk away from Google, at least in the mobile space (Tizen is actually pretty "mainstream" in smart TVs and wearables). Market shares are pretty much set at this point, and no alternative mobile OS based on linux has a chance to become mainstream, no matter the size of the company backing it. That doesn't stop a small company like Jolla from delivering viable products though, since they don't need to keep Google happy.
By the way, the phone runs a real Linux distro. There's Wayland, OpenSSH, bash, systemd (ugh...), RPM's, and a ton of good old commandline software like htop, tmux, python, - heck, even gcc if you feel like rebuilding the kernel :) Native apps are built with Qt & QML. There's very little NIH.
There's also support for Android apps. Many of the apps from F-Droid run OK, and even lots of commercial stuff.
Oh, and the phone is pretty fantastic for all the normal everyday things, like being an actual phone.
It's somewhere on my TODO list :) I make a "f*ck you Krzysztof" app for every new phone OS I get: there's one for J2ME, Android, now gotta learn myself some QML... Krzysztof is not very amused.
It looks to me that all Sailfish devices that have ever been available are not compatible with 3G/4G US carriers (but some are compatible with 2G).
It seems that if anyone in the US wants to seriously use Sailfish, they need to flash a community port of Sailfish to a US-sold Android device. Not a huge deal - it looks like a few manufacturers are actively supporting this ports (e.g. for the Fairphone 2): https://www.fairphone.com/en/2015/10/22/jolla-community-work...
There's AOSP admire android. AOSP is open source which is some components of the Android system - however a lot of Android is not just AOSP. A lot of it is Google web services and other proprietary stuff.
It would be nice if there were a 100% free-software version of Android available, or a way to remove all of the proprietary blobs from an Android phone.
As the OP is looking for an alternative to Ubuntu Phone, one has to bear in mind that Ubuntu Phone wasn't 100% free-software either (it used the same proprietary drivers and blobs as Android).
My best bet would be to restart/re-instantiate a community around CyanogenMod/Lineage OS, Android being F/OSS after all. Though maybe the community around CM is still strong (I honestly don't know).
Question is, are you willing to spend money (or testing/integration efforts) on a community O/S for your phone in exchange for knowing that you're not being spied on all the time?
I could imagine a model where you pay a reasonable price for a tested/supported third-party O/S, but maybe CM has shown this isn't economically feasible.
I don't remember android being floss since google bought it. My exprience of cyanogenMod is bad: support for the devices I owned was shaky to inconsistent through time. Then it turned into a commercial attempt at maximizing profit.
IMHO the effort put into cyanogenmod would have been better used if put into building an actual OS. Though this is a mostly unreachable moving target as devices get obsolete faster than one can add support for at best manufacturers do not help.
Right now I'm considering jolla/sailfish for the next time I buy a phone which hopefully will not happen before 4 or 5 years.
Someone linked to two daily wtf on hn the other day and that to me shows tizen under the current management is not simply useless but actively harmful.
Code quality seems to be a large issue for Samsung in general (no sources, but some first-hand experience). My gut feeling is that it's caused by the extremely bureaucratic Korean corporate culture. Though I'm sure someone who has actually worked there could shed some light to this phenomenon.
What I found out only recently is that Tizen's UI uses Enlightenment's foundation libraries (EFL), which made me kind of interested in getting a device running it.
Samsung has a range of smartwatches and wearables that run full Tizen (Gear S2, Gear S3, Gear Fit 2).
You can install custom software on these devices, and even SSH in over Wi-fi (which sounds like a crazy thing to do on a watch!).
I made a native EFL app for the Gear S2/S3 that did ship (the client was an European airline). The tools are kind of retro (compared to e.g. Xcode), but they work.
The problem is that most of the hardware is not open. It is hard to get fully open software running in proprietary environments like mobile phones and networks. The fairphone might be worth a look though: https://www.fairphone.com/en/
Fairphone might be interesting, but it does not solve the problem of blobs, the open source part must come from the chipset providers and they are not that willing.
>what exactly "not open" means in the hardware context
As natch said, lack of documentation. This lack of documentation prevents others from developing their own drivers etc.
>why so many manufacturers do not make "open" hardware
Multiple reasons. The first four of which I am confident that often play a large role, and the two last of which are more speculation.
1. Companies might feel that open hardware would put them at a disadvantage because others could copy them.
2. Company might have licensed portions of the hardware from other companies and therefore must adhere to agreements about not sharing information about the licensed hardware with others.
3. Maintaining an open project is a lot of work for a company. Everything from ensuring that the whole process is repeatable, to having a team of lawyers approve everything for release.
4. There is no incentive. Users buy their phones either way, even if everything is closed and proprietary.
6. Company might be using software tools in the hardware development process that they can't share freely so even if they did share the files others still wouldn't be able to use the files for anything?
7. Everyone's hardware infringes tons of patents that they didn't license or even probably know about. Open source drivers and documentation will expose that fact and invite lawsuits.
"I've wondered lately what exactly "not open" means in the hardware context, and why so many manufacturers do not make "open" hardware."
What you need to understand is that your mobile phone is not a single computer. There are at least three computers inside your phone that have their own CPU, memory and ability to run code.
First, there is your SIM chip. Your SIM chip is a fully functional, standalone computer with its own CPU and memory. Your SIM card can (and does) run arbitrary java applets that can be forced onto it by your carrier without your knowledge. Yes, that is indeed as terrible and horrifying as it sounds.
Second, there is the baseband processor which handles all of the tricky real-time radio comms with the cell towers and which could not be preempted by your browser or other apps you would be running on the AP (see below). The baseband processor is not controlled by you, can be controlled by your carrier, and in many cases has DMA control over the memory in your application processor (what you think of as your "phone"). Yes, you read that right - many, many mobile phones can have their physical memory directly manipulated by a baseband processor that they do not control. Remember that next time some cute "secure" messaging/encryption/marlinspikey/secretive communications app gets released.
Finally, there is the application processor which is the "actual" CPU and memory that you think of as "my phone" which runs things like the uber app and chrome and facebook.
We are sort of, kind of, getting closer to having a free/open stack on the application processor only. There are two other very powerful agents in your telephone that we have made almost zero progress in opening up. There are very powerful financial interests that stand in the way of opening those up.
You could get rid of two of those three computers, could you not, if you went for say an iPod Touch, as opposed to an iPhone. And then separately you got a dedicated WiFi hotspot. At least this decouples those functions into two devices and breaks the DMA link that you referred to.
I've heard long ago that the government (or whatever agency is responsible for this) won't license you to produce a phone if you don't put a baseband chip in your device. Don't take my word for it, I'm only sharing a vague memory.
Sounds pretty logical though. As @rsync said, there are very powerful financial interests behind the hardware backdoors in phones.
Exactly. iPhones are completely locked down, and with Android devices that best case is you can install Cyanogenmod or Lineage. They still package a giant binary blob from the manufacturer. You cannot install something like Ubuntu or FirefoxOS, so of course those died.
Long-term (1-2 years or so), keep an eye on Fuchsia. Nobody yet knows what Google's intentions are with this project relative to Android (which has a staggering installed base, btw, and is going to stubbornly stick around like a slightly less terrible Windows Mobile 6); right now it's just a research project. But it can apparently scale from tiny IoT sensors to ARM phones to x86 PCs.
Maybe not directly - my guess is that they want to get rid of the Linux kernel: the Linux driver model leaves Android upgrades held hostage by OEMs and SoC manufacturers who are incentivized against old phones getting OS upgrades (planned obsolescence).
With Fuchsia, Google has a clean slate and can choose to have 'write-once' drivers with a stable driver interface across kernel/version upgrades.
Writing once-off proprietary drivers for Linux is equally easy, no more, no less. Proprietary Linux drivers have the added downside of not supporting later kernel versions.
With mobile, as things are, you're guaranteed to have a bunch of proprietary drivers. With the Linux kernel, all the modules need to be the same version of the kernel because you can't guarantee that the interface hasn't changed. Contrast that with Windows, where the same driver file will install and work with a wide range of actual Windows kernel versions.
If Fuschia provides a stable driver interface, then it would mean that my 5-year-old phone doesn't need to also use a 5-year-old kernel to interface with its closed-source drivers. It'd be a big win, overall.
That seems like perfect being the enemy of better. The realistic options aren't "stick with current model of closed drivers locked to specific version of open kernel" and "force hardware manufacturers to produce open drivers". That second one isn't going to happen. The best you'll get is an open shim and a closed blob.
I'd agree if it wasn't Google we are talking about. With the Open Handset Alliance they certainly would have the power to force hardware manufactures to produce open drivers.
I agree that they'd have the power to do it. I don't think they have the motivation, though. It's a clear win for the customers, but a lot of work on their part that I don't think would translate directly to numbers on earnings reports.
It's a retreat. It could have happened. The ground was ceded when closed source drivers were allowed to be willy-nilly linked into the kernel with impunity, a clear GPL violation.
The Free Software initiative requires bravery and confidence. The idea is that if you establish a large enough base of viral software, people will eventually have no choice but to become a part, or be put at great disadvantage. And it worked. Linux is everywhere. The only places it didn't work, are the places we were too cowardly to press the advantage.
Stallman was right. You cannot compromise. Once you start paying the Dane-geld, you'll never get rid of the Dane.
Also, downvoted to 0 is one downvote. Hardly worth getting upset over, there are plenty of people who downvote everything to try to move their post further up, and you're not going to get an explanation from them. All complaining will do is invite further down votes from people who don't like to see complaining.
The thing is that fixing security bugs in old Androids just isn't that hard. I'm not talking about making Samsung upgrade their Galaxy S3 (a five year old phone) to Nougat (which also isn't that hard, Cyanogenmod (before it was LineageOS) did it, and the hardest part (back porting kernel features) is done by a very small team IIRC), but fixing bugs shouldn't be so much work.
The issue is that there is almost zero benefit for Samsung to bother.
So how will Fuchsia help?
Maybe now Google will contractually obligate companies using Play services to upgrade for X years?
How long will X be?
Based on Google's own history, I doubt it's going to be longer than 2 years since "flagship release".
Now this made sense when you got free phones every two years, so must people just upgraded then (why not?) But now that you actually lay out $800 on a flagship phone, people are holding on too their phones for much longer (and there's not much of a reason to upgrade, unless you're playing heavy games, SGS3 is perfect).
But we may actually lose something: If Samsung/Qualcomm can close source their kernel, it's going to be tough to build your own "Fuchsia." So even if you're an expert and shop smartly, you'll still be at the mercy of your phone manufacturer (see Motorola and their promise).
I read a linked article on here recentlyish that made an interesting note about the impact of Google being an advertising company: Android is Google's effort to create a defense moat by blasting a 100-mile crater around their ad properties. They can't turn Android into Broadway or a popup factory, but they can carefully court the DoJ (who fired the antitrust case at Microsoft in the 90s) and creatively push the boundaries.
Looking at it that way, Google have little incentive to rock their own boat.
There's also some interesting ponderation to be had considering why Android BSP propagation/vendor branding works the way it does in light of the above. Absolute device control (aka a flagship device) is likely only an option for Google (and Microsoft, thinking about it!) because of the competition; in fact now I wonder how fine the line is that Apple's skating (although I imagine the competition is what keeps them going as well).
In any case, I see Fuchsia as Google's equivalent of Microsoft Singularity. I'm trying to figure out what kind of point they're making by developing it in the open; they've likely gone through a hundred similar initiatives internally, as did/have Microsoft. Although now I think about it, Google do seem to have some practical business/real-world targets to hit with this (IoT is the likeliest actual hit) so maybe they're just publicizing it for that reason.
Regarding the openness of the kernel, all I can do is hope like mad that the kernel generally stays open on production devices (in "end-user" mode), or that there's some sort of developer option (and hardware, if necessary) available. And I can only hope like mad that Google figured out and appreciate the massive value of an open device, and don't do anything monumentally stupid. Fuchsia has an open repository, at least, which is a very nice start.
because quite frankly it's a change of kernel from linux god kernel to a mach type kernel, the android api on top does not change and in fact is the same android api
> Nobody yet knows what Google's intentions are with this project relative to Android
Pretty sure one of the effects will be total inability to port Linux drivers to the platform in order to install different operating systems. Not saying that this is easy today, but still some degree of compatibility allows the creation of jailrooted environments.
A 100% OSS alternative to iOS and Android sadly won't be here anytime soon, surely not from the big players.
Fuchsia is not an answer to this question. It's exactly the same as Android. Android is technically open source as well.
Also, Fuchsia will never be an distribution or branded OS on it's own. It might replace the Linux kernel is some bigger operating systems. Could replace Linux in android or chrome but I doubt it'll be fully new standalone OS.
The problem isn't software. Let's say I have a dozen engineers to develop a mobile UI on top of BSD. What do we use? Nothing, Nada, rien. There is no real hardware. Even Linus can make a kernel, if there is hardware to develop it on! So software isn't the problem.
F-Droid is cool but will lack lots of applications, even open source ones. I recently checked what it would require to publish my app there -- alas, can't do that since my app includes an API key that can't be published (according to the rules of the service in question), and F-Droid would need that[1].
I never developed an app so I dont know, but if you cant include in the APK because people can decode it, how do you distribute keys and secret strings?
You distribute user-specific secrets after a user has logged in over a secure channel.
You don't get to have app-specific secrets - since anybody can get and run the app (and modify it!), nothing in it has a reason to be secret. This means that you don't get to have an API that's available only through that app and with limitations set by that app. If you use a third-party API that requires you to enforce limits on its use (e.g. that end users can't redistribute access to that API), this means that you can't meet the requirements of that API licencing.
That's a very technical viewpoint. The API agreement tells not to share the key, which obviously does not mean you can't include it in the app binary. I interpret that as not being allowed to publish the key with the source code though.
That's pretty weird and questionable interpretation, since if I have a binary — I have the key, even if in some obfuscated form (even that isn't usually true with APKs though), but whatever, if it works for you — fine, then I have a solution to your problem.
Don't include API_KEY in the published source, include rot13(API_KEY).
You have to consider the intention of the service provider, which in this case is more geared towards mobile clients than web services. It's perfectly clear that binaries will include the API key, no interpretation needed on that part.
It's the source code part that is open to interpretation. I could of course just ask for explicit permission for that.
I dont get all that API key nonsense, you can search this board for our opinions on API keys. I’ll keep this short:
If your app requires an API key and you withhold it (because you entered an agreement with the service provider), this basically makes it not buildable for 3rd parties in a useful manner. F-droid will not sign an agreement with whatever service provider you use nor will we withhold build information.
There are actually only two solutions:
1) Provide a way for the user (!) to enter API key or account information at runtime.
2) Provide a way for us to get the key at buildtime, e.g. there was one app where I had to download a pre-compile APK file, extract the key from it and re-use that key in our builds.. which sucked. Anyway, I dont see what’s the difference to just providing the API key. If you distribute an APK, you distribute the API key (in one form or another) — since without it the app would not work… sigh.
You can build the app, and to make it functional you could request your own API key, so I think it satisfies the label. Requesting API keys as a regular end user isn't anywhere near being realistic though, so that's not an option for distribution.
From pawadu's response above it sounds like your app would satisfy the requirements if you have a build parameter or similar that lets them specify the key.
There's another discussion thread [1] which takes a strict stance more explicitly: "I don’t see how something that contains a ‘secret’ key [...] can be Free Software. So we just don’t publish such applications."
Yeah, BTW the good thing about these stores is that they install apps normally, by launching the system APK install dialog, instead of the rootkit-style thing Google Play does.
It uses special privileges to run the installation in the background. Google Play Services is frequently called a "rootkit" because of stuff like that.
F-Droid has several apps where they download a built APK, decompile it automatically, extract the API key, and build the open source app with that key.
The main problem with FOSS Android seems to be that your device has to be actually supported due to the myriad of cpu, graphics etc. combinations. I looked shortly for a tablet of mine which is completely workable but hangs at Android 4.2 - unfortunately there doesn't seem to be a CyanogenMod variant for it (so, probably no Lineageos either). The update story of Android devices is really sad ..
Thanks for the hint, will look into it. My current tablet is an old Huawei (Mediapad T1 10/T1-A21L). It was part of a promo action and does what I want (I mainly use it was PDF reader), but Android 4.2 gets old and security doesn't get better, so maybe time for an upgrade and this time something LineageOS supports.
This doesn't solve the problem, when asking for an alternative to Android. My issue with Android isn't just Google and privacy, but the fact that Android is pretty notoriously insecure at this point.
I've been carrying Windows but Microsoft just effectively announced end of life for the last two phones on my carrier.
Experience, incredible numbers of CVEs, arrogant yet meaningless statements from their security team over time which has convinced me they do not care. Lack of commitment to update distribution.
Heck, Fuchsia is built with a reasonable security model, most work on Android goes into making excuses for theirs.
At least if I'm carrying something obscure the likelihood of being targeted is low.
I don't have the time or desire to do what's required to securely operate on the Android platform.
LineageOS user here: This is the best Android distribution I've used, by far. I've used Paranoid Android, Slim8, Dirty Unicorns,... But none get to the level of featured and stability of LineageOS.
Extended per-app privacy settings, built-in root manager, lots of customization options... And the best of all: enormous community. There are builds for crazy amounts of devices.
Was there an official announcement on the killing of Ubuntu Phone? There was an official pause announcement, and it might as well be dead - is there an official status update?
The http://puri.sm people are trying to make an open source phone running their distro PureOS (based on debian). They even said on a podcast that they have removed or mitigated the binary blob issues. Apparently they are already working with Gnome developers to make Gnome work on a small screen and build the specialized phone software like a dialer.
Sadly, it will fail. I spoke to the founder about the project and in my opinion he's underestimated the challenge. He said something to me like "all we need to do is solve the battery life issue". That's like saying, to get to space all we need to do is build the space shuttle. As far as efficiency is concerned, android is the only show in town. Debian won't cut it. What he does works for stuff you plug in, not for battery operated gadgets.
The alternative is Android. Unfortunately the "alternative android" ecosystem isn't very good.
My dream would be an android "distribution", that doesn't rely on some murky "update by getting a new image somewhere if you're lucky enough that someone built one for your device". WOuld work more like a linux distribution (packages and updating) and is generic over a variety of phones. Challenge is probably how to handle drivers.
For me, a very interesting option at the moment is Sony's official AOSP builds for a number of Xperia devices[1].
You're able to build an image yourself from their source if you'd like slightly more comfort, and can run it without gapps if you're privacy or software freedom conscious.
And kernels, and random software the drivers require, and special snowflake bootloaders, ...
I'd love to see it, but considering how long it took desktop Linux distibutions to run semi-reliably on most PCs which have far fewer hardware differences and important components without even partially reverse engineered specifications, I'm very suspicious this is a feasible way forward.
> My dream would be an android "distribution", that doesn't rely on some murky "update by getting a new image somewhere if you're lucky enough that someone built one for your device".
This is why (just like for any other OS) you buy a device with explicit support. You don't buy a random laptop and then complain why macOS doesn't run on it... do you?
It's not exactly the same, though. You can buy a random laptop and throw Windows on it, even if it's not the version it shipped with. You can throw Linux on it, and it will almost certainly be usable; sound may not work, it may not resume from suspend, and graphics may be unaccelerated, but if will basically work.
If you're buying a new device, then yes, certainly you should shop for one that's supported on LineageOS or OmniROM, or whatever. But one of the uses of custom ROMs has been extending the life of older devices, and that ecosystem is very spotty.
It is exactly the same. I put Windows 10 on an older Dell laptop. It mostly works, but it's not "supported" and I get blue-screens once in a while. There's just no practical way to keep supporting arbitrarily old devices, even for a company like Microsoft.
If it's exactly the same, I will hand you an unbranded phone with no OS and see if you can get Android running on it. The only machines you can't get Windows running on right now are Chromebooks, so 99% of personal computers will let you pretty easily install Windows in exactly the same fashion you would on any other computer. It might not run well, but it will certainly install. If it's exactly the same, do that with Android on any random phone.
"Sound may not work" and "but it will basically work" being in the same sentence is more-or-less why Linux is still not yet ready to take on Windows and OSX in the desktop space.
What you're describing is similar to the situation with mobile devices, only to a lesser degree. Turns out, making an OS run on hardware is challenging and under-appreciated work, and continuing to gloss over the complexity of it doesn't do solving the problem of open-source OSes any favors.
If that sounds bad, then wait 'til you hear about Apple's situation - they don't support custom hardware, at all. Not only does sound not work, nothing works. Linux is a step above macOS in that it not only does it work very well when it ships with a computer, it also still works ok when you load it on any other computer. And yet, macOS has more users than linux does... Perhaps support on random computers is a bad metric for the readiness of an OS?
The problem you are describing is at once intractable and a solved problem. Most oems are at best ambivalent about Linux support. If you are lucky they provide enough documentation for volunteer labor to support their hardware otherwise someone has to for free spend their time reverse engineering their pile o' hacks.
Since there isn't an inexhaustible well of free labor to throw at other peoples hardware there will always be some hardware that either doesn't work right or doesn't work right out of the box because it requires fix foo that is only available in version bar that is the very latest that hasn't made its way into the stable version yet. If you run a bleeding edge distro you may find that you have the needed version of bar but they broke something else!
The solution is to buy hardware with the OS you intend to run in mind. If you are just curious about whether linux might be useful to you the easiest thing in the world to do is try it out either via live usb or virtual machine. If indeed you would like to run linux and it doesn't work with your existing hardware just buy with Linux in mind when you get your next machine.
Instead of asking whether linux can meet the impossible standard of running flawlessly on any pos you happen to throw at it ask whether there exists a reasonable range of hardware that meets your needs and expectations.
If you approach it that way you will most likely be satisfied.
That's basically my approach; when I want to run Linux (because the applications that run in Linux are useful for a wide range of things, and I'm very used to the command line), I tend to run it in a VM alongside / atop the Windows or OSX install that the hardware I'm using boots to.
The exception I regularly hit is raspberry pi, but in that specific case I (a) don't actually expect anything to really "just work" out of the box (the whole point of the platform is to hack around on it) and (b) I'm not trying to use it as my primary development / work / games / day-to-day environment.
Generic drivers have made explicit support mostly unnecessary in the desktop space. This doesn't exist on mobile. I've installed Linux effectively on many many pieces of junk whose designers never intended their hardware to be used that way.
Isnt Google's Fuchsia the project to tackle this very problem?
On the other hand it has potential for even more 'closed source'-ness on the handset manufacturer side of Android. And maybe even for other industries, once its market share rises.
LinageOS is the successor of CyanogenMod, they just started a few months ago.
The website and everything else is still new and very much work in progress. I guess their main focus was getting up the core infrastructure before making a cute website.
At the same time, saying "This is who we are, this is what we're doing" is pretty important. It's not part of a "cute" website; it's part of a functional and informative one.
No. Just no. This is not one of those, "You're welcome to contribute" things. This is one of the most basic things to have, and for them not to have it reflects extremely poorly on them. This is like not having the build scripts. So do not try to spin it. They very rightly should be criticized for not having that.
With what? Typing up a paragraph on the homepage that says "HEY CHECK THIS SHIT OUT. HEARD OF CYANOGEN? JUST LIKE THAT."
The lineage site is pretty garbage. It tells you nothing about it, and had I not been following the Cyanogen news, I'd have no idea what it is. It's literally impossible to figure out what it is from any page of the website.
I recently tinkered around with putting LineageOS onto a Samsung Galaxy S3. It was super easy to do, and is a really clean, fast, and efficient operating system. I personally enjoy it. I had previous experience with Cyanogenmod, and LineageOS is way better.
Unfortunately, I've got an S6 as my daily user phone, and there is currently no stable version of LineageOS that supports the S6 (as far as I'm aware).
Right, the monolithic images make sense for the phone manufacturers who want to update a lot of identical devices. Much less for the individual, who wants to install a distribution on their device (which e.g. might no longer be supported by the vendor).
I always found it wierd that people talk about "flashing" "ROMs", like it's firmware. It's not, it is under the hood not too different from installing a desktop OS on a hard disk (except you can't pop in a USB drive, you have to use a cable and ADB).
The (e.g. CyanogenMod) ROMs for different phones are not too different. In principle, you could wrap something around ADB that "flashes" (well, copies) a base OS, and then the needed drivers / radio / apps per model.
Also wierd that you can't easily replace individual components. If I want to make a change to a base package or the kernel, I have to reflash everything, instead of replacing one file (well, you can yourself, but nobody in the scene offers that).
> My dream would be an android "distribution", that doesn't rely on some murky "update by getting a new image somewhere if you're lucky enough that someone built one for your device".
While drivers are supplied as binary blobs, this will be impossible.
The project has transitioned to a non-commercial license (https://creativecommons.org/licenses/by-nc-sa/4.0/) until sustainable funding has been acquired. The code is still open source, but apparently asking to be compensated for work that improves the security of the entire Android ecosystem is too much for FOSS fanatics.
Sony put everything you need to run your OS on some of their Xperia phones on GitHub as part of their Open Device Program. Jolla which is going to become open source sometime has been successfully (in feburary 2017) run on one of the devices.
So in the near future, there is hope in that direction.
I second this, I'm pretty happy with my 1st gen Jolla, though it desperately needs an hardware update. To be able to get a terminal either on the device or by logging in with SSH to fix things or make changes is great.
Not all the UI components are open source (yet?) though it's pretty close to stock Qt; at least the base system is open-source, and that's more important to me – I think they want to prevent full rip-offs rather than lock down the system from their own users.
I've been critical of these computer-in-your-pocket claims a few years ago, but I can see now that if the hardware keeps improving at the rate it does, having a full Linux system based on something like Sailfish or Ubuntu Phone with a keyboard and screen attached could work out for a lot of scenarios.
Ok, so Android is open-source as mentioned already by other comments.
Now the thing with Android is that, it is just a framework, so saying Android is Open Source is missing big points
There are two major limits:
1. What about apps?
2. What about drivers?
Today, if you get an Android phone with Google Apps, especially Google Play Store, you have access to many tools that can be considered useful for everyday use, which you won't have with FOSS Android. Here are some examples:
With Play Store, you can have (mostly?) any IM, as long as you install the app going with it. The only possibility I know to do that with FOSS Android, is to use matrix or IRC, and have server-side libpuprle connectors.
With FOSS Android You don't have factorized push socket: Most apps pushing notifications on Android require GCM. But even if it doesn't require GCM, there is nothing fully open-source an app developer can use. All they can do, is open a socket to their own server, and deal with it, which is a huge battery-killer.
Many people are mentioning f-droid as an alternative to Play Store. I'm sorry, but I consider this a joke. I highly respect the work done on f-droid, but this is not a usable alternative.
For instance, you want to save your SMS. We call that backup, but not every knows that.
Well you search for "save sms" on f-droid. No result.
You search for "save sms" on Google Play Store, the second result is SMS Backup+ which is open-source! You search for SMS, the result is on the first page.
Same thing happen if you just search for "sms", QKSMS (an opensource SMS application) is much easier to find with Google Play Store than f-droid.
Even to look for open-source apps, you're better off with Google Play Store!
Again, I totally respect F-Droid devs, this is this way because of their choice of not tracking or saving any user information at all, which is legit.
But then, some people might want something intermediary. Just counting the number of installations of an app can be really useful to better sort apps (SMS Backup+ and QKSMS really deserve to be among the top in the results for SMS).
Now, about the drivers. Yes Android is open-source, but good luck running a phone with a FOSS Android!
At the moment, you have the choice with either replicant, which is old and missing gpu acceleration, or running a mainline Linux kernel with Mesa & stuff, but then you have no radio.
Though I have to mention that on the drivers side, Sailfish OS and Ubuntu phone have also those problems.
> Ok, so Android is open-source as mentioned already by other comments.
Is it ? I thought that only the AOSP part of Android was actually open source and not that useful by itself. I might be wrong here but my understanding is that the opensource in Android is mostly for show/marketing and is getting worse with time.
The next big OS is going to be Google Fuchsia, which runs on the Magenta kernel (not Linux) and runs apps built with Flutter.
Inb4 nay-sayers, but if you have followed Fuchsia for a few months and have seen the speed of development and just how many people and new technologies are involved, you will see why this isn't even a question.
Given Google's current track record for AOSP with bringing active development into Google Play and deprecating open source components, I am skeptical that it will be good for openness.
246 comments
[ 2.1 ms ] story [ 234 ms ] threadUPD:
Jolla -- company behind SailfishOS (ex-Nokia people) https://jolla.com/about/
Nevertheless, if Samsung can't push their Tizen into mainstream I doubt a tiny company from Finland can.
https://techcrunch.com/2016/11/29/jollas-sailfish-os-now-cer...
cool.
Samsung put itself in a position where the company simply cannot walk away from Google, at least in the mobile space (Tizen is actually pretty "mainstream" in smart TVs and wearables). Market shares are pretty much set at this point, and no alternative mobile OS based on linux has a chance to become mainstream, no matter the size of the company backing it. That doesn't stop a small company like Jolla from delivering viable products though, since they don't need to keep Google happy.
Based on what a _single person_ from Finland has achieved, I wouldn't be so sure. ;)
Seriously, though, why even mention the country of origin?
Here's a zany answer: maybe they're proud of their country of origin. Hi-larious, I know, right?
By the way, the phone runs a real Linux distro. There's Wayland, OpenSSH, bash, systemd (ugh...), RPM's, and a ton of good old commandline software like htop, tmux, python, - heck, even gcc if you feel like rebuilding the kernel :) Native apps are built with Qt & QML. There's very little NIH.
There's also support for Android apps. Many of the apps from F-Droid run OK, and even lots of commercial stuff.
Oh, and the phone is pretty fantastic for all the normal everyday things, like being an actual phone.
It looks to me that all Sailfish devices that have ever been available are not compatible with 3G/4G US carriers (but some are compatible with 2G).
It seems that if anyone in the US wants to seriously use Sailfish, they need to flash a community port of Sailfish to a US-sold Android device. Not a huge deal - it looks like a few manufacturers are actively supporting this ports (e.g. for the Fairphone 2): https://www.fairphone.com/en/2015/10/22/jolla-community-work...
The real problem is the hardware driver blobs.
Would you still consider them part of Android?
Unfortunately it is not well supported yet, as porting it to any given device seems to require rewriting several proprietary Android drivers.
Looks like the core maintainer could benefit from donated android devices for Replicant to run on newer devices.
http://blog.replicant.us/2017/02/replicant-6-0-development-u...
Question is, are you willing to spend money (or testing/integration efforts) on a community O/S for your phone in exchange for knowing that you're not being spied on all the time?
I could imagine a model where you pay a reasonable price for a tested/supported third-party O/S, but maybe CM has shown this isn't economically feasible.
IMHO the effort put into cyanogenmod would have been better used if put into building an actual OS. Though this is a mostly unreachable moving target as devices get obsolete faster than one can add support for at best manufacturers do not help.
Right now I'm considering jolla/sailfish for the next time I buy a phone which hopefully will not happen before 4 or 5 years.
https://www.tizen.org
However news that one researcher has found 40 0-days for it doesn't really sound good:
https://motherboard.vice.com/en_us/article/samsung-tizen-ope...
I remember reading about Plasma Mobile
https://plasma-mobile.org
But it looks like the latest phone they use as a Dev device is a Nexus 5x so it may be stalled/dead
https://forums.thedailywtf.com/topic/21368/samsung-insisting...
The story was Samsung's Tizen is riddled with security flaws, amateurishly written
https://news.ycombinator.com/item?id=14036965
https://what.thedailywtf.com/topic/15001/enlightened/2
You can install custom software on these devices, and even SSH in over Wi-fi (which sounds like a crazy thing to do on a watch!).
I made a native EFL app for the Gear S2/S3 that did ship (the client was an European airline). The tools are kind of retro (compared to e.g. Xcode), but they work.
Can someone enlighten me? I do understand what blobs are, but I guess I'm not clear on why they're needed.
As natch said, lack of documentation. This lack of documentation prevents others from developing their own drivers etc.
>why so many manufacturers do not make "open" hardware
Multiple reasons. The first four of which I am confident that often play a large role, and the two last of which are more speculation.
1. Companies might feel that open hardware would put them at a disadvantage because others could copy them.
2. Company might have licensed portions of the hardware from other companies and therefore must adhere to agreements about not sharing information about the licensed hardware with others.
3. Maintaining an open project is a lot of work for a company. Everything from ensuring that the whole process is repeatable, to having a team of lawyers approve everything for release.
4. There is no incentive. Users buy their phones either way, even if everything is closed and proprietary.
5. Regulations regarding wireless communications hardware might apply?
6. Company might be using software tools in the hardware development process that they can't share freely so even if they did share the files others still wouldn't be able to use the files for anything?
What you need to understand is that your mobile phone is not a single computer. There are at least three computers inside your phone that have their own CPU, memory and ability to run code.
First, there is your SIM chip. Your SIM chip is a fully functional, standalone computer with its own CPU and memory. Your SIM card can (and does) run arbitrary java applets that can be forced onto it by your carrier without your knowledge. Yes, that is indeed as terrible and horrifying as it sounds.
Second, there is the baseband processor which handles all of the tricky real-time radio comms with the cell towers and which could not be preempted by your browser or other apps you would be running on the AP (see below). The baseband processor is not controlled by you, can be controlled by your carrier, and in many cases has DMA control over the memory in your application processor (what you think of as your "phone"). Yes, you read that right - many, many mobile phones can have their physical memory directly manipulated by a baseband processor that they do not control. Remember that next time some cute "secure" messaging/encryption/marlinspikey/secretive communications app gets released.
Finally, there is the application processor which is the "actual" CPU and memory that you think of as "my phone" which runs things like the uber app and chrome and facebook.
We are sort of, kind of, getting closer to having a free/open stack on the application processor only. There are two other very powerful agents in your telephone that we have made almost zero progress in opening up. There are very powerful financial interests that stand in the way of opening those up.
Sounds pretty logical though. As @rsync said, there are very powerful financial interests behind the hardware backdoors in phones.
https://lwn.net/Articles/718267/ / https://news.ycombinator.com/item?id=14002386
EDIT: This just got downvoted to 0, unsure why...
Now it is deprecated, but according to the roadmap it will be gone from the SDK with release 16.
With Fuchsia, Google has a clean slate and can choose to have 'write-once' drivers with a stable driver interface across kernel/version upgrades.
Which makes it easier to write proprietary drivers.
> And most likely not supporting future kernel versions.
Huh?
If Fuschia provides a stable driver interface, then it would mean that my 5-year-old phone doesn't need to also use a 5-year-old kernel to interface with its closed-source drivers. It'd be a big win, overall.
The Free Software initiative requires bravery and confidence. The idea is that if you establish a large enough base of viral software, people will eventually have no choice but to become a part, or be put at great disadvantage. And it worked. Linux is everywhere. The only places it didn't work, are the places we were too cowardly to press the advantage.
Stallman was right. You cannot compromise. Once you start paying the Dane-geld, you'll never get rid of the Dane.
Maybe because you called Android "a slightly less terrible Windows Mobile 6".
Also: "Please resist commenting about being downvoted. It never does any good, and it makes boring reading." https://news.ycombinator.com/newsguidelines.html
Okay, that's entirely fair. I guess I've gotten too caught up in the fragmentation and vulnerability hype.
I think I was underexaggerating when I said "slightly" as well - Android is a remarkably decent system by and large.
> Also: "Please resist commenting about being downvoted. It never does any good, and it makes boring reading." https://news.ycombinator.com/newsguidelines.html*
This... woops, I picked that behavior up from others here. Now I know to link to this page instead. Thanks very much.
And I thought I'd I'd gone over the guidelines page a while back, too...
The thing is that fixing security bugs in old Androids just isn't that hard. I'm not talking about making Samsung upgrade their Galaxy S3 (a five year old phone) to Nougat (which also isn't that hard, Cyanogenmod (before it was LineageOS) did it, and the hardest part (back porting kernel features) is done by a very small team IIRC), but fixing bugs shouldn't be so much work.
The issue is that there is almost zero benefit for Samsung to bother.
So how will Fuchsia help?
Maybe now Google will contractually obligate companies using Play services to upgrade for X years?
How long will X be?
Based on Google's own history, I doubt it's going to be longer than 2 years since "flagship release".
Now this made sense when you got free phones every two years, so must people just upgraded then (why not?) But now that you actually lay out $800 on a flagship phone, people are holding on too their phones for much longer (and there's not much of a reason to upgrade, unless you're playing heavy games, SGS3 is perfect).
But we may actually lose something: If Samsung/Qualcomm can close source their kernel, it's going to be tough to build your own "Fuchsia." So even if you're an expert and shop smartly, you'll still be at the mercy of your phone manufacturer (see Motorola and their promise).
Looking at it that way, Google have little incentive to rock their own boat.
There's also some interesting ponderation to be had considering why Android BSP propagation/vendor branding works the way it does in light of the above. Absolute device control (aka a flagship device) is likely only an option for Google (and Microsoft, thinking about it!) because of the competition; in fact now I wonder how fine the line is that Apple's skating (although I imagine the competition is what keeps them going as well).
In any case, I see Fuchsia as Google's equivalent of Microsoft Singularity. I'm trying to figure out what kind of point they're making by developing it in the open; they've likely gone through a hundred similar initiatives internally, as did/have Microsoft. Although now I think about it, Google do seem to have some practical business/real-world targets to hit with this (IoT is the likeliest actual hit) so maybe they're just publicizing it for that reason.
Regarding the openness of the kernel, all I can do is hope like mad that the kernel generally stays open on production devices (in "end-user" mode), or that there's some sort of developer option (and hardware, if necessary) available. And I can only hope like mad that Google figured out and appreciate the massive value of an open device, and don't do anything monumentally stupid. Fuchsia has an open repository, at least, which is a very nice start.
Pretty sure one of the effects will be total inability to port Linux drivers to the platform in order to install different operating systems. Not saying that this is easy today, but still some degree of compatibility allows the creation of jailrooted environments. A 100% OSS alternative to iOS and Android sadly won't be here anytime soon, surely not from the big players.
Also, Fuchsia will never be an distribution or branded OS on it's own. It might replace the Linux kernel is some bigger operating systems. Could replace Linux in android or chrome but I doubt it'll be fully new standalone OS.
I just downvoted you because you complained about being downvoted.
Write your comment and live with it - don't interrupt the discussion to meta-discuss the scoring system.
As a replacement for the Play Store, check out https://f-droid.org/
[1] https://f-droid.org/forums/topic/what-to-do-with-private-api...
You distribute user-specific secrets after a user has logged in over a secure channel.
You don't get to have app-specific secrets - since anybody can get and run the app (and modify it!), nothing in it has a reason to be secret. This means that you don't get to have an API that's available only through that app and with limitations set by that app. If you use a third-party API that requires you to enforce limits on its use (e.g. that end users can't redistribute access to that API), this means that you can't meet the requirements of that API licencing.
Don't include API_KEY in the published source, include rot13(API_KEY).
It's the source code part that is open to interpretation. I could of course just ask for explicit permission for that.
---
I dont get all that API key nonsense, you can search this board for our opinions on API keys. I’ll keep this short:
If your app requires an API key and you withhold it (because you entered an agreement with the service provider), this basically makes it not buildable for 3rd parties in a useful manner. F-droid will not sign an agreement with whatever service provider you use nor will we withhold build information.
There are actually only two solutions:
1) Provide a way for the user (!) to enter API key or account information at runtime.
2) Provide a way for us to get the key at buildtime, e.g. there was one app where I had to download a pre-compile APK file, extract the key from it and re-use that key in our builds.. which sucked. Anyway, I dont see what’s the difference to just providing the API key. If you distribute an APK, you distribute the API key (in one form or another) — since without it the app would not work… sigh.
I think many times you can limit the FOSS version to not include functions such as leader boards to avoid such issues and no one will complain.
Other alternative app stores are the Yandex Store (https://store.yandex.com/) or the Amazon App Store, those include non-free software too.
[1] https://f-droid.org/forums/topic/api-keys-and-free-software-...
F-Droid has several apps where they download a built APK, decompile it automatically, extract the API key, and build the open source app with that key.
You can do exactly that already.
GPLv3 would help.
https://www.amazon.com/LG-Tablet-Snapdragon-Android-JellyBea...
https://download.lineageos.org/v500
There are over 150 devices supported, but the vast majority are smartphones
My last 3 mobile phones were MediaTek phones, but that's one of my biggest gripes with them.
I've been carrying Windows but Microsoft just effectively announced end of life for the last two phones on my carrier.
Why do you think that?
Heck, Fuchsia is built with a reasonable security model, most work on Android goes into making excuses for theirs.
At least if I'm carrying something obscure the likelihood of being targeted is low.
I don't have the time or desire to do what's required to securely operate on the Android platform.
Extended per-app privacy settings, built-in root manager, lots of customization options... And the best of all: enormous community. There are builds for crazy amounts of devices.
They truly care about the privacy and redesign the hardware according to this goal.
Maybe by 2020 and for $5000 we will have a truly free phone with the specs of a device from 2009!
https://en.wikipedia.org/wiki/Maemo https://en.wikipedia.org/wiki/Nokia_N900
There's still a relatively active community going:
https://talk.maemo.org/
http://www.omgubuntu.co.uk/2016/10/purism-wants-make-truly-o...
My dream would be an android "distribution", that doesn't rely on some murky "update by getting a new image somewhere if you're lucky enough that someone built one for your device". WOuld work more like a linux distribution (packages and updating) and is generic over a variety of phones. Challenge is probably how to handle drivers.
You're able to build an image yourself from their source if you'd like slightly more comfort, and can run it without gapps if you're privacy or software freedom conscious.
[1]: https://developer.sonymobile.com/open-devices/
I'd love to see it, but considering how long it took desktop Linux distibutions to run semi-reliably on most PCs which have far fewer hardware differences and important components without even partially reverse engineered specifications, I'm very suspicious this is a feasible way forward.
LineageOS (http://lineageos.org/) has OTA updates with UI: https://1.f.ix.de/scale/geometry/710x500/q75/imgs/71/2/1/3/6...
So your dream has already came true :)
If you're buying a new device, then yes, certainly you should shop for one that's supported on LineageOS or OmniROM, or whatever. But one of the uses of custom ROMs has been extending the life of older devices, and that ecosystem is very spotty.
What you're describing is similar to the situation with mobile devices, only to a lesser degree. Turns out, making an OS run on hardware is challenging and under-appreciated work, and continuing to gloss over the complexity of it doesn't do solving the problem of open-source OSes any favors.
Since there isn't an inexhaustible well of free labor to throw at other peoples hardware there will always be some hardware that either doesn't work right or doesn't work right out of the box because it requires fix foo that is only available in version bar that is the very latest that hasn't made its way into the stable version yet. If you run a bleeding edge distro you may find that you have the needed version of bar but they broke something else!
The solution is to buy hardware with the OS you intend to run in mind. If you are just curious about whether linux might be useful to you the easiest thing in the world to do is try it out either via live usb or virtual machine. If indeed you would like to run linux and it doesn't work with your existing hardware just buy with Linux in mind when you get your next machine.
Instead of asking whether linux can meet the impossible standard of running flawlessly on any pos you happen to throw at it ask whether there exists a reasonable range of hardware that meets your needs and expectations.
If you approach it that way you will most likely be satisfied.
The exception I regularly hit is raspberry pi, but in that specific case I (a) don't actually expect anything to really "just work" out of the box (the whole point of the platform is to hack around on it) and (b) I'm not trying to use it as my primary development / work / games / day-to-day environment.
The idea to build an OS for every device simply doesn't scale.
On the other hand it has potential for even more 'closed source'-ness on the handset manufacturer side of Android. And maybe even for other industries, once its market share rises.
Much more info on wikipedia - https://en.wikipedia.org/wiki/LineageOS
Wow
The website and everything else is still new and very much work in progress. I guess their main focus was getting up the core infrastructure before making a cute website.
The lineage site is pretty garbage. It tells you nothing about it, and had I not been following the Cyanogen news, I'd have no idea what it is. It's literally impossible to figure out what it is from any page of the website.
Unfortunately, I've got an S6 as my daily user phone, and there is currently no stable version of LineageOS that supports the S6 (as far as I'm aware).
I always found it wierd that people talk about "flashing" "ROMs", like it's firmware. It's not, it is under the hood not too different from installing a desktop OS on a hard disk (except you can't pop in a USB drive, you have to use a cable and ADB).
The (e.g. CyanogenMod) ROMs for different phones are not too different. In principle, you could wrap something around ADB that "flashes" (well, copies) a base OS, and then the needed drivers / radio / apps per model.
Also wierd that you can't easily replace individual components. If I want to make a change to a base package or the kernel, I have to reflash everything, instead of replacing one file (well, you can yourself, but nobody in the scene offers that).
You can actually boot your device into TWRP and "flash" the OS zip from USB OTG.
While drivers are supplied as binary blobs, this will be impossible.
I think the biggest issue is still device support.
[0] https://mail.kde.org/pipermail/plasma-devel/2017-April/threa...
I've been running it for some time now and I like it a lot. Support for a lot of phones? No. Wide range of apps available via F-droid? Decent.
I'm not a very appy guy though. Most of my needs are browser based.
Sony put everything you need to run your OS on some of their Xperia phones on GitHub as part of their Open Device Program. Jolla which is going to become open source sometime has been successfully (in feburary 2017) run on one of the devices.
So in the near future, there is hope in that direction.
Not all the UI components are open source (yet?) though it's pretty close to stock Qt; at least the base system is open-source, and that's more important to me – I think they want to prevent full rip-offs rather than lock down the system from their own users.
I've been critical of these computer-in-your-pocket claims a few years ago, but I can see now that if the hardware keeps improving at the rate it does, having a full Linux system based on something like Sailfish or Ubuntu Phone with a keyboard and screen attached could work out for a lot of scenarios.
Now the thing with Android is that, it is just a framework, so saying Android is Open Source is missing big points There are two major limits: 1. What about apps? 2. What about drivers?
Today, if you get an Android phone with Google Apps, especially Google Play Store, you have access to many tools that can be considered useful for everyday use, which you won't have with FOSS Android. Here are some examples:
With Play Store, you can have (mostly?) any IM, as long as you install the app going with it. The only possibility I know to do that with FOSS Android, is to use matrix or IRC, and have server-side libpuprle connectors.
With FOSS Android You don't have factorized push socket: Most apps pushing notifications on Android require GCM. But even if it doesn't require GCM, there is nothing fully open-source an app developer can use. All they can do, is open a socket to their own server, and deal with it, which is a huge battery-killer.
Many people are mentioning f-droid as an alternative to Play Store. I'm sorry, but I consider this a joke. I highly respect the work done on f-droid, but this is not a usable alternative. For instance, you want to save your SMS. We call that backup, but not every knows that. Well you search for "save sms" on f-droid. No result. You search for "save sms" on Google Play Store, the second result is SMS Backup+ which is open-source! You search for SMS, the result is on the first page. Same thing happen if you just search for "sms", QKSMS (an opensource SMS application) is much easier to find with Google Play Store than f-droid. Even to look for open-source apps, you're better off with Google Play Store! Again, I totally respect F-Droid devs, this is this way because of their choice of not tracking or saving any user information at all, which is legit. But then, some people might want something intermediary. Just counting the number of installations of an app can be really useful to better sort apps (SMS Backup+ and QKSMS really deserve to be among the top in the results for SMS).
Now, about the drivers. Yes Android is open-source, but good luck running a phone with a FOSS Android! At the moment, you have the choice with either replicant, which is old and missing gpu acceleration, or running a mainline Linux kernel with Mesa & stuff, but then you have no radio.
Though I have to mention that on the drivers side, Sailfish OS and Ubuntu phone have also those problems.
Is it ? I thought that only the AOSP part of Android was actually open source and not that useful by itself. I might be wrong here but my understanding is that the opensource in Android is mostly for show/marketing and is getting worse with time.
Inb4 nay-sayers, but if you have followed Fuchsia for a few months and have seen the speed of development and just how many people and new technologies are involved, you will see why this isn't even a question.