[j-james]

Termux has recently run into issues with Android 10 and the more recent APIs, which break its form of package management.

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...

[rektide]

Comments like this one[1] that mention having difficulty using Termux to access SD cards keep making me feel like we are radically over-securing devices. More and more it feels like the OS, the browser, are guarding the user not against bad apps, but also against the user. Firefox Mobile only allowing less than a dozen extensions. Chrome mobile supporting no extensions. These are different than the OS, but the same kind of decisions done "for the user" by removing capabilities from the environment.

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.

[1] https://news.ycombinator.com/item?id=24982862

[quicklime]

What worries me most is that our devices are being radically over-secured according to a threat model that doesn't include companies that share my data without my permission, but does include open source developers building general-purpose tools. The former are actively encouraged, and the latter are considered collateral damage.

[anderspitman]

That might have something to do with the fact that the people making the OS are also the people most interested in your data.

[heavyset_go]

> More and more it feels like the OS, the browser, are guarding the user not against bad apps, but also against the user.

This is something Stallman and others have been talking about[1] for more than a decade now.

[1] https://news.ycombinator.com/item?id=24881893

[MarkusWandel]

Well, I approach it from two angles at once. One, a pocket computer running Linux which, using Termux, could be a full Linux machine - in which I can run Perl scripts on my SMS messages, grep my emails, rename and organize my photo library and so on. Which was presumably mostly possible on old, less secure versions of Android. With Android 10 and its exec restriction, sure you can still install precompiled packages as apk's but what about simply compiling a small C program and running it? So the old school tinkerer is sad that I'm locked out of a perfectly good Linux machine that I own.

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.

[rektide]

I agree that there are multiple angles. I think of them as different contexts. What I see is that, at the moment, we're designing, permitting, allowing, creating, constructing, & securing only for one angle, only for the pure-consumerism mode, the mode where we assume the user is in "don't care/don't know" mode.

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.

[pabs3]

Maybe Android just needs to add support for virtual machines? Then you could have the best of both worlds.

[1vuio0pswjnm7]

Can the user really achieve "security" without having full control. When the user is not the customer of the third party providing "security". (In this case advertisers are the customer.)

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.

[fogihujy]

This is not a part of the war on general purpose computing; it's a part of the effort to make Eternal September to end by making software that works for everyone.

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.

[heavyset_go]

> 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.

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.

[fogihujy]

Ditto with my in-laws and Linux Mint. Thing is, they don't really care about tinkering (just like most people) and so they don't care. Allowing them to tinker would benefit them very little, while it would definitely increase the risk of them screwing things up.

[rusk]

That’s the cover story LOL

[fogihujy]

It's the official story, no matter how you put it. I'm not saying it's a good thing (in fact, I find it horrible), but it is what it is and I have no idea on how to turn that tide.

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.

[rusk]

I really think this line of thinking is overegged. It is one thing to make a device easy to use, yet quite another to lock them out for creative purposes.

[fogihujy]

It's not about making things easy to use, but about making them harder to break. Creative tinkering is simply not taken into the consideration for most consumer products. Things like support load, RMA rate and consumer protection laws is.

[Valkhyr]

Could not agree more.

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.

[npsimons]

Stallman was right.

[unicornporn]

> Chrome mobile supporting no extensions.

Kiwi browser does.

[nanna]

Reminder that Termux is available on F-Droid.

[javajosh]

I've had a terrible experience with my LineageOS S9.

[0xdeadb00f]

F-Droid's UI is trash in terms of usability IMO. Quite clunky.

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.

[tweetle_beetle]

I agree, the big F-Droid redesign was a step backwards. I didn't know about the alternatives though. Thanks

[donio]

What does that have to do with Termux or F-Droid?

[javajosh]

Free associating? I never experienced F-Droid before or since my scattered Cyanogen/LineageOS experiments. Honestly, I doubt I'm alone making that distinction (similar to how its hard to make a distinction between javascript and jquery when you're first learning)

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.

[DennisAleynikov]

fdroid is kinda like cydia, repo based but often open source/FOSS stuff you can install as apks on an android OS device.

dont need a special lineage install to get it, seems to work anywhere

[ce4]

Yep. You can even install f-droid on Amazon fireTV sticks using the sideload feature.

[bosswipe]

I hate the direction Google is taking Android. They're on an appliance-ification quest trying to hide any exposed linux-ness of the OS, including trying to remove developer access to all file handles. They always claim it's in the name of security but my suspicion is that it's an effort to transition from Linux to Fuchsia.

[varispeed]

For me so far the worst thing Google did was disabling API for call recording. That makes new phones pretty much useless for me. I always record calls, so that I can go back to them if I forget something or that nobody can claim they said something when they didn't (most recently insurance salesperson told me I will have option X if I take their insurance and they once I bought it, there was no such option. Once I pulled the "I have recorded your salesman lying to me", I got a prompt refund and apologies).

[joecool1029]

I got around this limitation by using LineageOS. Unfortunately, I'm forced to compile my own builds with call recording enabled for the US because there's no way to tell which state you're in through MNC-MCC numbers and states like California and Pennsylvania have lame two-party consent laws for recording calls[1][2]. My state is single party consent. Just super lame that all my featurephones from the mid-2000's could record without modification.

[1] https://en.wikipedia.org/wiki/Telephone_call_recording_laws#...

[2] File to edit: https://github.com/LineageOS/android_packages_apps_Dialer/bl...

[causality0]

I'm surprised and disappointed LineageOS disables it as well. Do they block apps with the word "torrent" in them as well?

[vorpalhex]

One would think a stern warning dialog would be sufficient...

[dredmorbius]

"This call may be recorded..."

[tyingq]

I assume you're up on all the various local laws on recording conversations, so this is for others, not you. Look into it before doing this.

[varispeed]

Ok but then why don't they disable the camera and a microphone when you record videos? You can hide the phone in a way that the person you talk to won't see you are recording it. I don't accept this explanation.

[tyingq]

Yes, laws overlap. The ones I'm talking about are generally about "intercepting communications" i.e., "recording conversations". In general, the US requires one-party consent, but there are 15 states that require two-party consent.

[varispeed]

So you can put your phone on recording e.g. in a restaurant "intercepting communications", but when someone calls you it's a no-no. Regardless, in my country recording is perfectly legal and yet Google has disabled it. If this is the law, then don't you think they should either follow it or not? I am not sure how you can only partially follow the law.

[sxiin]

Not against the law in Finland at least and thus seems unfair that rooting is needed to do this.

[fencepost]

You may be better off with a VoIP service and a softphone client, though I don't think any are as smooth as the phone native performance

[wtracy]

This is more a limitation of smartphone hardware than of Android. In most phones, calls are entirely handled by the baseband processor, and the ARM chip never sees any of the audio data.

Android doesn't expose it because the hardware doesn't expose it to the OS in the first place.

[varispeed]

I am not sure if that is true. I am running Samsung S9 with an early Android version and call recording works just fine. The Samsung released an update that disables call recording altogether (and does not allow you to turn off updates, so I've been postponing the OS update for almost two years now every day or so).

[p_l]

DISCLAIMER: It's been some time since I used to read release notes for every new api level

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).

[CivBase]

Ironically, the biggest concern I have with "security" on my Android phone is Google itself. Their overzealous collection of private data makes them a constant liability which I have practically no control over other than to abandon the Android platform altogether. I've ditched Google for almost everything else, but Android is one of the few things which I don't have a reasonable alternative for.

[AsyncAwait]

That's why I decided to get a PinePhone this year.

[pjmlp]

Android was always about Java (now Kotlin).

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.

[bosswipe]

But Java has interfaces for interacting with the host OS, for example you can create a file by writing `new File("myfile").createNewFile()` which makes a Linux call under the hood. Android 11 breaks that File API.

[pjmlp]

The same API on Windows does a Windows call under the hood, on IBM I does a TIMI call under the hood and on PTC bare metal it does the work itself.

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.

[stuaxo]

It's a shame as it you can make much more powerful apps with a native API.

[pjmlp]

On modern Android Java is native both ways.

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.

[badsectoracula]

> They always claim it's in the name of security

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.

[Ballas]

I heard somebody mispronounce the color fuchsia as fucks-ya. Seems apt in this case?

[yorwba]

The color fuchsia is named after the plant which is names after the German botanist Leonhart Fuchs, whose surname means "fox" and is pronounced roughly "fooks". I strongly suspect that the usual English pronunciation is the result of taboo avoidance. (If it were a regular sound change, you'd expect "axial" to be pronounced "ashal" as well.)

[Valkhyr]

This.

[donio]

The workaround won't help with self-installed executables though, right? Like when I cross-compile something on my dekstop and copy the executable to run under Termux?

[kbenson]

It seems like maybe as long as you package your executable into a DEB it can convert it into an APK? That shouldn't be too hard. It's probably possible for them to release a script that does it automatically depending on what information is preserved from the DEB in the APK with regard to types of files and how complex the thing you want to install is.

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).

[donio]

Yeah I guess that would work as a last resort but it's a pretty big hoop to jump through compared to just scp-ing the binary over. I guess I will stick with SDK 28 builds as long as I possibly can and start looking at alternatives for the longer term.

[saagarjha]

This is annoying but not actually a big deal; it is easy to work around this with a custom dynamic linker.

[swiley]

If you want to do something other than Instagram then don't buy devices that run "mobile" OSes.

[saagarjha]

It's easy to say that, but the competition isn't all that great so your comment isn't really adding much.

[swiley]

This is the whole "linux desktop isn't there yet" thing but with phones now.

It's not shiny but it does work. Continuing to use abusive software is a disservice to yourself and everyone around you.

[Valkhyr]

It all depends on your personal definitions of 'shiny' and 'work' I suppose. Current GNU/Linux phones unfortunately don’t even clear the ‘work’ threshold for me, and are far from it.

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).

[saagarjha]

Linux on the desktop is eminently usable, and many people do use it daily to get work done. I have yet to see someone make something usable for mobile.

[pigeons]

Maemo

[higerordermap]

It doesn't work for most people who need to use

* 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.

[snazz]

MMS doesn't work on any FOSS non-Android Linux phone I'm aware of, so they definitely do not work for a significant percentage of the population even for basic group text messages.

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.

[OJFord]

MMS? Seriously, that's your bar?

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.

[snazz]

No, that's just a technology that I consider "basic"—and one which most Americans use at least a little, even if the experience is terrible. And it does work for most people, even if it compresses images to oblivion and is slow to send messages.

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.

[lxgr]

SMS and MMS are much more popular in the US than in the rest of the world in my experience.

They are, to my understanding, the default way of sharing pictures and group messages between iOS and Android there.

[swiley]

On the Linux phone I have (pinephone) with the carrier I have (At&t) there is a script that can pull and send mms messages. There's work to get this integrated into libpurple sms so it you can use it from a shiny GTK3 app just like sms.

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.

[wtracy]

What is a handheld device that can make phone calls that you recommend instead?

[pxeboot]

There are several Linux phone projects being worked on right now. Not quite ready for the average user, but the PinePhone [1] is more than capable of making calls right now and is very affordable.

[1] https://www.pine64.org/pinephone/

[abawany]

I was miserable with my PinePhone until I found out about https://github.com/dreemurrs-embedded/Pine64-Arch - this is an Arch-based distro that works very well, ime. Previous attempts results in glacial response times, sub-day idle battery drain, broken software updates, and overheating.

[OJFord]

Doesn't it run Manjaro by default? (Which is also 'Arch-based'.)

[abawany]

Mine was the UBPorts edition but I believe the latest shipped phone is Manjaro based. I was planning to try that as well at some point but the current version I have makes me happy enough to not want to experiment anymore :) . Edit0: s/release/shipped phone/ .

[skykooler]

I've been quite happy with a F(x)Tec Pro¹ running Sailfish OS. It's a full Linux environment, and it's the best hardware keyboard I've used on a phone since the Nokia N900.

https://www.fxtec.com/pro1