sprash

> Oracle owns the rights to the NeWS source code so I'm not allowed to post it on my Github page.

They are certainly not making any money with it right now. All patents should be expired by now. Have you ever sincerely asked if you are allowed to publish the code?

> Do you have any ... display servers that solve all the problems too?

X11 has extensions which correct for most of its original flaws. Most importantly XRandr (as mentioned in the article), DRI3 (fast hardware access) and XRender (accelerated drawing primitives that don't suck). With the exception for the availability of a decent toolkit and HDR extension X11 solves all the problems.

> Or comments on any of these?

Oh boy... well, you asked for it.

> Pie Menus

Great for demos and to collect grant money, i guess. But in principle a total anti-pattern. People read from left to right and from top to bottom. Traditional context menus are therefore far superior, especially for varying numbers of options.

> Weirdly dragable tabs

Not impressed at all, sorry. Creates much more visual confusion than generic title bars.

> HyperTIES

The most revolutionary component are links... which are not invented by HyperTIES.

> PSIBER

Genuinely very impressive. A proper visual postscript debugging tool. But also necessary for a rather unintuitive stack based language like postscript which is primarily designed to be machine readable.

> SimCity

Great Game. Thanks again for making that available to the FOSS community.

> 1994

Apparently you have to be criticizing X11 for more than three decades now. Since you seem to know your stuff, could you please post a link to your git repository containing your personal display server that solves all the problems?

> while Wayland leisurely moves forward

Debateable. But it sure started with huge step backwards. On X11 all relevant functions are at least standardized within the xrandr protocol. On Wayland you don't even have that. So it really depends on the compositor if it works or not where each is doing its own thing which is just crazy. I prefer the 70s standardization model of "mechanism, not policy".

Seems like somebody forgot to read the pamphlet[1].

1.: https://stopthemingmy.app/

A test [1] by a random dude with the older Wormhole N150 delivers half the performance (as in tokens/s) of a RTX 4090 in generic Llama tests. The new p150 should have double the performance according to specs, but who knows. I'd call it somewhat competitive.

1.: https://youtu.be/WibEx3jfKu0?t=957

> Can you point out any specifics?

How much time do you have? First of all it needs to be much simpler to do simple things. You are right that you need to "allocate some shared memory for a surface, agree on a pixel format, etc" but it shouldn't take 250 LOC just to put a simple window on the screen (look at https://wayland.app/protocols/wayland there is no reason to make bare essential things that complicated). A proper standardized client library should need 1 LOC for that. The whole polling/ping mechanism is completely flawed. Since you don't know how to solve the halting problem please let the user decide if an application is unresponsive or not and reliably kill the pid of the window when the user presses that "x". Until then assume the process to be working. This also means a hard requirement for server side window decorations since they need to be rendered by another process with higher priority (also because temporarily unresponsive windows might occasionally be moved or resized). Windows should also be able to obtain where they are on the screen in relation to other windows from other processes. There should also be processes that are allowed to read out and modify all window positions (e.g. for window managing and automation). Also processes should be able to read image data from screen or other windows (e.g. for screen sharing). Standardized interfaces and proper access control for all latter things should be baked into the protocol from day one and not rely on non-standardized external infrastructure (like dbus/portals). And those interfaces should be as simple as possible. Latency is generally bad on Wayland. The mouse pointer should be rendered by a separate thread on its own hardware layer which requires no vsync. Keyboard input events should be able to immediately update dirty rectangles disregarding vsync for those pixels to make typing as smooth as possible. Generally allow tearing for windows by choice of the user/program and be able to have windows that don't allow tearing next to tearing windows at the same time. (I have more but nobody reads that shit anyways.)

> If you were designing a modern windowing system from scratch, what would you do differently?

Personally I would recreate something like MGR with a modern spin. But this is obviously a very opinionated design.

I find it very surprising how well Xorg still works considering it receives essentially zero funding. To me this is a sing of a very robust design.

I'm also not surprised at all how bad Wayland is. The protocol makes wrong abstractions at the lowest level which causes problems everywhere else. The worst being massive fragmentation. It wont ever be good despite receiving big amounts of funding. But this is obviously by design.

The VRR issue can be solved with a simple patch that never got merged into mainline (no idea why). Hence it's not inherently a X11 problem and honestly also a rather niche problem compared to the humongous deficits Wayland brings.

Mixed DPI works perfectly fine on X11 if the toolkit supports it. The xrandr protocol provides all the necessary dpi information. GNOME simply chose not to support it on X11.

Wayland lacks a strong reference implementation. The resulting fragmentation in the ecosystem turns the most popular compositors into de-facto standards every application developer will have to use as a reference.

This means Gnome's problems = Wayland problems.

Furthermore, the latency issues with Wayland are inherent. Compositors will always have worse latency than writing directly to the front buffer.

What exactly is better? I can't even think of a single thing.

It has worse performance on almost all metrics. Heavy fragmentation. Very limited and incomplete API measured in functionality but still extremely complicated to work with as developer. Extremely slow development. The only thing that it has over X11 is better funding (for whatever reason).

It should be easy to create something better than X11. And if not pour more resources into X11 developement. Wayland on the other hand is a complete failure on all fronts. It should be abandoned ASAP.

This is pretty good:

https://www.shadertoy.com/view/4dlyWX

But more practical are:

https://www.shadertoy.com/view/XsjSzR

https://www.shadertoy.com/view/MtSfRK

https://www.shadertoy.com/view/4scSR8

The CIA has papers about it [1, 2]. Paper [2] even contains experiments that should be easy to replicate (and will obviously not work). It's probably complete BS.

There is a paper [3] that derives the Maxwell equations from quaternions and introduces a scalar quantity called "Temporal Field".

If you completely disregard gauge freedom like all those "theories" you can do all kinds of fun things. But those things don't describe what we see in nature.

1.: https://www.cia.gov/readingroom/docs/cia-RDP96-00792R0005002...

2.: https://www.cia.gov/readingroom/docs/CIA-RDP96-00788R0019006...

3.: https://arxiv.org/pdf/math-ph/0307038

The mostly unelected EU regime really loves censorship. Nobody ever claimed that Putin is in any way better. That doesn't mean that the EU isn't complete shit. And if you want to focus on the EU market like Whittaker claims in the interview it only works if you are completely compromised. Also looking at her history I don't think you could find a more glow in the dark person than her.

As long as they don't get rid of the Qt dependency the project is a bit pointless. If you are using Qt anyways Qt Webview offers already a superior way to render HTML than Ladybird.

Almost 100% of the "scientific community of mathematicians" is funded by the government. They can't be trusted either. If they want to publish something that is considered to be a "threat to national security" the agencies have multiple avenues at their disposal to "convince" them to not publish.

> And finally, we wouldn't get laws like this.

Codifying covert practices into law has the big advantage to make the whole oppressive surveillance state much more efficient. Gone are the days of "parallel constructions". Also the chilling effects of total surveillance alone might be enough to prevent the opposition to be effective.

If there was public evidence allowed to be released nobody would be using those algorithms obviously. The point of those algorithms is to make them hard to break for the public and easy to break for the agencies . E.g. None of your mentioned products use quantum hard encryption. It is not far fetched to assume that all the relevant agencies have access to a working quantum computer. But I doubt you need even sophisticated hardware. Most "government approved" encryption algorithms should be considered compromised from the get-go.

"Chat Control" is already real. This is just codifying prevalent practice done by a multitude of agencies into law.

This is why the XRender extension was introduced. There you have antialiasing, all blending modes you could wish for, subpixel coordinates, advanced drawing operations like gradients and it is fast because it is fully hardware accelerated. All working over a very efficient wire protocol. E.g. Cairo uses Xrender as a backend.

Not powerful but extremely simple, especially if you want to avoid JavaScript at all cost:

https://chartscss.org

> X11 wins in some cases, Wayland wins in other cases

Even according to your blog post uncomposited X11 wins in all cases (or is tied within the error of one millisecond). It especially sweeps the floor with immediate rendering.

> "broken by design" is an extraordinary claim and requires extraordinary evidences

There are many technical aspects that make Wayland broken by design (like default forced vsync, forced double buffering, a fucked up event-loop for single threaded applications or severely lacking functionality for things like window positioning or screen sharing). But the biggest problem is the design-philosophy: Wayland makes life extremely easy for gate keeping "Protocol Designers" and extremely hard for application developers.

> un-sandboxable

Not true. The quick and dirty way would be using Xephyr. Besides that many access control hooks like XACE are present and standardized in the X11 protocol for many years. Application developers just choose not to use them. So if X11 is not secure enough for you, blame GNOME and KDE, not X11.

Wayland is also a "client-server" model. If you use DRI3, X11 and Wayland even do the exact same thing "under the hood". Only the sub msec negotiation phase is slightly more complicated on X11. We are talking about very cold code paths here.

Wayland not only has forced vertical sync it also requires every application to be double buffered. This can be detrimental for some performance metrics. That is why Wayland has worse performance despite being "simpler".

The X11 DRI3 buffer swap mechanism is identical to the one used in Wayland. The fact that Wayland has still worse performance across the board (especially latency metrics) might be an indicator that Wayland is fundamentally mismatched with the needs of a modern graphics stack.

No they decided working on X11 would not rake in enough consulting money. So they engineered a completely non-working solution called Wayland that is broken by design and takes years and many consulting hours to fix.

The real reason people stopped developing Gtk applications is that GNOME tends to declare widely used APIs arbitrarily as "internal interface" and makes incompatible changes even on minor version updates.

It's a constant chase not worth any developers time.

I would be interested in a comparision of uncomposited X11 running Xterm using this measurement method.

Xterm outperforms everything "on paper" with typometer but is it really real?

This is also not what happened. I remembered that she once was proud of her work and the fact that her image was used so widely. Then FOSS and engineering in general was targeted by a wave of cultural marxist psyops that brought us useless stupid things like CoCs. And within that wave she was convinced by "activist" (=operatives) to demand the retirement of her image.

It's the perfect angle to cause division and cause endless discussions about irrelevant BS. Congrats Psyop successfully deployed! (Probably CCP behind this in order to weaken western Engineering)

As expected fine-tuned st is the clear winner. However, it can be improved even further by removing double buffering altogether. Since the code is very hackable it's quiet easy to do and many LOCs can be thrown out.

It's a Wayland problem if it is really problem at all though. The author complains that XCursor themes take too much space on disk (They will live uncompressed in VRAM anyways). Considering we are talking about Megabytes in the age of Terabytes HDDs, as long as you don't want to install thousands of XCursor themes on the same machine this is really a non-issue.