EDIT to add: I also think packaging up an application plus the compatibility layer using flatpak[0] is a really nice idea; it lets you 1. make those apps available in a way that nearly appears native, 2. lets you get users/testers on your compat layer easily, while 3. scoping it to a single app at a time to make it easier to do things like "well we've got this one app working, but how do we tell people that without them expecting other things to work that aren't implemented yet?". Excellent symbiosis:)
[0] Strictly speaking there shouldn't be anything requiring flatpak here... I think there's no technical blocker preventing you making a debian package for the ATL and another for NewPipe and sticking them in a repo/PPA that people could add. But I do somewhat feel that flatpak lends itself to this usecase.
Trying to reimplement Android without Binder is a doomed plan. Everything about Android is so intrinsically linked to having Binder available that you're just going to end up piling hacks on hacks to have anything working. At this point, an x86 Android image will be better and more reliable. Somewhat just as fast.
Services ? Binder. Intents (even internal ones) ? Binder. Play Services / microG which 90% of apps use ? Binder. Permissions ? Binder.
I disagree. Apps barely use Binder directly, but mostly call framework jar (which yes will do binder, but since they are reimplementing framework jar that's fine). Intents and permissions can be implemented without binder as the API is quite semantic.
It may happen that the app uses Binder for same-app IPC, but since app does ser-des itself, you can easily replace Android.os.binder by whatever IPC you want,
The only "real" issue I can see , and you're right there, is Play Services. I think that handling that case specifically later (once floss apps/apps that don't require play services work properly), is not too horrific (it basically needs to compile the aidl into not calling binder, but redirecting it to a custom lib)
For most of Wine's life it was sufficient to implement the system library ABI, but recent developments mean they also have to trap the (unstable) syscall ABI with ptrace. You could mimic Binder in userspace the same way, without the kernel module. But even that's not a problem since Binder is upstream and enabled by default in many distro kernels now.
> Games avoiding the Windows API and performing system calls directly is an increasingly common occurrence by modern Windows games, seemingly in the name of Digital Rights Management schemes and similar protected modes.
Yuck. Windows system call numbers are not contractual. At all. Microsoft should try harder to kill any code outside ntdll.dll that makes a system call. It's obnoxious for a developer to deliberately use unstable interfaces and then demand indefinite compatibility.
No, merely using the standard Android emulator, as well as the x86_64 images that have been available for a while (or the ARM64 ones if you're on an M1 and others). With hardware acceleration properly setup, it's a nice experience. https://developer.android.com/studio/run/emulator-commandlin...
It does tend to be very unhappy when the system gets under load though, and might be sluggish if you're running a dozen IDEs on the side.
(Which, as comment under says, is technically a VM. But QEMU gets a pass at pretending not to be a VM and rather just black wizardry that makes bytes happy)
I have been hoping for compatibility layer + application flatpaks for a while so it’s nice to see someone doing it. My dream is to have a bunch of flatpaks for the Microsoft office suite
A few years ago we stopped distributing on Linux outside of Flatpak. It was tiring getting bug reports that were only reproducible on certain drivers and setups, not to mention the weekly "how do I install this on <new distro here>".
We've seen people complain about the extra space it takes on disk, but after deduplication and compression the tradeoff to have Linux apps "just work" is worth it (imo)
Not someone you asked, but I personally tend to avoid it because it makes my system less transparent to me.
Isolated self contained containers are cool for enterprise setting with huge fleets of machines, frequent updates, etc. But it's not optimal for desktop Linux atm because no one secured any of desktop APIs and there are no easy way to inspec WTF each container is doing and why. Is it ships outdated deps? Is there crypto miner in or its just random hung process eating 100% of one cpu core.
Basically each app in self contained container have its own universe and you will never figure out what exactly its doing. So its turn your system into a black box.
As maintainer of OSS software and game developer I totally get the appeal, but as user I love Linux exactly because it's give me more transparency and I dont want to lose it.
If you have a device running postmarketOS or Alpine Linux you can try this out yourself with other Android apps. Just "sudo apk add android-translation-layer" and then run
$ android-translation-layer some-app.apk
I tried a few (F-Droid, Spotify, Megalodon) but they all failed with various issues, looks like there's a lot of API surface still not covered. Hopefully a lot of it is fairly easy to add now that the foundational work has been done!
Very cool stuff! I wonder if you can switch out the newpipe app for the Tubular (https://github.com/polymorphicshade/Tubular) fork which has SponsorBlock and ReturnYoutubeDislike built into it.
> Never heard of Freetube, but it looks pretty snazzy.
I've used it for several months now and am very happy with it.
I'ts a Electron app, however, so don't expect it to be small; I hope they will consider
rebuilding it using Tauri, which would reduce its size drastically.
I know a lot of people hate on the recommendations homepage on YouTube, but I discover a lot of content I like watching there. However, I can't watch all of it and what to save what I see there and otherwise find and search for in a playlist, but the watch later playlist is not user friendly. Does Freetube improve playlist management too? That would be a big plus.
I have been enjoying the new version that just came out yesterday, they implemented a new video player and IMHO the user experience is much improved, if the UI glitches you mentioned were related to the player, maybe you could give it a try.
I have used FreeTube on wayland now for a long time without any issues. Electron still uses x11 as the default on wayland so you need to enable the wayland mode manually. You can easily do that by setting the ELECTRON_OZONE_PLATFORM_HINT=auto
environment variable.
They fixed a few bugs already I think. But it still looks like crap (lower resolution?) on my tablet and I have to force the onscreen keyboard on manually (normally comes on by itself).
Oddly enough the video itself looks fine when playing, but not the browser interface.
On the desktop, youtube in the browser is tolerable with ublock origin, so I use it in preference to youtube because of the ability to show search results most recent first. Newpipe (maybe due to technical obstacles, idk) doesn't do that and it makes things harder.
I feel like the interesting part is mostly https://gitlab.com/android_translation_layer/android_transla... which is probably an alternative to waydroid, but maybe more like WINE so it doesn't need the binder kernel module?
EDIT to add: I also think packaging up an application plus the compatibility layer using flatpak[0] is a really nice idea; it lets you 1. make those apps available in a way that nearly appears native, 2. lets you get users/testers on your compat layer easily, while 3. scoping it to a single app at a time to make it easier to do things like "well we've got this one app working, but how do we tell people that without them expecting other things to work that aren't implemented yet?". Excellent symbiosis:)
[0] Strictly speaking there shouldn't be anything requiring flatpak here... I think there's no technical blocker preventing you making a debian package for the ATL and another for NewPipe and sticking them in a repo/PPA that people could add. But I do somewhat feel that flatpak lends itself to this usecase.
Trying to reimplement Android without Binder is a doomed plan. Everything about Android is so intrinsically linked to having Binder available that you're just going to end up piling hacks on hacks to have anything working. At this point, an x86 Android image will be better and more reliable. Somewhat just as fast.
Services ? Binder. Intents (even internal ones) ? Binder. Play Services / microG which 90% of apps use ? Binder. Permissions ? Binder.
I disagree. Apps barely use Binder directly, but mostly call framework jar (which yes will do binder, but since they are reimplementing framework jar that's fine). Intents and permissions can be implemented without binder as the API is quite semantic. It may happen that the app uses Binder for same-app IPC, but since app does ser-des itself, you can easily replace Android.os.binder by whatever IPC you want, The only "real" issue I can see , and you're right there, is Play Services. I think that handling that case specifically later (once floss apps/apps that don't require play services work properly), is not too horrific (it basically needs to compile the aidl into not calling binder, but redirecting it to a custom lib)
For most of Wine's life it was sufficient to implement the system library ABI, but recent developments mean they also have to trap the (unstable) syscall ABI with ptrace. You could mimic Binder in userspace the same way, without the kernel module. But even that's not a problem since Binder is upstream and enabled by default in many distro kernels now.
When did WINE start doing this? I always love a good read on ptrace hacks.
https://github.com/wine-staging/wine-staging/commit/595f2f98...
A new strategy is used that is much faster: https://www.phoronix.com/news/Syscall-User-Dispatch-Queued
> Games avoiding the Windows API and performing system calls directly is an increasingly common occurrence by modern Windows games, seemingly in the name of Digital Rights Management schemes and similar protected modes.
Yuck. Windows system call numbers are not contractual. At all. Microsoft should try harder to kill any code outside ntdll.dll that makes a system call. It's obnoxious for a developer to deliberately use unstable interfaces and then demand indefinite compatibility.
> At this point, an x86 Android image will be better and more reliable. Somewhat just as fast.
You mean a full VM?
No, merely using the standard Android emulator, as well as the x86_64 images that have been available for a while (or the ARM64 ones if you're on an M1 and others). With hardware acceleration properly setup, it's a nice experience. https://developer.android.com/studio/run/emulator-commandlin...
It does tend to be very unhappy when the system gets under load though, and might be sluggish if you're running a dozen IDEs on the side.
(Which, as comment under says, is technically a VM. But QEMU gets a pass at pretending not to be a VM and rather just black wizardry that makes bytes happy)
The Android Emulator is a full VM under the hood. Waydroid is a lighter-weight alternative that uses the Binder implementation in the Linux kernel.
Plus, Linux itself should adopt binder. It's already upstream and actually pretty good.
Binder is upstreamed into Linux.
But I feel I don't know much about binder/kernel/IPC: maybe I overestimate what that means?
Binder is in mainline Linux, but I was under the impression that most distros aren't building it by default?
I have been hoping for compatibility layer + application flatpaks for a while so it’s nice to see someone doing it. My dream is to have a bunch of flatpaks for the Microsoft office suite
I don't use flatpak, snap or appimage so it's good that it doesn't need flatpak or similar.
Can I ask why?
A few years ago we stopped distributing on Linux outside of Flatpak. It was tiring getting bug reports that were only reproducible on certain drivers and setups, not to mention the weekly "how do I install this on <new distro here>".
We've seen people complain about the extra space it takes on disk, but after deduplication and compression the tradeoff to have Linux apps "just work" is worth it (imo)
Not someone you asked, but I personally tend to avoid it because it makes my system less transparent to me.
Isolated self contained containers are cool for enterprise setting with huge fleets of machines, frequent updates, etc. But it's not optimal for desktop Linux atm because no one secured any of desktop APIs and there are no easy way to inspec WTF each container is doing and why. Is it ships outdated deps? Is there crypto miner in or its just random hung process eating 100% of one cpu core.
Basically each app in self contained container have its own universe and you will never figure out what exactly its doing. So its turn your system into a black box.
As maintainer of OSS software and game developer I totally get the appeal, but as user I love Linux exactly because it's give me more transparency and I dont want to lose it.
Definitely. I'd never heard of this one before; I'd love to read a full comparison between the two.
It's conceptually similar to wine, but rather a reimplementation of the reference Android, which is AOSP.
See https://gitlab.com/android_translation_layer/android_transla...
Better link: https://gitlab.com/android_translation_layer/android_transla...
If you have a device running postmarketOS or Alpine Linux you can try this out yourself with other Android apps. Just "sudo apk add android-translation-layer" and then run
$ android-translation-layer some-app.apk
I tried a few (F-Droid, Spotify, Megalodon) but they all failed with various issues, looks like there's a lot of API surface still not covered. Hopefully a lot of it is fairly easy to add now that the foundational work has been done!
I'm going to try and get android_translation_layer building on Arch and then we can have a third distro to add to the list!
Very cool stuff! I wonder if you can switch out the newpipe app for the Tubular (https://github.com/polymorphicshade/Tubular) fork which has SponsorBlock and ReturnYoutubeDislike built into it.
https://gitlab.com/android_translation_layer/android_transla...
https://gitlab.com/android_translation_layer/android_transla...
I wonder how well this approach works over anbox/waydroid's approach.
Why would one want NewPipe on desktop when there's https://freetubeapp.io/
Perhaps because one is accustomed to the NewPipe experience and would prefer consistency across devices?
Never heard of Freetube, but it looks pretty snazzy.
> Never heard of Freetube, but it looks pretty snazzy.
I've used it for several months now and am very happy with it. I'ts a Electron app, however, so don't expect it to be small; I hope they will consider rebuilding it using Tauri, which would reduce its size drastically.
I know a lot of people hate on the recommendations homepage on YouTube, but I discover a lot of content I like watching there. However, I can't watch all of it and what to save what I see there and otherwise find and search for in a playlist, but the watch later playlist is not user friendly. Does Freetube improve playlist management too? That would be a big plus.
I don't know, it makes sense that UI between desktop and mobile would be different. I use Freetube on desktop and newpipe on mobile.
Having said that, newpipe is not only a youtube client but also a soundcloud, bandcamp and a few others too.
I tried it, it didn't feel like what you get on android and had ui glitches
I have been enjoying the new version that just came out yesterday, they implemented a new video player and IMHO the user experience is much improved, if the UI glitches you mentioned were related to the player, maybe you could give it a try.
Parabolic it's far better for desktop users.
You know you could drop a recommendation without being so damn submissive of OP. Let a thousand alternative clients bloom.
Doesn’t work well on Wayland unfortunately. Don’t know if this one does but worth a shot.
I have used FreeTube on wayland now for a long time without any issues. Electron still uses x11 as the default on wayland so you need to enable the wayland mode manually. You can easily do that by setting the ELECTRON_OZONE_PLATFORM_HINT=auto environment variable.
I use Freetube on Wayland with 0 issues.
Same here.
They fixed a few bugs already I think. But it still looks like crap (lower resolution?) on my tablet and I have to force the onscreen keyboard on manually (normally comes on by itself).
Oddly enough the video itself looks fine when playing, but not the browser interface.
Freetube is terribly unoptimized. Even though it supports hw video playback, I decided to skip it as it had too much CPU overhead.
Semi related, there is a Minecraft Bedrock Launcher that ports the Minecraft for Android app to *nix.
https://flathub.org/apps/io.mrarm.mcpelauncher
Exciting. I'd love to see AppImage [0] builds of applications produced with this library.
[0] https://appimage.org/
This is amazing! Have been using Newpipe for years because of its ability to group subscribed channels into different feeds.
On the desktop, youtube in the browser is tolerable with ublock origin, so I use it in preference to youtube because of the ability to show search results most recent first. Newpipe (maybe due to technical obstacles, idk) doesn't do that and it makes things harder.
for me freetube in the arch repo works great
https://github.com/FreeTubeApp/FreeTube
I think it is in the AUR not arch official repos