greenfield

ore Greenfield, an html5 Wayland desktop/compositor. https://github.com/udevbe/greenfield I absolutely think there is all-in potential for the web. I think we're missing a visible rallying point, where a stronger community of app makers can cooperatively advance beyond-the-web capabilities. Project Fugu & WICG help a lot but are also working with Safari (and sort of Firefox) handcuffed to them.

there are multiple competing protocols for the same feature-sets, but usually/historically, wayland-protocols hammers stuff out reasonably quickly & most of this is a matter of time. Still, this is often easier than the past, where apps would have to each test for extensions & have various fast/regular/fallback codepaths depending on available extensions; not necessarily a hindrance to the window-manager, but a bundle of complexity for everyone else trying to use X11 adequately. The Wayland common primitives, on the other hand, are fairly universally performant & well chosen. Returning to complexity for window-manager/compositor, the situation is not unlike X11 itself, where yes, a simple window manager (or compositor) is possible to spin up relatively quickly, but where there is a sea of different standards to implement to do a good job. Window manager hints, extended window manager hints, and a plethora of other standards existed around X11 that were up to the window-manager to tackle, and implementing each of those took a lot of time too, if you wanted good support for all apps. Different Wayland compositors also have different support for different protocols, and those are a bit deeper rooted capabilities, less superficial than many of the X11 hints (which, if ignored, were less likely to impede use), but the idea is the same: real support to really be decent took work in X11, and it takes work in Wayland to implement a good suite of protocols here too. Where I disagree highly is calling out the hardware here. Wayland is closely tied to kernel fundamentals; any reasonably supported video card will perform adequately under any competent/non-specialist compositor today. (Certainly some compositors could demand higher standards, such as some of the experimental compositors requiring Vulkan, but generally compositors have very similar, very common requirements.) > I wonder if it would have made more sense to go with a paired approach-- a single master compositor implementation, with the complicated and more hardware-sensitive stuff involved, and a pluggable window manager that spoke to it. I like where we are, where there are various toolkits/libraries for accelerated implementing. Wlroots, which underpins chiefly Sway (the i3 replacement), has given rise to a variety of other compositors, spanning the gamut from quick/fast/experimental to rich/deep/powerful. libwayland still defines some core ideas, if not compositing implementations, to speed development somewhat. Weston is still available as a reference compositor, although yes it's designed (more or less) to be forked & enhanced, not built to be preserved & built (extensibly) on top of. Wlroots & other alternative toolkits fill this need, & provide a diversity of ideas for how we might get going. Projects like Greenfield, the HTML5 compositor (https://github.com/udevbe/greenfield) demonstrate the diversity we get from not having a single common core technology, are possible because of this belief in protocol & standards over implementations, eased though implementations might be from promoting something like Weston to the one-and-only implementation. > The whole "nVidia works, but only with the GNOME compositor" sort of stuff reads as a sign that there's way too much involved in there. We can't look at a anti-plays-well-with-others entity like Nvidia to assess what is/isn't a good idea. Nvidia spent nearly a decade stomping their feet & demanding only their way was ok. The fact that Embedded OpenGL itself, what the rock their obstinacy was built around (EGLStreams), is quite heavily on the way out further should stress how foolish & self-centered this vendor has been. This discompatibility indicates nothing, is no sign, except an indicator of what kind of a company Nvidia is/was (one that obstructed any implementations of well known & common kernel constructs).

adapter layer, a Vulkan-atop-WebGPU translator, that could be stacked up. Or we could build WebGPU backends for these adapters. This is a pretty non-trivial effort. It's notable that projects like wgpu exist to provide a cross platform support for WebGPU, so if one were to build a DirectX-on-WebGPU translator, wgpu would let that game run on basically any platform: it'd be way cool. But again, that sounds like hella work. There's a ton of other technical problems. Huge challenge #2 is that most games are precompiled for x86. Ideally we'd need to recompile them for webassembly, but it's unlikely many games would ever get ported. They could run at radically reduced speed via some machine-translation and games like TA might even work ok that way, given how much faster even a cellphone is than the pentium166 i rocked TA out on. Challenge #3 is platform. These games rely on an native platform support for files, sockets, and dozens of other event loop & other concepts. Given time & effort, doubtless many of these could be platform libraries could be re-implemented. Projects like UMass's Browsix[4] purported to create similar platform libraries web-natively, creating a Linux-y/POSIX-y environment in the browser. This could perhaps be mated to something like Emscripten to expand the platform offerings significantly. Emscripten itself has adjacent projects for some platform support. Oh, wow, TIL it has OpenGL->WebGL conversion layers: some games could concievably be recompiled with emscripten without too too much fuss & work. But this would not be a Linux desktop, it would be just the game, in a canvas. There are projects such as QuakeJS[5] that appear to do just this! The web itself is evolving many similar-ish capabilities for this #3. WebTransport is a better WebSocket that comes closer to being a viable network layer, and one day may perhaps, if we're all really really lucky, become a transport for WebRTC as well (fingers crossed). There are various File System API and File System Access API proposals going around for talking to files, which are only kind of semi needed, as a virtual filesystem is probably fine. [1] https://github.com/udevbe/greenfield https://news.ycombinator.com/item?id=29239781 (71 points, 3 months ago, 26 comments) [2] https://github.com/doitsujin/dxvk https://news.ycombinator.com/item?id=16199332 (216 points, 4 years ago, 51 comments) [3] https://wiki.winehq.org/Vkd3d [4] https://browsix.org/ https://github.com/plasma-umass/browsix many popular discussions, 5~6 years ago: https://hn.algolia.com/?q=browsix [5] http://www.quakejs.com/ https://news.ycombinator.com/item?id=22797060 (357 points, 2yr ago, 158 comments)