sprash

Agreed. The display in Jupyter should happen via some inline WebGL-shaders which would be instant rendering. Also the "marching qubes" algorithm to render the stl is not exactly state of the art (use at least octrees or something) and needs very high resolution to achieve good results.

I used to like OpenSCAD for its simple approach but then I discovered SDF-based modelling with Python made possible with this neat library: [1]. This is perfect if you are a programmer that doesn't know anything about CAD-Software.

1.: https://github.com/fogleman/sdf

When is China going to "acknowledge the truth about climate"? When it finished building the hundreds of planned coal power plants? This BS is all a pure geopolitics show with obvious traitors in power of western governments.

It's not that impressive if you consider that the current government in Germany is driving a massive de-industrialization campaign. Destroying the own car industry fits well in the agenda.

Most of the criticisms in this talk are solved with DRI3. Also this guy makes money with a consultant agency that mainly works on Wayland and indirectly profits from shitting on X11. This is not a neutral source.

X11 became really stable in the late 00s. And since the introduction of DRI3 it is at the same technological level of Wayland concerning the efficient buffer swap mechanism. X11 is however still miles ahead on the architectural level. Parts of the system like window managers or compositors can fail or be replaced at runtime without affecting running clients. Wayland lacks the appropriate standardized interfaces for that and there are not plans if not outright refusal to actually implement them.

By gold standard I actually mean no fractional reserve banking. The great depression was caused by the federal reserve. As soon as you have fractional reserve banking you allow over-leveraged debts which lead immediately to boom and bust cycles. If you want to avoid those cycles simply don't allow people to spend money they don't actually have and always settle payments as early as possible (also don't allow anybody to simply print money).

X11 is actually not really difficult to maintain. There is just no corporate funding anymore. Wayland is designed to be used in car entertainment systems. At least this is where most of the funding is coming from. As such it is completely unsuitable for any desktop use and has had zero community mind share in that space for a very long time.

The boom and bust cycles are artificial and are created entirely by the central bank. We can have continuous stable development and did have it when the gold standard was still a thing.

The work is not done for free. It is done by consultant agencies like Collabora with full time paid developers. It is just unclear who funds them.

And no, it's not worth it. The amount of regressions are high compared to the rather questionable security benefits.

> Collabora ports windows game to linux.

Not according to their references.

> They created SteamOS for Valve.

Obviously not. They created some parts of the update system for SteamOS 3.0.

Since this isn't a community effort at all but purely done by a consultant agency called Collabora my question would be, who is funding them?

This has been tried. All you will get is rejected pull requests. What makes it even worse is that GNOME has usurped many projects that were original not part of GNOME but that the community relies on (one example is the "GIMP Tool Kit"). This led to the death of many long tail niche projects which are the actual strength of Linux/FOSS.

There are several full time paid developers working on it which is plenty of resources (AFAIK more than KDE). They are not only actively user-hostile but also community-hostile. Every library or project they have under their umbrella receives updates all the time that only serve GNOME and potentially break all software dependent on it that are not part of GNOME (e.g [1]).

1.: https://github.com/thestinger/termite

Flatpak is essentially RedHat/IBM tech. Why should Canonical even think about supporting their competitors. Just because multi billion corps like RedHat/IBM have the audacity to ask for donations to develop their products doesn't mean Flatpaks are in any way neutral territory.

If payment is your main incentive to work on software you should stay out of the FOSS space. Go write your iPhone/Android app or sell your stuff on Steam. Another little insignificant app store won't convince Adobe or AutoDesk to port their stuff to Linux.

Does your motherboard have a parallel port header? Connecting some LEDs is trivial. Writing a short C program to display CPU utilization on LTP is not that hard either. There goes your weekend.

If you don't use your capslock/numlock/scrolllock on your keyboard you can use those LEDs to indicate hdd, network or even cpu activity (kernel must support it) by writing the appropriate command to the sys interface like this

    echo "disk-activity" | sudo tee /sys/class/leds/<your LED>/trigger

From Alphabet Inc to Alphabet Soup. Why not? The former is just a front of the latter anyways.

To me writing C is orders of magnitude easier because I almost instantly can see in my mind the resulting assembly code generated by the C code. In comparison Rust feels very opaque (e.g. A simple writeln expands into a rather large macro and who knows what the compiler is doing with that). I'm sure with more experience you can get better but why bother.

Even with just static analysis and some sane coding conventions you can get C on the same safety level of Rust. I see Rust as a huge waste of everybody's time and resources and far too opinionated in many regards.

This! If you really care about security you should educate people about how to use available tools to analyze C instead of relentless Rust evangelism.

People arguing that "you can not ever write safe C" might also come to the conclusion that one "unsafe" somewhere in your Rust code potentially means that the whole code base is immediately at the same level of implicit memory safety as C.

Even simpler is farbfeld which supports 16bit per channel + alpha. The header is nothing more than a magic string and image dimensions.

> Is there anything even remotely similar around?

There is GnuBee [1] with two models for 2.5" drives [2] and 3.5" drives [3].

1.: http://gnubee.org/

2.: https://www.crowdsupply.com/gnubee/personal-cloud-1

3.: https://www.crowdsupply.com/gnubee/personal-cloud-2

> No, all those can be solved with client libraries.

There is no easy way to open a Window and render a string. Period! You either need to write it yourself completely (as OP stated) or you can use Gtk/Qt or other heavy weight "client libraries" (cairo and freetype do not create Wayland windows and therefore are not applicable here).

Look at the code again! If you really think that the code at [1] is in any way a great solution as compared to [2] we are going to disagree.

> No, in both modern X11 or Wayland, you should use the same API for screenshots: the XDG screenshot portal.

ZERO screenshot apps on X11 use XDG screenshot portal, they all use XGetImage(). Mainly because the assumption that a dbus-daemon is always running everywhere is mostly false. Also XDG screenshot portal is simply not a good solution. It is cumbersome to use, contains tons of edge-cases and pulls a dbus dependency for something that could be solved much simpler with onboard OS-functionality without the need for extra daemons and weird binary protocols

> Client-side rendering is also the norm in X11, since decades ago when Xft was released

Besides the point, but you are still wrong. Xft does server-side rendering via XRender. The cache is rendered only once on the client but that's a technicality, spline tessellation was supposed to go into the server but Keith Packard had more important things to do at the time.

> there's nothing at the protocol level that prevents the long tail

Severe over engineering, unstable interfaces, massive boiler plate and huge development overhead is preventing the long tail "at the protocol level".

As example: Compare the Wayland "Hello World" [1] with X11 "Hello World" [2]. If you want to add the ability to take screenshots it gets exponentially worse. (Also the Wayland version is not even capable to render strings.)

1.: https://github.com/emersion/hello-wayland/blob/master/main.c

2.: https://rosettacode.org/wiki/Window_creation/X11#C

> "With Wayland, you handle everything, even with wlroots."

The observable effect of this is that the long tail of niche projects like X11 window managers, custom toolkits or small applications (that don't carry around extremely heavy dependencies like GTK/Qt) gets decimated. The assumption that this is done on purpose is plausible.

The Solution is very simple:

1. Scrap everything you have done so far and start over.

2. Use tried and tested engineering principles as basis for your development philosophy (such as "mechanism, not policy" or "Keep It Simple Stupid").

3. Choose the right target audience. The target audience of the FOSS-Desktop are neither car entertainment systems, nor Android consumer users that potentially download malware everyday. Your target audience are power users and developers that know what they are doing. If you don't agree, go work for a car manufacturer, work as an Android developer or do something else, just stay away from the FOSS-Desktop.

4. Do what developers and power users need! Just some examples: use simple and stable interfaces, use non-opaque low-level abstractions, standardize often used functionality, avoid redundant standards, don't litter my pstree with pointless daemons, use existing mechanism provided by the OS, use clear text for low bandwidth IPC, keep dependency trees as small as possible, keep build dependencies as small as possible, look at Plan9 as inspiration instead of Windows and MacOS.

This is interesting if you are after retro effects. State of the art dithering however works with blue noise threshold textures[1] because we have plenty of memory available these days. Here is a nice comparison of all kinds of dithering algorithms that also shows the clear superiority of blue noise dithering: [2].

1.: http://momentsingraphics.de/BlueNoise.html

2.: https://surma.dev/things/ditherpunk/

Not Semantics. It shows how Wayland forces a Gnome/GTK and KDE/Qt duopoly and cuts out the long tail of hobbyists and power users. The latter is the interesting part about the FOSS/Linux-Desktop ecosystem. With Wayland the FOSS-Desktop will be 100% corporate controlled. If essential things were properly standardized this wouldn't happen. Therefore it's obviously done on purpose as means for sabotage.

Yes. Wayland is a display protocol, not a general-purpose IPC. Hence it must contain access control interfaces for buffers.

Only the compositor has access to the composited image therefore is the only program able to make screenshots and full screen sharing. Furthermore, efficient sharing of single application windows is only possible with direct memory access to the buffer which also is something the compositor does/has. The Display protocol is the only sensible place to negotiate access to GPU resources.