In this case “alt text” refers to Randall Munroe’s bonus punchlines he hides in the alt text on xkcd.org.
I’m not sure what people do there who need actual alt text.

Rust is faster than C. Iterators and mutable noalias can be optimized better. There’s still FORTRAN code in use because it’s noalias and therefore faster

But yeah I dunno in what cases rust is faster than C/C++.

First of all C and C++ are very different, C is faster than C++. Rust is not intrinsically faster than C in the same way that C is faster than C++, however there’s a huge difference, safety.

Imagine the following C function:

void do_something(Person* person);

Are you sure that you can pass NULL? Or that it won’t delete your object? Or delete later? Or anything, you need to know what the function does to be sure and/or perform lots of tests, e.g. the proper use of that function might be something like:

if( person ) {
  person_uses++;
  do_something(person);
}

...

if( --person_uses == 0 )
  free( person )

That’s a lot more calls than just calling the function, but it’s also a lot more secure.

In C++ this is somewhat solved by using smart pointers, e.g.

void do_something(std::unique_ptr<Person> person);
void something_else(std::shared_ptr<Person> person);

That’s a lot more secure and readable, but also a lot slower. Rust achieves the C++ level of security and readability using only the equivalent of a single C call by performing pre-compile analysis and making the assembly both fast and secure.

Can the same thing be done on C? Absolutely, you could use macros instead of ifs and counters and have a very fast and safe code but not easy to read at all. The thing is Rust makes it easy to write fast and safe code, C is faster but safe C is slower, and since you always want safe code Rust ends up being faster for most applications.

C/C++ isn’t really faster than Rust. That’s the attraction of Rust; safety AND speed.

Of course it also depends on the job.

https://benchmarksgame-team.pages.debian.net/benchmarksgame/box-plot-summary-charts.html

Zig!!

I feel tracked… Better strike this all through

Damn I was close. I knew it was something to do with filesystems. Thanks

This has nothing to do with Wayland, it’s just AppImages kinda sucking. Use Flatpak or the one in your distro’s repos, not the AppImage. AppImages are the equivalent of portable apps on Windows, like the single exe ones you’d put on a flash drive to carry around.

Also the AppImage developer is very against Wayland and refuses to support it, which is why Wayland support is a shitshow on AppImages.

If you pick the Flatpak it’ll get updated in the background, have a proper launcher and everything.

Do not download Firefox of the internet. Use your package manager or flatpak

It’s slowly happening. KDE can now do global Xwayland shortcuts, they also implemented XWaylandVideoBridge and compositor restart crash recovery for apps. We’re getting proper HDR, we have proper per-monitor refresh rates and VRR, I can even hotplug GPUs. Some of that stuff works better in XWayland because we can just run multiple instances with different settings. For the particularly stubborn cases, there’s rootful XWayland. X12 would have to break things too, and I doubt an Xorg rewrite would be all that much further than Wayland is. Canonical had a go at it too with Mir which was much less ambitious.

NVIDIA was right on that one indeed, but Wayland also predates Vulkan and was designed for GLES, pretty much at the tail end of big drivers and the beginning of explicit and low level APIs like Vulkan. They could very well have been right with EGLStream too, but graphics on Linux back then was, erm, bad. But in the end they’re all still better than the kludge that is 3D in Xorg.

It’s getting a lot of momentum and a lot of things are getting fixed lately. It went from unusable to “I can’t believe it’s not Xorg!” just this year for me. It’s very nice when it works well. We’ll get there.

I can’t up-vote this enough. The “architectural purists” have made the migration a nightmare. Always blaming everyone else for simply not seeing their genius. I’m honestly surprised it’s gotten as far as it has.

40 years old is also what makes it so hard to replace or even reimplement. The bugs are all decade old features, everything is written specifically for Xorg, all of which needs to be emulated correctly. It sure did serve us well, it’s impressive how long we’ve managed to make it work with technology well beyond the imagination of the engineers in the 80s.

There’s this for the protocols: https://github.com/probonopd/wayland-x11-compat-protocols

It can be done, it’s just nobody wants to do it. It’s not really worth the effort, when you can work on making it work properly in Wayland instead. That way you don’t need XWayland in the first place, but also XWayland can then implement it using the same public API everyone else does so it works on every compositor.

What we wanted: Wayland.

What we needed: X12, X13…

How is PulseAudio still there? I mean, sure the protocol is still there, but it’s handled by pipewire-pulse on most systems nowadays (KDE specifically requires PipeWire).

Also, PulseAudio was never designed to replace ALSA, it’s sitting on top of ALSA to abstract some complexity from the programs, that would arise if they were to use ALSA directly.

What’s wrong with it?

Would be a crazy expensive migration though

So much of that is PDP-11 baggage or derived from it.

Or more generally Very Small Disk baggage.

The only thing I personally dislike about systemd is the “waiting for service to stop 5mins/1h30mins” stuff during shutdowns and reboots. I know I can limit them to 10s or something but how about just making systemd force-stop these services like, say, runit.

When I’m using my bemenu script to shutdown and feel like a hackerman, don’t take that way from me by being an annoyance, systemd!!!

Edit: Yes, I’m considering switching to Void, how could you tell?