Even the people not fighting against people in the War on General Purpose Computing keep seceding our sovereign systems away from us. The need for security is real, but I don't see that we are approaching it with balance. We seem to be growing ever more heavyhanded, permitting users less & less, and I don't see a reciprocal respect & empowerment being considered, furthered or advanced.
This is something Stallman and others have been talking about[1] for more than a decade now.
However the other angle is, this phone is an appliance and I want it to just work. I'm personally competent enough to have that cake (programmability) and eat it too (reliable usability) - after all I've been running Red Hat/Fedora as my primary desktop OS at home for two decades and it works just fine, thank you. But I also remember what a horrible mess the average schmoe's home computer was back in the good old days... remember an outdated version of Internet Explorer with half the screen obscured by a stack of junky toolbars, and the whole thing running at 800x600 on a monitor capable of higher resolutions "because otherwise the letters are too small". Good riddance.
Anyway for the moment, second-hand desktop and laptop machines that can run a full, unencumbered compute environment are still plentiful. Maybe by the time they aren't, I'll be a truly old fart who doesn't care any more.
This mode, however, is such a denigration to humanity. All the spirit of augmenting the human intellect, computing being servant to the human psyche, harnessed by human creativity... it's a way-more-than-tacit admission of defeat, a brazen retreat. It just seems... unaccounted for. We don't talk about this loss, this turning around. We trumpet security & chalk up wins for helping each other, but there's no mainstream dialogue that supports the deeply enriched angle, the immersive, expert computer user, the post-training-wheels life. Everything is centered around the dumb consumer, all of computing focused around a consumerized applicationized "just work" mentality.
I think we've been drinking poison.
Hopefully courts will begin to recognise that this sort of "security" is in fact created for the benefit of the company and its customers, not users. Any benefits to users are incidental.
Users are not soliciting these "security" measures. They are always initiated by the company.
As it is, this entails limiting the users' freedom to tinker in such a way that they simply cannot screw things up no matter how hard they try. Because, you know, if users have that option, then someone will take advantage of it and screw things up.
This line of thought has powerful political and philosophical backing, as digitalization is seen as the magic bullet that will solve a wide array of issues throughout society, and the general idea seem to be to protect people for their own good. Incidentally, it's often the most profitable route as well, as it's the only way to get non-technical users on-board.
I've had my parents on Ubuntu Linux for a while now for exactly this reason: no matter what they do, they aren't going to screw things up, even if they tried. It just works.
So far there have been no complaints and no issues.
There's a lot to be said about freedom of computing, but the fact remains that given the option to screw things up, then some people will do that. At the same time, we have a culture that incentivize catering to the non-technical users in a way that prevents them from screwing things up.
Long story short: If we want to turn this trend, then we need to:
1) Start telling non-technical users that any damage caused through their freedom of action is their own responsibility.
2) Produce competitive products that not only provide the desired amount of freedom, but which also compete on price, desirability, usability and the impression that the products are secure enough to use.
In many cases, 1 will be seen as a way of avoiding responsibility, and it'll take a tremendous amount of effort to convince users (and consumer protection agencies) that they should be less protected just in case someone else decides to tinker with their product. That alone makes 2 more or less impossible.
There should be a "I know what I'm doing" switch that disables a bunch of restrictions and essentially enables full root privileges for your user.
Kiwi browser does.
If that was your issue too there are various frontend forks that fix that issue in better ways than F-Droid has attempted to. I for one use FoxyDroid which is about as minimal as it gets, but still usable and pretty to look at. There's also AuroraDroid (best looking one IMO), and G-Droid as alternative frontends.
Honestly I'm a little confused about the DIY mobile software landscape, and would love to get a minimalist, open-source wonderland mobile OS - and I wouldn't even mind if it was browser native, and neither should anyone else because WASM.
dont need a special lineage install to get it, seems to work anywhere
[1] https://en.wikipedia.org/wiki/Telephone_call_recording_laws#...
[2] File to edit: https://github.com/LineageOS/android_packages_apps_Dialer/bl...
Maybe it's complicated for telephone conversations where you're not breaking a law locally, but are breaking a law remotely?
Android doesn't expose it because the hardware doesn't expose it to the OS in the first place.
Well... IIRC there was never an official call recording API, and in fact on some phones it was physically impossible to snoop on the telephony audio.
Most recording apps used to either work only on some qualcomm single chip phones where baseband exposed audio path to application processor, or enabled microphone recording in hopes of catching the audio from speakers (and not all phones allowed simultaneous mic use like that).
The NDK was only added in 2.0 to appease game developers and workaround for Dalvik anemic performance.
Any access to Linux APIs was accidental and never part of the official native APIs.
Android ported to any of those platforms would still make use of File("myfile").createNewFile() with zero dependencies on a Linux implementation.
No it doesn't, the API call is still valid in Android 11, as long as the filesystem reserved for the application is used.
Even so, it has to do with the Java implementation.
It is the main userspace programming APIs are written in. Followed by the increased use of Kotlin.
In both cases, the final execution tier does produce a pure binary, when the device is idle, after getting the PGO data from the JIT tier.
The NDK C and C++ APIs are based on ISO C, ISO C++, OpenGL, Vulkan, OpenSL (now replaced by AAudio), and Android specific native APIs.
Plenty of choice, just not Linux specific APIs.
Like pretty much everything that goes against the user and people are way too quick to accept anything that has the word "security" applied to it.
I don't have much experience with DEBs, but have quite a bit with RPMs and their spec files which are used to create them, and this wouldn't be that hard to do with an RPM (and you can convert RPMs to DEBs in many cases with utilities).
It's not shiny but it does work. Continuing to use abusive software is a disservice to yourself and everyone around you.
If current GNU/Linux phones work for your needs, that’s great - but sorry to say that you are not representative of all users (neither am I - that's the point, kind of - Android/iOS are mature enough to cover most users' needs). I don’t want to go into too much detail of my specific needs, but let’s just say the deficiencies boil down to (a) vastly inferior power management/battery life, (b) vastly inferior processing power in the current crop of hardware and (c) specific apps/services not being available on the platform (and likely impossible to run via Anbox because of (b)).
I would actually love to jump to a GNU/Linux phone. Less so because of freedom or privacy concerns (they are a factor, but not the dominating factor). More because I prefer the traditional desktop/general-purpose-computing OS way of doing things (file-centric vs app-centric, root access to the entire file system, development directly on the device). I would honestly be fairly happy with Android if it was pre-rooted, imposed fewer restrictions on what apps can do, and was based on a mainline kernel ideally.
I have previously used Ubuntu Touch for about a year on a secondary device, I have a Librem 5 on pre-order, and I follow development for the Pinephone somewhat closely and am tempted to get one. But for the foreseeable future I can't see a GNU/Linux smartphone replacing my Android - I'd see it as a complement to it (a tiny portable laptop).
* Google services for work / school
* Facebook / Whatsapp / Instagram for keeping in touch with friends.
* Spotify, Netflix etc.. in good resolution
* Many other specific apps.
It's not all black and white either. Traditional linux doesn't sandbox software. Android does sandboxing pretty well.
Building an alternative phone OS is much harder than building an alternative desktop OS—the requirements are much higher (battery life, cellular, app support) and the mobile web is far less developed as a stopgap compared to the desktop web.
Desktop Linux is usable for most developers and people who don't care about UI consistency or proprietary applications like Office and Creative Cloud. That's a reasonably significant chunk of the computer-using population. The same cannot be said of phones.
I haven't had it working on Android or iOS for years, only realising when it accidentally tries to send.
I just assumed it didn't work because nobody cared.
My bar for widespread adoption is far higher, but it may be somewhat unattainable and it's definitely not necessary for the types of people who use desktop Linux. Even if you're happy with desktop Linux—in other words, your expectations of integration and proprietary software support are low—you won't be happy with current Linux phones.
They are, to my understanding, the default way of sharing pictures and group messages between iOS and Android there.
I think it would be good to point out that MMS often doesn't even work on android phones. So making that a requirement is a bit silly.
Their workaround is fairly clever (although not yet implemented) but means that updates to the Play Store version have been temporarily put on hold.
https://github.com/termux/termux-packages/wiki/Termux-and-An...