You are talking about the OS while the person you are discussing with is speaking about the kernel.
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.
Compiling the mainline Linux kernel myself really taught me that the kernel does way more than people give it credit for. Sure, it can be debated as to whether two distributions of Linux can really be considered the same OS, but acting like the kernel is a relatively minor detail comes off to me as ignorant.
You’re keeping a discussion on technical reasoning for why Android and Desktop Linux are separated in a list like that, but the reason is not technical. It’s wholly for convenience. We want to know the performance of Desktop Linux separate from Android. Whether or not they are a different OS or not is irrelevant.
> We want to know the performance of Desktop Linux separate from 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!
So when somebody says "Linux reaches X market share", are they talking about the kernel? Why does it even matter how much the kernel is used? Would you count WSL?
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)
> Almost every Android version imposes new major restrictions when it comes to security requirements, and specifically the Android 10 version update was dramatic for Termux usage, as it disallowed executing downloaded files directly.
> The Termux app avoided that by using a targetSdkVersion of Android 9, declaring that it was not compatible with the Android 10 requirements.
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.
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.
Apologies! I originally posted Android 9 Pie (2018), but had doubt & switched to the SDK version. My mistake!!
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.
Right, Android target levels are so different in how they behave towards applications that they're practically best treated as distinct OS's to begin with. There's really no such thing as a unified Android or iOS, unlike Windows or desktop Linux where even a program from the mid-1990s will run unmodified in the latest version of the OS.
> Android target levels are so different in how they behave towards applications that they're practically best treated as distinct OS's to begin with
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).
>Termux is glued to a truly ancient version of Android, because Android became inhospitable to basic Linux userland use cases.
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.
>it dynamically downloads the programs using apt-get.
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.
The principled way of doing this (while coping with the new post-Pie restrictions) would be to build a new "updated" .apk on-device with a new /usr/bin/ equivalent, then have the user explicitly "install" it and relaunch Termux. It would work no different than any live-CD install, or for that matter any other kind of "immutable" OS.
But then, everything runs under the same Termux user app again, just with extra cumbersome steps. And I'm not sure it's possible to do this safely, you need the APK to be signed, and the only way to do this would be to share the private key. And likely to have a good chunk of the Android SDK bundled with Termux. A version that runs on Android anyway.
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.
Linux is a kernel, that's it. There is an organisation maintaining it, and also the trademark.
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?
To me, Desktop Linux is the Linux I run on my work computer: the one that has a screen, a keyboard and a mouse. It is based on Linux (obviously), the GNU userland to some extent, and then it has a graphical environment (usually based on Xorg or Wayland).
This is different from embedded Linux or Linux on a server. And this is different from Linux-the-kernel (which runs on Android).
What if I run linux + gnu + gnome over rdp on VM a server in a rack somewhere that has no screen keyboard and mouse on it? Am i using desktop linux or not?
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?
I feel like you're overthinking it. It's not that one can get a badge saying "powered by Desktop Linux". It's a rough categorisation based on the use case:
* 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.
Well, you came up with a rather vague definition. Xorg OR wayland. Gtk or qt? Which set of tools do you expect to be available?
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.
Desktop Linux is difficult to define exactly, but the idea has merits. Something that's not proprietary, and that's not incredibly closed / locked / controlled by a monopolist like Android or Chrome OS.
> 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.
Hey, I'm the author of this doc. The reason for the pattern is to make it so you always can find why a mutation occured. So combining state variables and dom changes is ok as long as that's the only place that does the mutation. If not, now you've made it harder to debug. I keep the strict separation so that I can always stick a debugger and see a stack trace of what happened.
Writing a language, even a DSL is a lot of work. It's not enough to just make a good language, there's also a whole world of tooling support that people expect nowadays.
Also ultimately it was hard to sell the idea of living in a different file format from the rest of your code. This is always a tough sell for DSLs. Even languages as good as CSS and SQL struggle with this for a lot of devs.
A JavaScript-only implementation of robot suffers a similar fate as a DSL without proper tooling, as states and actions are just some custom strings that need to be repeated, no? An implmenetation with good types would provide useful autocompletion, and I can see there was a similar conclusion and types have been implemented with generics. Haven't used it yet to confirm the behavior (at a first glance it seems like a few more strings would need to be inferred), but it would be helpful to mention this somewhere for us TypeScript folks.
This is a very good question! One of the big reasons we partnered with Turso was for their edge network, so replicas are available close to your origin server. Being able to host anywhere is something that's important to Astro, so this felt like the right balance. Turso is known for its speed and one of the main thing that attracts people to use it.
Hi Matthew. Both Cloudflare[1] and Turso[2] have apparently very similar offerings at what appears to be better pricing. What does AstroDB provide to warrant the additional cost?
First, we have just launched and are still figuring out pricing, this is a great point of feedback that we'll consider, thank you.
What differentiates Astro DB is the deep integration with the Astro framework and providing an easy path for common scenarios. Astro DB is a higher-level product than using a database service directly. For example, Astro DB handles migrations transparently for you and guides you when manual intervention is needed, just from running `astro db push`.
Astro DB also includes a local story, by default you use a local SQLite database that you can seed (using db/seed.ts) for local development. You can even use it for a purely static site, although we're still working on making SSG use-cases more seamless. For now though, this gives you a great local workflow for development that you can think easily connect to production with `astro build --remote`.
reply