Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

NewPipe on Linux, Using Android_translation_layer

flathub.org

Post reply on HN
Print view View original

41–50 of 100 posts

Re: NewPipe on Linux, Using Android_translation_layer

#41

Post by yjftsjthsd-h »

refulgentis wrote: post #40
sigh_again wrote: post #11

Earlier quoted context omitted.

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

Re: NewPipe on Linux, Using Android_translation_layer

#42

Post by irunmyownemail »

yjftsjthsd-h wrote: post #2

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 nati…

I don't use flatpak, snap or appimage so it's good that it doesn't need flatpak or similar.

Re: NewPipe on Linux, Using Android_translation_layer

#43

Post by quotemstr »

sigh_again wrote: post #11
yjftsjthsd-h wrote: post #2

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 nati…

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 ?…

Plus, Linux itself should adopt binder. It's already upstream and actually pretty good.

Re: NewPipe on Linux, Using Android_translation_layer

#44

Post by quotemstr »

lights0123 wrote: post #32
ronsor wrote: post #26

Earlier quoted context omitted.

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.

Re: NewPipe on Linux, Using Android_translation_layer

#45

Post by OsrsNeedsf2P »

irunmyownemail wrote: post #42
yjftsjthsd-h wrote: post #2

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 nati…

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

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)

Re: NewPipe on Linux, Using Android_translation_layer

#46

Post by mixmastamyk »

prmoustache wrote: post #29
BadHumans wrote: post #24

Earlier quoted context omitted.

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.

Re: NewPipe on Linux, Using Android_translation_layer

#47

Post by SXX »

OsrsNeedsf2P wrote: post #45
irunmyownemail wrote: post #42

Earlier quoted context omitted.

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

Re: NewPipe on Linux, Using Android_translation_layer

#48

Post by augusto-moura »

mappu wrote: post #21
sigh_again wrote: post #11

Earlier quoted context omitted.

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 ?…

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.

I don't think binder is upstream, nor is the default in many distros. AFAIK support is very limited as not a lot of people use it. In arch it is provided only as a community package (AUR) [1]. This was a major blocker for me when trying to install anbox or waydroid, custom compiled kernel modules is a no-no for me, not because of security issues (which could exist), but because they can break a lot of stuff and fixing kernel modules is not a stroll in the park.

[1]: https://aur.archlinux.org/packages/binder_linux-dkms

Re: NewPipe on Linux, Using Android_translation_layer

#49

Post by yjftsjthsd-h »

augusto-moura wrote: post #48
mappu wrote: post #21

Earlier quoted context omitted.

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.

I don't think binder is upstream, nor is the default in many distros. AFAIK support is very limited as not a lot of people use it. In arch it is provided only as a community package (AUR) [1]. This was a major blocker for me when trying to install anbox or waydroid, custom compiled kernel modules is a no-no for me, not because of security issues (which could exist), but because they can break a lot of stuff and fixin…

I'm reasonably confident that it is upstream: https://github.com/torvalds/linux/blob/master/drivers/androi... looks like the most obvious bit, though there are other pieces. (And now I'm curious why waydroid is maintaining their own dkms code separate from that; perhaps it's to better target a range of kernel versions?) I will agree that it's not generally actually built/used by distros.

Re: NewPipe on Linux, Using Android_translation_layer

#50

Post by deaddodo »

sigh_again wrote: post #11
yjftsjthsd-h wrote: post #2

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 nati…

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 ?…

> At this point, an x86 Android image will be better and more reliable. Somewhat just as fast.

I'm pretty sure the overhead for something like Windows Subsystem Android is a few percentage points max, assuming the video card supports the proper OpenGL subsystem (so doesn't require software fallbacks). In fact, given that most x86 laptop CPUs and GPUs offer much more performance than most phone ARM chips, it's basically a moot point. The big problem is finding packages built universally or specifically for x86 (not sure what the status is for WSA on Windows ARM, but that could be an option too).

I'm still waiting for the day Linux offers something similar. Or FreeBSD does something similar to their Linux ABI compatibility.

Edit: looks like WSA is being ended in early 2025:

https://learn.microsoft.com/en-us/windows/android/wsa/

Due to not being able to integrate a store and make revenuue:

https://www.windowscentral.com/software-apps/windows-11/here...

What a shame.

Post reply on HN