Tess's Android Wayland Compositor | Hacker News Reader

Tess's Android Wayland Compositor

github.com

86 pointsschmorptron17 comments

This looks promising. Would be cool if we could set a standard Linux DE (like Plasma) as the default homescreen and have it integrate with Android's notifications, apps etc.

Oh that Is cool especially on a foldable you can run some interesting apps on it. And with wine + fex even more crazy stuff.

Very cool.

> libhybris allows glibc Linux programs to load the standard Android graphics drivers

I don't quite follow why you need that? This runs on a real full Android, so surely drivers already work?

The graphics drivers on Android are compiled with Bionic where as most Linux distributions are compiled with glibc. You can't really mix and match them.

Desktop linux apps still need to link to the system graphics driver to get hardware acceleration.

> Desktop linux apps still need to link to the system graphics driver to get hardware acceleration.

Oh, right. I forgot about that part. Thx.

That's just the tip of massive ridiculous endless NIH reinvention. Nothing works at all the same in any way. Android has its own Surface Flinger windowing system, with its own drivers. Nothing is at all alike the rest of Linux userlands, from libc up.

I don't think it's NIH so much as the glibc ABI is a broad surface of implementation specific choices outside the C standard, and a moving target. It's an emergent property of many small implementation choices that another libc project would find too difficult to replicate.

I had a recent experience fighting this sort of thing when I wanted to cross-compile from a distro using glibc to a distro using musl.

Glibc is also kind of bloated and it's reasonable that android or a similar embedded project would not want to pull the whole thing in. Especially when you consider the original goal of bionic was just to bootstrap Java code, which was meant to be the primary platform interface rather than C, they would want a very minimalist libc for that purpose.

NIH barely applies here at all. If we take into account the constraints they were under and the absolute state of desktop Linux when Android started, it makes total sense.

Starting a lot of the components as greenfield projects will fortunately help a ton with shedding years and years of legacy cludge, hacks and desktop first design. Without mentioning the colossal amount of friction they would've faced if they tried to upstream any of the code they would've produced by the end. "We don't care about that issue. Closing."

Because of the above, they still would've needed to have their own fork regardless and still would've eventually diverged further and further -- so why bother? With a greenfield project, you can just optimize to your specific constraints. If the maintenance becomes too burdensome, just pick up the best of your design and reimplement them onto the non-greenfield project, everyone wins :D

Maemo was right there at the same time?

Yeah, it technically was there, but it had proprietary components and Nokia had a baggage of softbware project management being super inefficient because of their earlier roots of how they developed software in their past. Not that I have personal experience of it, but a colleague of mine had first hand experience of it.

Nokia had a "means to an end" type of perspective to software, it was all made to be basically disposable and they didn't have great "steward of the platform" type of effort.

Also, if we take a gander at the timelines, unfortunately QT and Maemo were happening in parallel, and of course Maemo was based on GTK. (But QT was still a Nokia proprietary tech back then.) Right hand not knowing what the left hand was doing etc.

Not that any of this means anything, just felt that this was all relevant.

And in spite of Nokia being fundamentally in the dark, not really helping: it was a wildly successful scene. People were rabidly excited and doing incredible things with their devices, in cross-modal between phone/laptop/desktop ways. The core of technology had great interoperation points.

It's weird because my whole point is that the freedesktop mentality means no one company ever is that important to the device. And your point is that Nokia was terrible at Maemo. Yes but? Yes but: it didn't really matter. The ecosystem was incredible, intense, vibrant. If you leave the door open, people will do amazing things with your platform. And even if the company burns the platform, burns the ships, a lot of people will still probably spent a decade being vociferously dedicated to the platform. https://maemo-freak.com/community/

SurfaceFlinger is not NIH. When Android was being never Wayland was barely a thing and Xorg is inappropriate for embedded.

D-bus had been around for a decade. Asserting that X was inappropriate requires a little more justification in my view than a blanket testimony. Worked ok for Nokia!

Binder predates Dbus and uses less memory than Dbus, which is important in memory constrained devices.

> Worked ok for Nokia!

Yeh... No multi-touch, terrible latency.

Nokia certainly did well...

Binder was proprietary closed technology that came from a pre-Linux use, if I i recall correctly? It was spun off from OpenBinder from Be Inc and Palm. Android built their own initially closed new Binder, for Android Inc, before the acquisition by Google. You're right that it existed first, in some form. I do keep forgetting that DBus itself isn't that old, 2002, so yes, Binder has earlier roots. But it was never really a thing anywhere in the Linux world? No one knew about it or used it? It was a novel new direction for Linux, with no real precedent. And sure, I am sympathetic to not just hopping on the latest messaging bus, assuming it's going to work. https://en.wikipedia.org/wiki/OpenBinder

Perhaps Binder is lower memory footprint, but given the size of messages sent around (small, sometimes with sizable attachment files), I expect this is a rounding error at best. I'm pretty skeptical this was a grounded decision based on memory footprint.

The timeline where Android decided to care about the valent Linux ecosystem doesn't seem quite as hard to imagine as you make it out to be. It would have meant giving up on previous really good ideas from Be, from Palm, that they adopted & re-cut for their own purposes. It would have meant looking at the open source ecosystem, tracking it, & caring.

SurfaceFlinger was also NIH, contrary to your previous statement. Sure Wayland didn't exist. But once again I think there's no real actual factual strong basis to say X wasn't enough. If you want to pose some hypotheticals for arguments you'd make that indicate that direction, you're welcome to make the claims. But it sure was NIH, as other did use X and Android invented it, so I think you're just arguing whether it was justified NIH or not.

Last, I don't see how some cheap shots at Nokia hardware (running on an already quite middle-of-the-road at-best core) reflects on this whole point. This feels like yet more just trying to shut down engagement/discussion/conversation, close down thinking. So what if Nokia wasn't making the greatest hardware? So what if they used a very middling TI cpu that wasn't very good? Those to me are questions of circumstance, are much less interesting than what the OSes reached for.

I realize comments on HN tend to be very terse and short, but you've made so many big claims, with so little substantiation or support, and they seem on the face of them pretty misleading or outright wrong. And none of them point to any evidence or circumstance, or are guarded: they don't argue, they insist. I personally prefer more open debate, and would like to see a little richer respect for nuance, a little less heavy handed absolutes.

I'm trying to imagine a use case for this, but can't think of anything. Maybe Desktop mode + full/real Linux apps?

This is what the author showed off on Twitter at least, with Desktop chromium I think.

Reply on news.ycombinator.com