destructionator

> Xorg being removed. What does this mean?

It means your distro is terrible and it is time to switch.

The author of this blog works for Red Hat though, so he won't speak that particular truth.

I've played with this a bit over the years, starting with my automatic form generator for the web back in 2011 based on function arguments (coupled with an automatic data to html thing to see the function output), and more recently some similar stuff for my gui toolkit too (using the D programming language).

For example, you can write:

``` import arsd.minigui;

void main() { // need to define the data you want in a struct, // it requires a struct even if you only want one item struct Data { string code; }

// then do the dialog function with the struct and it // auto-creates a dialog for all the parts of the struct // and calls the function you provide when the user hits OK dialog((Data received) { // you got the number here

  messageBox("You gave me " ~ received.code);

 });

 // need to run the event loop explicitly so main doesn't return
        // early and end your program; this will return when all windows are closed
 EventLoop.get.run();

} ```

You can also attach some user defined attributes to tell it which widget you want to control the thing (defaults are line input for string and int, drop-down select for enum, groups for structs... that's about all i bothered to implement so far, tbh my gui toolkit is more of a side project toy than a main event so the time i put in is limited), for example using `@ControlledBy!VerticalSlider(0, 100)` on an `int` to make it a slider from 0 to 100 instead of a text box asking for a number.

My menu thing uses this too, you can attach functions to menus and it can pop up a dialog. For example you might do `@menu("Search") Find(string text) { ... }` and let it auto-generate the menu and dialog box for it. I also have a `DataControllerWidget` which does the callback on any change event, allowing for real-time manipulation. I wrote a little blog post about this a couple years ago (seriously, i move sooooo slowly on this stuff!) http://dpldocs.info/this-week-in-d/Blog.Posted_2020_11_02.ht...

I'd love to spend more time on this, I think it is really cool, but tbh I haven't gone too far beyond the basics and since day job has no use for such stuff it gotta be squeezed into when i feel like doing code on the weekend.

Translating small syntax differences like that are easy to do by machine if you have to.

Hmm, yeah, I never saw any internal stuff (I'm just a random person on the internet), but my impression from public info is they had a few isolated individuals experiment with it on small projects but the company never formally adopted it or supported it for anything serious.

> Many projects were written in D.

What's your source on this?

I joined a number of patreon things and i liked how it just billed me the one thing a month and it was pretty easy to stop it all on the one website, but i recently tried joining a new one and it asked for my payment info again and had a different pay date and i just noped out of it. kinda a pity, i liked the way it used to be.

What I like about D is if you already know it, it can adapt to just about anything you want, from these kind of shorter "scripts" to experimenting on bare metal to regular applications.

But yeah, if you already know ruby and python and perl and awk and the unix shell, there's not much to be gained in these examples. Just if you don't know those things and know a little D, it can meet you where you are and take you where you're going.

I have D code I wrote back in 2008 that still works fine today.

That said, there are often small breakages scattered around and it can be annoying. If it is your own code, you spend the 5-10 minutes to update it (with some exceptions, the last couple months have been particularly bad, most aren't like that though). But if it is someone else's code and you have to wait for them to update it then push a new version tag, and cascade through the dependency list, that can suck.

of course dependencies suck so you get what you pay for lol

> Well, it makes the project unprofessional.

Next time I hire a professional, I'll be sure to call them unprofessional when they hand me a bill. A real professional doesn't expect to be paid!

Caps lock is great when you are typing one-handed.

On Windows, the normal ReadFile function can return synchronously or async (if you pass the appropriate arguments to it) depending on presence in the cache. Since it is all one atomic operation, there's no race condition; you just call it and see in the return value if it succeeded immediately or queued the operation.

(If you haven't read about Windows' overlapped i/o, do so, it is actually quite nice to use.)

io_uring brings something similar to Linux.

This test doesn't include epoll in any significant fashion at all, and also doesn't apply to network operations. The libuv thing is specifically about disk files, which linux doesn't really support with epoll (epoll just always considers them ready, regardless of if the requested page is in cache or not, meaning it is not helpful for the async case. by contrast, a socket without data immediately available in the kernel's buffer will not show readiness).

Since you can't tell if a disk io function would have to actually hit the disk or use the cache on older linuxes, libuv just always dispatches said operations to a worker thread pool which then calls the normal function. When it returns, it sends a message back to the other thread to indicate its completion.

If data is already present in the cache, this adds significant overhead vs just calling `read` directly - instead calling `read`, it will post a request to the worker thread queue (which may require synchronization, im not sure exactly how the impl does it tbh), wake the worker thread which calls `read`, which does not block significantly since the data is indeed already present, then it posts an event back to the main thread (which, sure, it is listening for this event on `epoll`, along with whatever else it is listening to, but that's an insignificant detail at this point) which calls the on-complete handler. All that work instead of just transferring the data from the cache to the result. Significant slowdown.

If the data is not already present in the cache, it does exactly those same steps, except this time `read` actually does block for some time, so the main thread can continue with other work in the mean time. (Of course, if the main thread has no other work to do, you've gained nothing from this!)

Hence why I said in my other comment that you ought not draw any general conclusion from this. This speedup has nothing to do with epoll vs io_uring (except maybe that linux file i/o is not really epoll compatible) and everything to do with libuv's block device implementation specifically. It is totally inapplicable to network loads entirely.

edit: in the first version I said "disk file" but it is technically block devices, of which disk files are just the most common example, but of course /dev/zero is a block device that is not a disk file.... and worth noting that /dev/zero is never going to actually load off a disk meaning it is "in the cache" all the time.

libuv's implementation of "async" disk i/o brings massive overhead (somewhat necessarily on linux, totally unnecessarily on other systems), so just about anything (including just switching to straight blocking read/write/seek/etc syscalls) would result in a significant speed increase.

This isn't to say that io_uring is bad, just don't draw too much a conclusion from any benchmark of their old impl beyond the context of their old impl specifically.

The client is given an XConfigureEvent when it is moved and can compare it against the monitor's bounding boxes (which it caches in between xrandr change notifications) and rescale itself.

Doesn't work with legacy applications... but neither does Wayland so you aren't really behind.

You can do it with client side scaling in X (which is also the preferred solution on systems like Windows, since an application can scale itself better than a generic compositor anyway).

First, you can simply not use trash frameworks and get better results.

But more importantly, drawing pixels is just one part of a gui and focusing on that without considering the other parts hurts. I've been testing input devices on remote X lately: using programs on my desktop on an old laptop with a touchscreen and a drawing tablet and all kinds of other gadgets. It has different input methods than the client computer. They all just work remotely too, with full capability. Things like copy/paste and drag+drop just working between windows, regardless of where they are running, and integration with local window management is a huge benefit, you can forget these random programs actually run somewhere else. It feels like there's no barrier.

> Are you doing different scaling per monitor in X11?

I do this, but only some applications cooperate. I couldn't even figure out how to configure it right on kde even though the underlying capability is there.

It definitely isn't impossible, but the popular toolkits make it much harder than they should.

I use tons of things on it. When I use my laptop, often I'll run a local browser (though sometimes I run remote browsers too - Chromium's core works actually surprisingly well on a remote X link - but the bigger problem there is that chromium doesn't support multiple instances, so if I left the browser open on the desktop, the cookies and history aren't shared on the remote instance on the laptop which defeats the purpose of reusing the instance anyway, but sometimes the shared passwords still nice to have) with most everything else being run remote.

Among the specific applications are my developer tools, image viewers, music editors, the apps I'm actually working on, etc. Of course, some of these also work fine on ssh terminals and I do plenty of that too, but there's just no need to be limited and I'll run whatever I want to.

He claims gedit does 130 blocking InternAtom calls, 34 blocking GetProperty calls, and 116 property change requests. None of those are actually using the available async functions (or even available XInternAtoms call to batch all those 130 into the main thing).

Since this video is coming up on ten years old, it might have been true at the time, and gtk/gedit have since changed the implementation. But regardless, if the video is accurate, they didn't use the non-blocking calls. If the video is not accurate, it is meaningless anyway.

It isn't really Wayland's calls itself, I prolly stretched too much there, but the main thing is the async discussion usually comes up in the context of running applications remotely, which Wayland simply doesn't support. If you do a loop of XInternAtom (which btw you shouldn't do, even in xlib - notice that there's also XInternAtoms, plural, for that kind of thing which batches them to reduce wait time...) locally, it is unlikely to matter. The time spent there is near zero anyway. But remotely, now you might be looking at several ms per iteration and that adds up fast. Now the blocking aspect can become problematic.

Since Wayland doesn't support this kind of network remote use anyway, the distinction doesn't matter. Local X vs Wayland are both fast.

> That graceful degradation is in practice the same, as just using Wayland. Ever tried to use modern X11 app over network? RDP is vastly better experience, (and RDP support is wip in wayland).

I do, in fact, use modern X11 apps over the network literally every day. Some are better than others - if the programmer made the effort to actually gracefully degrade it can be a considerably better experience than the ones who just shoot a constant stream of bitmaps down the wire (which do work better on rdp, i remember once upon a time, I'd ssh to my linux box and set up port forwarding to a windows box on my lan so i can remote desktop to it, then run Xming from there... which is absurd that that actually worked better), but if you do it well, remote X is very nice to use.

The seamless integration of windows from multiple computers is a thing to behold. Remote Desktop is great and I like a lot about it, but even the "Seamless" rdp doesn't work as nice as X.

This isn't that different than X though which also has the fire off a message and receive event back. Very few of the functions actually make you want (even in xlib, which wraps the protocol itself to be a bit easier to use from C, the majority of functions still are async - much to the chagrin of newbies trying to decipher error messages)

> But even with that it's STILL possible with the right setup using xrandr where you essentially render at a higher res and then downscale.

You actually don't even have to do this for updated programs - hidpi aware applications scale themselves, vector graphics style, so there's no up then down scaling going on. And applications can easily read the xrandr config and adjust their factor when moved to a different monitor. However, xrandr's ppi factor is not the scale factor you likely want, so this isn't really standardized; each toolkit might do it a bit differently. But all the pieces are there.

Non-aware applications might be bitmap scaled if needed though. (Of course, wayland just breaks all legacy applications anyway so that sets the compatibility bar low regardless)

This link comes up in literally every Wayland thread and it is even more bullshit now than it was in 2013 when it was first posted (and it was bullshit then too). It is titled "the real story" but it is quite the opposite.

A few key points:

1) he laughs at how X has a bunch of extensions. https://wayland.app/protocols/ hypocrites much. In 2013, since it was completely unusable, it probably didn't have many. But turns out real world use leads to "useless" features being reimplemented.

2) he complains about how X.org has broad hardware compatibility. As if that's a bad thing. Meanwhile wayland, even now it still doesn't work reliably on half the graphics chips on the market.

3) It complains that certain X features are not fully network transparent. True, but most are and you can detect at runtime and gracefully degrade. Wayland "fixes" this by just dropping the whole feature.

4) it flat-out lies saying the X server does nothing yet it is so much hard to maintain code. The core X protocol provides backward compatibility and is rock solid (and really easy to impelment from scratch btw, someone did it in Javascript for a tutorial for crying out loud). Meanwhile the Wayland compositor keeps accumulating everything because of point 1. Need a screenshot? Add it it the compositor. Need a hotkey? Add it to the compositor. Need drag and drop? Add it to the compositor. Need a notification icon? Add it to the compositor. In X, all those are peer to peer. Graphics are actually a relatively small part of a graphical user interface, something Wayland is still slow to learn.

5) He complains that certain applications are written inefficiently with blocking calls which is inefficient over a network connection. Wayland's calls are ALL blocking and just has no network connection.

6) Complains that X may draw things unnecessarily. Indeed... but there's an extension to disable that. Easy fix. Wayland even uses the same drivers!

> The fact that any Xorg client can become a key logger without any user input or authentication is a pretty big security hole imo.

This "hole" doesn't exist. For an X client to capture input, it must be authenticated by either the unix user permission or by an access control list (where the default is to deny). Individual clients can also be marked untrusted which sandboxes them to some extent (though not as much as using a separate X server of course).

I'll grant that in practice, most the time these restrictions are very lax... in part because they can break some applications. But at the same time, in practice, it doesn't seem to matter that much since either you're running things you trust anyway or if a malicious application has access to your X connection they also have access to all your other files so you're in trouble anyway.

> I’m speaking of the consequences of Xorg’s basic lack of isolation (because it wasn’t designed for use cases where that matters): that granting access to the X socket allows you to inspect, intercept and modify inputs and outputs for things like key strokes, window contents (yours or others’) and clipboards.

This is not true! Both the protocol and the implementation allow for significant separation of server permissions (for example, notice the difference between ssh -X and ssh -Y), and the peer-to-peer nature of things like clipboard means it is quite easy to deny requests on an application level if they're written for it.

> Do you think the Xorg devs are spreading lies about Xorg?

Some are, yes, this is incontrovertibly true. But this one? You should hit the "history" button that's in the corner of every wiki. That page hasn't been edited at all since 2013, imported from some other document written I don't know when, and literally the only thing it actually says about security is that "needs to be designed with security in mind".

What does that mean? What specific shortcomings have they identified?

> the likes of Xorg really aren’t designed for that use case.

Bullshit. Would be nice if people were to stop spreading these outright lies.

D rarely has copy on write.

It will just plain copy certain types on assignment though so perhaps that's what you meant.

D is realistically somewhere in a middle ground between C and Rust for kernel work. It leans more toward familiarity for C programmers with some added safety checks (indeed, you do lose something by not using a garbage collector, but you can still go a pretty long way without it thanks to auto bounds checks and such) but does not enable as much static checking - nor require as much new learning - as Rust.