The 'one weird trick' could've been spotted in a graphical bundle analyser. But are they not caching npm packages somewhere, seems like an awful waste downloading from the npm registry over and over? I would think it would be parsing four different versions of the AWS sdk that was so slow.
> seems like an awful waste downloading from the npm registry over and over
Pondering this question across every organization in the world and the countless opportunities for caching leads to dark places. Would be interesting to see CDN usage for Linux distributions pre and post docker builds becoming popular.
I think principally, it's not actually that much worse. However, there are some aspects of Wayland that are much better and much worse for people who prefer to go their own way.
With Wayland, the protocols are specified in machine-readable XML files, not unlike how XCB works, and typically a program called a "scanner" would read those XML files and perform code generation. So if you wanted to generate proper Wayland bindings, you'd need to write the scanner. The scanner is not terribly complicated. I did it in Go with around 750 SLOC, not counting the supporting code. It's not released, but here's just the code generation part, if you are curious. Last I used it, it could generate all of the Wayland protocols, and I was successfully using dozens of them from my own Go bindings.
Of course, if you just want to implement Hello World, you don't need to use code generation, and the resulting amount of work to interface with X11 is ultimately similar to that of Wayland. But there are two huge caveats:
- Right now, the EGL interface for Wayland requires that you pass libwayland wl_surface structures. That means to get on-screen hardware accelerated contexts in Wayland, you have to link to libwayland (maybe making compatible structures would work if you're into that kind of thing, but definitely no easy options.)
- X11 has many server-side features that Wayland doesn't. Wayland's core protocols don't specify even window decorations or cursor shape, so a Wayland client has to implement drawing window decorations and loading cursor themes to properly support all Wayland compositors... even if they would prefer to use xdg-decoration and cursor-shape-v1. This is on top of things that no Wayland compositor has support for, like an equivalent to XRender or indirect rendering with OpenGL; those things just don't exist.
So it's far from perfect. Though, it's also not like X11 was free of cruft or design issues, either. I'm pretty sure with X you also have to implement cursor themes yourself, by virtue of linking to XCURSOR. And while you can use XRender and other server side rendering features, which will be way more efficient for remote usage than simply opening a GL or Vulkan context, most software (GTK, Electron) doesn't do this anymore, and either ships buffers over shared memory or opens a direct hardware accelerated context.
Personally, the problem I'd really like to see fixed is the EGL ABI one, but I'm pretty disillusioned by the bullshit in anything RedHat indirectly touches (e.g. Freedesktop.org), so even if there's a chance I could help, at this point, I'd rather spend my time working on other things.
There are some things that are more compilcated, e.g. you need to bring your own libraries for font support and input methods and rasterization and so on, and you need to handle hotplugged input devices and such. But protocol-wise it’s not really more conplicated, no.
I think as always in software, "it depends". The author appears to be assuming there are no tests on all of these paths that we will apparently miss when we migrate the code over. If so that is a problem with testing rather than migration.
Also how messy are we talking? I've seen code at a bank where a junior contractor implemented, in reams of code, his own database locking primitives, apparently unaware that the db could handle concurrent accesses on its own.
Rewrites aren't such a big issue these days, this seems a little dated. The real issue where we get painted into a corner now is architectural, say if you went really hard down the microservices route and tried to back up out of it.
No worries, it's still broken by the way, I have an enterprise SAML log in for figma, not sure if that helps. I did want to demo this to my company, but maybe you are not ready for prime time just yet?
Do you mean to say Haskell hasn't solved the halting problem yet?
reply