We can argue about Android being a horrible OS for all sorts of reasons but that's a separate discussion.
> The Termux app avoided that by using a targetSdkVersion of Android 9, declaring that it was not compatible with the Android 10 requirements.
Android level 9 is from Android 2 Gingerbread (2010!!). https://apilevels.com/
For now it's not a huge barrier to Termux running. We can go run Android 2 stuff today, & maybe Android will forever be backwards compatible.
It does mean that Termux can't build a top or use any new Android features. Termux is glued to a truly ancient version of Android, because Android became inhospitable to basic Linux userland use cases. Seems its mostly about being unable to run downloaded code, which feels admittedly like very much "just a technicality", but boy oh boy has that technicality kept Android from expanding outside of its own bespoke userland.
> Android level 9 is from Android 2 Gingerbread (2010!!). https://apilevels.com/
Wait, no, Termux is not stuck at Gingerbread, it's stuck at Android 9 (Pie).
Agree with the rest though. Android is a sinking ship, not only the Termux issue, but the increasing number of basic apps and features that are proprietary and not part of AOSP. I hope we'll be able to be caught by Linux Mobile or something like this in time.
The AI age where the AI needs to be able to peak into all the apps will hopefully create a new API / MCP age, new machine-to-machine work. I'm not sure how much of what Google is doing today is proprietary, adding hooks into all their apps and creating some means for Gemini to access that all, and how much is paved road & available for others. Very curious to know more.
You can run applications running different target levels side by side though
> desktop Linux where even a program from the mid-1990s will run unmodified in the latest version of the OS
mhm... I wish but that's not so true for Linux. Your old program will likely be missing some dynamic library or be incompatible with your current libc. Desktop Linux userspace is awfully unstable, compatibility is broken left and right, basically no one cares except the Linux kernel itself. There's a reason people jokingly say that win32, through wine, is the most stable Linux API. If you still have the source code of your program (and the linux ecosystem is full of free software so that's likely), you can always recompile but you'll probably need to edit the code so it's compatible with the current versions of libraries).
I've heard macOS is not great at this neither.
No, this only a problem with Termux's approach of trying to put all apps into a single app. One Linux app should correspond to one Android app. This also makes it so that permissions you grant to the app is not to all of termux, but to a specific app.
That's not exactly what it does, it dynamically downloads the programs using apt-get.
I get the security benefits of preventing the execution of data stuff, but building one Android app for each binary is difficult to work with.
And then runs them as the Termux app. I didn't mean to imply that it put all of the apps into itself at build time.
>Android app for each binary is difficult to work with.
You could group multiple binaries that belong to a single conceptual app into a single android app. What do you think would make it difficult to work with? I think most of it could be automated away.
Not sure it would fly with Google's Play Store policies.
to your parent:
> And then runs them as the Termux app. I didn't mean to imply that it put all of the apps into itself at build time.
ok, got you
Please give it a try and if you find it useful, donate.
The Linux kernel has its own merits outside standard Linux userspace.
I agree, saying that the fact standard Linux distros and Android share the same kernel has no single meaningful implication really undervalues the Linux kernel.
I also agree that it's important to keep in mind the two OSes are mostly incompatible.
The two OSes sharing the kernel have practical implications, including (theoretically) seeing improvements coming from Android dev in the kernel that can benefit standard linux distros, and things like Termux or Waydroid.
> So
I reject the link here.
> when somebody says "Linux reaches X market share", are they talking about the kernel?
Likely not.
> Why does it even matter how much the kernel is used?
Why not? Depends what's your concern.
> Would you count WSL?
Depends what you want to evaluate.
This is exactly my question. You said the discussion's about the kernel. Why do you want to evaluate its usage? Which conclusions are you going to draw?
Because when talking about the OS, you can conclude that Windows and MacOS start falling behind the free software.
I never implied this. This subthread is about countering your affirmation that Android being based on the linux kernel has no single meaningful implication. It's not anymore about evaluating usage and counting stuff.
This all started with a commenter writing "Android systems don't even run the linux kernel in any real sense", which is wrong, or at least highly misleading and confusing (I do agree with this commenter about the fact that we are talking about forks that don't upstream their shit, which does have severe implications). You could say that Android systems usually don't run mainline Linux kernel.
> you can conclude that Windows and MacOS start falling behind the free software.
I wish :-) And I wouldn't generally include Android in the free software family, few people run Replicant or some Android flavor without the Google services, let alone without proprietary blobs. (I would count blob-free Android)
... Because they are a different OS.
> You’re keeping a discussion on technical reasoning for why Android and Desktop Linux are separated in a list like that
Mind you, my motivation to have them separated aren't that technical. Actually, I'd be more interested in the philosophical / social aspects of the question.
That doesn't mean the technical aspects aren't interesting and this subthread is technical, and I've been snipped by the technical inaccuracies present there.
In a way, the philosophical discussion also has less risk of being clouded by technical inaccuracies too, and more chance of succeeding in the technicalities are sorted out, especially in presence of people who know the technical details.
You are free to spark a nontechnical discussion in which you motivate why, technical details aside, we should be interested in having the two separated. Please do!
Actually, I did this a bit there: https://news.ycombinator.com/item?id=44580682#44583693
What do you even count as "an OS"? Linux + gnu userland + Gnome? Or is it KDE? Embedded Linux? Does ChromeOS count? LG's WebOS?
Can I install LibreOffice on Android? Gnome, KDE, Xfce? Which percentage of packages in the Debian repos can I use on Android?
There is also a major family of OSes building on the kernel + gnu userspace, which you probably call "desktop linux".
In my house there are dozens of devices running linux the kernel: routers, a tv set, washing machines, NAS, printers, etc. Some have the full gnu posix-like stack, others are very barebones.
Then, there's is a bunch of android devices running the kernel as well.
What's wrong with all of these? At what point should i draw a line?
This is different from embedded Linux or Linux on a server. And this is different from Linux-the-kernel (which runs on Android).
All of that is just too nebulous. Linux is something that runs the kernel, that's about it.
I mean, I've been using linux for all of my life, servers, at home, for work, embedded dev, corporate environment, as a manager and as a dev, etc.
What I see is that linux as already everywhere. Desktop space is the only OS market where non-linux OSes are in the majority, and maybe this is why people are so excited about these pointless numbers.
> maybe this is why people are so excited about these pointless numbers.
I'd be excited by numbers showing an increase free software use, including the OS, first and foremost.
For what I personally care, I'd be happy to drop the Linux kernel requirement and extend the scope to Desktop BSDs and other open source desktop OS as well. People being trapped in closed OSes that happen to be based on a Linux kernel is of limited comfort anyway, actually.
What if that same VM also is running nginx and serving up web content?
What if I have a pc with a keyboard and monitor sitting literally on my desktop, and it's running linux + gnu but no graphical environment, and I use it for coding (it has music playing when I do this, and i sometime check email or github issues, etc via cli) - yes I've done this, even recently to reduce distractions... some days GUIs are bad for my adhd. Is that a desktop linux? If not, why? What's different about this than doing basically the same thing, but also having a browser open when it's surrounded by a GUI?
* Embedded Linux is what you expect to see on a "small" device that usually doesn't have a graphical environment (it may have a small screen showing a temperature).
* A Linux server is what you expect to see in racks, serving stuff over the Internet. A homeserver could be that, too.
* Linux on mobile is what you would put on your phone.
* Desktop Linux is what you would put on your working computer, the one you interact with "physically".
Of course, you can run a server on your personal laptop, and you could run a "Desktop" graphical environment on a mobile phone. But that's beside the point. And of course, you can work on a Linux without a graphical environment.