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

51–60 of 100 posts

Re: NewPipe on Linux, Using Android_translation_layer

#51

Post by mixmastamyk »

EffrafaxOfWug wrote: post #23
mixmastamyk wrote: post #18

Earlier quoted context omitted.

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.

Thanks, that fixed the resolution issue! I also had to give it access to the dbus system socket and wayland for it to work. Wasn't sure how to do that but the flatseal app made it easy.

Re: NewPipe on Linux, Using Android_translation_layer

#52

Post by yjftsjthsd-h »

deaddodo wrote: post #50
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 ?…

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

> I'm still waiting for the day Linux offers something similar.

Waiting? Waydroid is several years old at this point, and you've always been able to run Android in a VM via either Google's official device emulator in the SDK or just running https://www.android-x86.org/ et al. in whatever hypervisor you prefer.

Re: NewPipe on Linux, Using Android_translation_layer

#53

Post by ac29 »

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…

It is upstream and Arch gives directions for enabling it in the standard kernel: https://wiki.archlinux.org/title/Waydroid#Building_a_kernel

Re: NewPipe on Linux, Using Android_translation_layer

#54

Post by mappu »

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…

It was moved from linux-staging to proper Linux in 2014 [1], and it's included with Debian oldoldstable, oldstable, and stable as well as Ubuntu linux-image packages, as a module binder_linux.ko; just need to modprobe binder.

1. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

2. https://packages.debian.org/search?suite=buster&arch=any&mod...

Re: NewPipe on Linux, Using Android_translation_layer

#55

Post by yjftsjthsd-h »

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)

> Can I ask why?

I dislike the way flatpak is effectively a second distro on top of whatever else I'm running; it eats a rather lot of additional disk space (and network bandwidth), requires that I run updates for it in addition to everything else, and I'm not sold on its security patching story (last I looked, it strongly favored everyone effectively vendoring most dependencies and I don't trust them to keep up with patches like my actual distro).

To be fair, there's also a list of reasons I do like it, just... both pros and cons.

> It was tiring getting bug reports that were only reproducible on certain drivers and setups

I'll give you userspace, but drivers should be like the one thing that flatpak doesn't help with? It's the same kernel, not a VM.

Re: NewPipe on Linux, Using Android_translation_layer

#56

Post by pmontra »

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)

I have no idea if all flatpack apps update their own vulnerabilities once they are discovered. The distribution usually does it. Then I hate the idea of having boundaries between apps and imperfect integration with the desktop environment. Furthermore I don't really need any app distributed as flatpack so far, so I don't care. When I see one I only miss giving it a try but I don't miss using it to do my daily job. I could even said that flatpack is a good thing for me because it encapsulates all the possible distractions and makes them unreachable.

Anyway, I'd rather use flatpack than snap. I left Ubuntu for Debian because of it. I hope it goes the way of the other Canonical's unsuccessful attempts at building their own proprietary system and moat.

Re: NewPipe on Linux, Using Android_translation_layer

#58

Post by surajrmal »

deaddodo wrote: post #50
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 ?…

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

Google launched the play store on Windows without wsa. I assume that's a big reason it collapsed.

Re: NewPipe on Linux, Using Android_translation_layer

#59

Post by gbraad »

I have finally been able to install it and have to say I am really impressed how well this works. Sure, you can not really 'fullscreen'? There are some glitches; margins. But mostly it just works. It is so much more efficient than starting up Waydroid... I am even considering trying this with some of my other go-to applications.

Note; FreeTube is also a good client. Though at three times the size due to Electron, I like NewPipe more. It feels way more snappy to use.

Re: NewPipe on Linux, Using Android_translation_layer

#60

Post by sigh_again »

phh wrote: post #38
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 ?…

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…

So, as I said, hacks on top of hacks on top of hacks :D If you're going to shim and reimplement, piece by piece some APIs like Binder... Just use Binder, that is already upstreamed in the kernel for so long.
Post reply on HN