Live data from Hacker News

NewPipe on Linux, Using Android_translation_layer

flathub.org

81–90 of 100 posts

Re: NewPipe on Linux, Using Android_translation_layer

#81
post #79

Mmmh, I'm using it on Android for some time now, installed as F-Droid app. Problem is, there is some friction regarding Countermeasures of YT and a new version adjusting to them. Often, I'm unable to use the alternative Client on Android for months until this is fixed. Will this be a problem on Linux too?

The problem is that F-Droid takes time to review new releases, when they're already available from other (direct) sources.

I have discovered Obtainium[1] not too long ago. Allows you to install and update apps from pretty much any source you want (e.g., directly from GitHub releases, as in NewPipe's case).

[1] https://obtainium.imranr.dev/

Re: NewPipe on Linux, Using Android_translation_layer

#82

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…

What’s wrong with binder? The problem with Waydroid is that you need to boot up a whole Android system, which is not great for app startup time.

I keep my Waydroid session running in the background, managed by a systemd user-level service. Works great, and if it increases resource usage I don't notice--this is on a converted Chromebook so pretty low specs.

Re: NewPipe on Linux, Using Android_translation_layer

#83
post #79

Mmmh, I'm using it on Android for some time now, installed as F-Droid app. Problem is, there is some friction regarding Countermeasures of YT and a new version adjusting to them. Often, I'm unable to use the alternative Client on Android for months until this is fixed. Will this be a problem on Linux too?

[deleted]

Re: NewPipe on Linux, Using Android_translation_layer

#84

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…

The project seems to be built on top of my android2gnulinux project from way back. Nice to see someone picking up the pieces and making it more functional.

https://github.com/Cloudef/android2gnulinux

Re: NewPipe on Linux, Using Android_translation_layer

#85
post #75

Earlier quoted context omitted.

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

> demand indefinite compatibility. Not infinite – long enough for the game to bring in most revenue is enough. Who cares that it stops running one or two Windows updates later for totally avoidable reasons? Definitely not the publisher. (In fact, isn't it about time for an HD remaster again?)

Microsoft cares, though, because if a game stops working when you upgrade Windows, you blame the Windows upgrade, not Microsoft. So now Microsoft has to maintain these legacy system calls even though they never signed up to do that.

Re: NewPipe on Linux, Using Android_translation_layer

#86

Earlier quoted context omitted.

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

There is now at least one public windows kernel call listed on MSDN: __fastfail

https://learn.microsoft.com/en-us/cpp/intrinsics/fastfail?vi...

Re: NewPipe on Linux, Using Android_translation_layer

#87
post #67

Earlier quoted context omitted.

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.

You're confusing shiming with rewriting. DirectX uses direct hardware access. DirectX uses direct hardware access. That doesn't mean you can't rewrite a DirectX-API implementation without direct hardware access. Likewise, Android's original implementation of MediaCodec uses binder. That doesn't mean that a reimplementation of MediaCodec API requires binder. The vast majority of Android public APIs do not assume binde…

> Most usages of android.os.Binder will be local to an app, so you can easily replace it with any IPC.

I'd be absolutely shocked if that was even a little bit true. Android's binder & AIDL generated code will absolutely do in-process passthrough to avoid the syscall for local calls, but ~nobody is bothering with AIDL unless it's to enable IPC. So that local pass-through is almost certainly rarely if ever used except on "accident" when components nominally support being passed over IPC, but in some cases aren't. An example would be Android's Surface + SurfaceTexture. Normally you're using Surface over IPC either to the display or to media codec or from camera. But if you're using SurfaceTexture, then in that rare scenario it might be local to the process.

But that's definitely a lot less common than IPC binder + AIDL.

All that said, you could almost certainly make a Binder driver shim that just uses unix domain sockets. Heck, Android itself even has one: https://cs.android.com/android/platform/superproject/main/+/...

What'd be a lot harder is handling some of the more advanced graphics & multimedia features. Android's gralloc HAL in particular is likely borderline impossible to implement on Linux as it assumes tight integration between all of the camera, media/video, GPU, and display stacks, and also largely assumes it's on unified memory.

Re: NewPipe on Linux, Using Android_translation_layer

#88

Earlier quoted context omitted.

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

Sorry, I should have rephrased that:

I'm still waiting for Linux to offer a good version of that. I currently use waydroid, and it's barely functional.

Re: NewPipe on Linux, Using Android_translation_layer

#89
post #86

Earlier quoted context omitted.

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

There is now at least one public windows kernel call listed on MSDN: __fastfail https://learn.microsoft.com/en-us/cpp/intrinsics/fastfail?vi...

I'd call that a special ABI feature, not a stable system call. Note that it's a software interrupt, not a regular SYSENTER. But sure. Maybe I'm splitting hairs.

Re: NewPipe on Linux, Using Android_translation_layer

#90
post #80
post #79

Mmmh, I'm using it on Android for some time now, installed as F-Droid app. Problem is, there is some friction regarding Countermeasures of YT and a new version adjusting to them. Often, I'm unable to use the alternative Client on Android for months until this is fixed. Will this be a problem on Linux too?

have a look at NewPipe's own fdroid repo: https://newpipe.net/FAQ/tutorials/install-add-fdroid-repo/

Thanks! Shows the same version as the installed app from the main F-Droid repository - but this one works.
Post reply on HN