Anybody know if the actual terminal supports pixel graphics via Sixels, or better Kitty Graphics Protocol?
Anyway that's not really what this is about.
https://www.collabora.com/news-and-blog/blog/2025/01/15/the-...
> GFX virtualization aims at providing support for hardware accelerated 3D graphics in virtual machines. Unlike GPU-passthrough, with GFX virtualization the host and all VM guests can access the host GPU simultaneously. Vulkan and OpenGL are supported by virglrenderer using various approaches.. vDRM is a much thinner layer.. able to achieve native GPU performance, where VirGL and Venus may struggle to overcome expensive host/guest synchronizations..at the beginning of 2025, vDRM is partially supported by crosvm.
Hopefully Google's phone-tablet-laptop-desktop convergence of Android, ChromeOS and developer-targeted Debian Linux will motivate Apple to restore iPadOS 16.2 (2022!) virtualization support, https://github.com/utmapp/UTM/discussions/5748.
(The Flip is Exynos while the Fold is Qualcomm.)
[0] - Meaning the OpenGL ES, Vulkan, OpenSL, OpenMAX, C and C++ that also exist in GNU/Linux.
We've already seen the whole "corporate sponsor courts game publisher" thing with Eidos and Capcom at Apple. Let's just say that Apple's commitment to native experiences didn't put them in contention with Sony or Nintendo in the way Valve did.
"Nintendo Shares Have Breakout Year as Switch 2 Sales Smash Records"
https://www.asktraders.com/analysis/nintendo-shares-have-bre...
Consumers really should pay more attention to those YouTube influencers, buying the wrong stuff. /s
Apple is doing just fine across iOS, iPadOS and TV OS, which apparently people like to ignore when discussing numbers and monetary figures in gaming profits.
Oh! The Mac! Whenever you let publishers compete with software storefronts of their own, Apple is chronically incapable of making money for some reason. You know, like how League of Legends and Steam and World of Warcraft and all support the Mac but conspicuously don't show up on the macOS app store or get ported to the mobile platforms that could clearly support them. Or how Photoshop and Pro Tools and Premiere all support the Mac, but just refuse to put their professional software on the App Store or iPad! What's up with that?
The fact that those storefronts are entirely captive audiences might be it. When you add macOS to the lineup, it becomes the punchline to a tortuously protracted joke.
"- Mobile games generated $81 billion revenue in 2023 across both platforms
- iOS was responsible for $47.7 billion of that revenue, Google Play generated $33.3 billion
- Mobile was responsible for 49% of total game revenues, close to PC and console totals combined"
https://www.businessofapps.com/data/mobile-games-revenue/
Laugh at will, we don't want sad people.
Instead, serious economists turn to markets that are representative of Apple's ability to compete, for example, the macOS App Store. When Apple has to compete, how much market cap are they actually earning from the App Store? We have the numbers, you just know they aren't flattering.
(SELinux has run in enforcing mode on Android devices since Android 4.4, which was released in 2013. But Android in ChromeOS only runs SELinux in the guest VM FWIU)
SELinux in a guest [VM or container] should restrict processes in the guest from interfering with other processes and resources in the guest.
IMHO, Nested UIDs like uid1.subuid1.subuid2 would be better for rootless containers than root-writeable /etc/subuids.
-Z, --context: print any security context of each file
Of course, UI adjustments would be the next step!
Also, GNUs it's the only working usenet client for Android too. Which is ironic, because k9mail/Thunderbird and friends both support NNTP in the biggy build in the desktop...
And NNTP support on Android for MUA developers should be a piece of cake...
On two different Pixel phones (6a & 8a) I had a terrible experience:
- Very slow
- Crash all the time
- The app need to be reinitialised almost every day
But I have heard some people have no complain.
Also, since I couldn't really keep it alive long enough: what as the prospects in terms of battery usage? will it be realistic to have it running all time in the background?
Nice idea, nowhere near ready for anything but playing.
That sounds more like it's being killed for RAM reasons rather than "crashing"
I'm sure the Android one is much more aggressive, but Linux's OOM killer isn't too different is it?
Apps are meant to be started and destroyed dynamically when the user does something else, their phone is idle for a long time, battery life is low, etc. If something is in the background it's fair game to kill.
It's just an issue that plagued the last 15 years of attempts at getting Linux running in VMs/containers/etc on Android, and that's the reason it's an issue.
Developers might be able to work around the limitation by building dynamic suspending and restoring of VM state into their Linux launcher and try to make it play nice with Android.
I suppose normal GNU/Linux might have this issue as well if you run an OS with lots of background services that randomly consume large amounts of RAM or if your desktop environment does. I don't so outside of kind of insane environments like raspberry pi zeros or weird situations on servers I don't typically run into this. (and no. It's not 2010, phones are normal PCs not a weird embedded environment.)
It's the opposite.
Define what is a "normal PC" to you, then. Is it just specs?
It's the reason you can use any amd64 ISO to boot Linux on your PC, but each individual embedded device needs its own special image that is custom to that board, and often a custom Linux fork.
See also https://developer.android.com/guide/components/processes-and...
> just running regular apt-get upgrade if it has too many packages to update, or takes too long
That's really interesting! How's it handle nala[0]? I ask because it parallelizes apt. So if it crashes fast then might be a good hint that it is overloaded but if it is more successful could be a timeout?Also... I mean nala is also a much better experience than apt...
In Android's case, a Java or Kotlin written Terminal app, exposing CLI capabilities, taking advantage of Android's APIs.
Even assuming the Terminal app works great, it is still only usable for playing, unless I am able to plug a keyboard, mouse and external monitor to a phone, and I have used both DEX and Windows Continuum in the past.
I am not sure why VT100 emulation is relevant in this context. Removing it will break a lot of existing Unix/Linux terminal applications and the point of this emulator is to bring the wealth of existing applications (as well as X11/Wayland applications) to Android.
Exactly because we should stop dragging UNIX all over place, and embrace new computing models, the world already has enough UNIX clones always redoing the same stuff over and over again, as if Lion's book had been published last week.
Probably more the fact that the memory and battery management logic assumes all user apps which are not in focus can be killed aggressively, which makes the system unsuitable for any background task by design.
Now I am not very knowledge about memory management on Android but I just noticed the 8Gb of the Pixel 8a are almost all used just after reboot. So this is very different than a Linux desktop...
Expecting Android to be just another Linux distro is exactly the root cause of many Termux developers frustations.
> Pixel 8a has 8gb ram. It's not a low end number for Android phones.
I mean... linux runs fine of a Gen 1 raspberry pi... I have several machines around me that are running linux with 4GB or less. Hell, my 3D printer only has 128MB and my car has under a gig and run Linux fine. A low end phone *should* be just fine...You used to be able to run Unix fine on computers with 64MB of ram. A modern phone has more than enough memory.
For context, I use it mostly for web development. It runs a desktop environment with VNC, so I'm able to connect and run software like a browser. I don't develop on the device, but instead connect to a remote machine. Although the browser takes a few seconds to start, I didn't have any issues doing frontend development or doing web searches and reading docs, but I tend to be careful regarding the number of open tabs.
The Terminal app does crash from time to time. It can crash after 15 minutes, but I've also had it running for about 2 hours without issues. I'm not bothered by this as I just reconnect and continue where I left.
The reinstall is not needed every day. When I run the app, sometimes it says there was an unrecoverable error and suggests to reinstall. I ignore this, because it's a timing issue; the app was slow to start. Usually, if I run it again after closing the activity, it starts normally. The same VM has been running for me without a need to reinstall for a few months.
The battery usage is not too bad. I use an external display and make the phone screen black during this time. The battery gets depleted at a rate between 5% and 20% per hour, but this is only for active usage. I haven't been running it all the time in the background.
+ Doesn't have the same compatibility issues Termux has, so I can install things like bun.js and npm packages with native bindings (e.g. database connectors)
- Can't edit text selection, which makes it difficult to copy text
- Can't paste text
- Frequently restarts and loses all progress while switching apps
I can't say much about the battery because I just haven't used it enough to tell the difference. Honestly, with all these major flaws, I usually end up just using Termux.
I hope they fix these glaring flaws soon, IMO they're a lot more urgent to get devs to actually use this than GUI support.
Nitpick: also, a more distinctive name would be nice. Right now, it's basically impossible to search for solutions to Android Terminal issues
1) security. Container breakouts are much more common than VM breakouts
2) compatibility - the Android kernel is known to be heavily modified and Debian may benefit from being run on a more vanilla kernel as it does on desktop/server
https://source.android.com/docs/core/architecture/hal/archiv...
https://source.android.com/docs/core/architecture/hal
Processes are sandboxed, in which app gets its own user id, everything that Google considers not a public API gets blacklisted, via a mix of LinuxSE and seccomp.
Native executables are not allowed per se on userspace, native code outside system processes has to always be a shared object loaded into the Zygote process fork, which takes the init role on Android. There are ways to launch executables, but they are frowned upon.
https://source.android.com/docs/core/runtime/zygote
Android is quite stright in memory consumption, an application that is seen as misbehaving gets killed without remorses.
For all details, you can go from here https://source.android.com/docs/core/architecture/kernel
On native executables and such, file and objdump once I installed clang under termux to compile a simple binary tells me otherwise.
What matters is how an Android device as bought on a random shop as consumer behaves, not how one can hack around Android and AOSP.
Back when I used Waydroid, I had to use an out-of-tree module picked from the Anbox project. I have stopped using Waydroid but good to know that binderfs is a thing!
Also you're moving the goalpost with this comment a bit. My original comment says "may benefit from" being run under a "vanilla" kernel, as opposed to saying it would be completely non-functional under Android's kernel.
[1] Though I'm very much not one of the pedants who refuse to see any security value at all in container isolation. Containers isolate software access (e.g. limiting access to libraries with vulnerabilities) and network communication (writing firewall rules for a container is a lot easier than it is for an app) really well, for example. Use them! But not for this.
You can run whatever kernel you want in a VM, though.
Pixel 8/9 Pro have at least 12GB of RAM, with some models (256GB unlocked Obsidian?) having more.
The Kali thing is also just a chroot image (if rooted) that you have to VNC into, and cannot do docker and stuff.
I think they killed it way too quickly. But anyway, meh..
The S10e was the last small Samsung too :'(
Beginning to dream of a Corne keyboard + AR glasses + phone setup. There's a chance we're beginning to approach fully pocketable computing with no ergonomic compromises!
Nested virt has been available on x86 for a decade (KVM, Bromium vSentry / HP SureClick, Microsoft Defender App Guard), on Apple Silicon since M2, MacOS since M3 and iPadOS since M4 (Secure eXclave VM). On mobile, it can sidestep some business model conflicts which torpedoed Nokia, RIM, Maemo, Meego, Tizen, etc.
"Virtual Machine as a core Android Primitive" (2023), 160 comments, https://news.ycombinator.com/item?id=38538100
Do you have a good link to learn more about that?
https://www.androidauthority.com/android-15-virtual-machine-...
If they’re not quick in getting some more bang in the phone, which is more expensive than a computer, I might even switch. At that point, what’s the point of all the other Apple hardware.
Google is certainly demonstrating some good habits here. They did good work in opening up their laptop hardware. Their pixels are the most friendly devices for alternative operating systems. They added standard API access to GNSS raw data. Now it looks like they're doing GPU virtualization. They just keep breaking down barriers.
It's opengl/vulkan call interception (virgl/venus) and/or virtgpu drm native context which operates at the graphics driver level for both guest and host.
Separately, wayland memory sharing channels between guest and host need to be established. This is also done through the virtgpu pipeline.
Currently this appears to both work on Android and macOS[1]. AMDGPU also has virtgpu drm native context merged into Mesa but I believe it's still 'experimental'.
[1] <https://github.com/AsahiLinux/muvm> , <https://github.com/containers/libkrun>
It sounds to me like trying to redefine exactly what Linux is: just an app that you run on top of your proprietary OS. For a lot of people who'll be exposed to it for the first time, that's all it'll be. The mere idea of a standalone free and open source OS will be even more alien that to the previous generation.
Instead I waded into a soup of X11 vs Wayland, endless bickering about which tech stack, WM vs gui, etc. I would be curious to hear what people think linux's 'killer app' is. Not just "equivalent" but better. To your point, Linux needs a killer app, not just equivalent-app or "linux flavored" app that does the same thing, a DAW, a font editor, a GIS app, something.
If the best coffee comes from one coffee shop, naturally you go inside there to get the coffee. We are talking about an app so good it makes you want to install linux.
Those examples aren't killer apps because they could be ran in Windows/Linux through these compatibility layers. Linux's 'killer app', if it had one, would be things like better window management that doesn't get in your way, faster file I/O, being able to do more with your hardware.
xeonmc•6mo ago
piperswe•6mo ago
lawlessone•6mo ago
And with decent performance.
It's emulating windows and an x86 cpu though. Could probably run minecraft java too
https://www.reddit.com/r/Android/comments/1divvyo/samsung_ga...
anthk•6mo ago