Yeah, I doubt WebAssembly when executed in a browser will become multi-threaded anytime soon, since JavaScript is single-threaded just as well. If you need multiple threads, you need to use web workers. Haven’t done anything with those yet, but I’d assume them to be usable from WebAssembly as well, since the whole JavaScript API seems to be accessible.

Well, and in Rust, I’m pretty sure the runtime that’s typically used for async stuff (tokio) will produce a compile error, if you try to enable the “multi-thread” feature flag on the WebAssembly target.
But yeah, might be more of a problem with other languages.

LibreOffice has a way to switch to a sidebar UI. I always preferred that, because of what you describe…

Well, part of the problem is that web apps themselves are kind of alien on the web. The web is generally document-based. Web apps take the document format and try to turn it into something it’s not.
There’s a way to not do the JavaScript, but it doesn’t fix things being document-based and it can be argued that it makes other things worse in some respects.

I’m talking about WebAssembly. Basically, you can write your web app in HTML+CSS+Rust and then the Rust part is compiled to WebAssembly, which then takes the role that JavaScript would normally take. It does not have to be Rust, lots of languages can be compiled to WebAssembly, but Rust has the most mature ecosystem for that, as far as I’m aware.

In principle, it is also possible to use WebAssembly to render directly to a pixel buffer, but that’s really rather heavyweight and not terribly responsive, so not generally done, unless you implement a game¹ or similar.
Alright, so back to the document mangling approach. There’s various frameworks available for Rust. I’ve used Leptos so far. There’s also Dioxus and Yew and probably others.

Advantages:

• Don’t have to write JS.
• Can write Rust. Rust has some concepts that mesh really well with frontend dev, like the Result and Option types for error handling, which you can pass directly to your rendering stack and it can show either the data or the error (or nothing).
• Can use the same language in backend and frontend and therefore also get compile-time checks that the two work together.

Disadvantages:

• The ecosystem is young. You will find barely a fraction of the component libraries as you can find for JS.
• Rust also has concepts which don’t mesh well with frontend dev, like the whole memory management concept. Those frameworks bypass that or make use of it in clever ways, but things can be a bit peculiar or overly complex at times.
• WebAssembly is sent to the browser in one big blob, because it’s a compiled program. This means you get somewhat of a loading time when first loading the web app. There’s ways to mitigate that with “hydration” strategies, but yeah, still a thing.
• While JS is often minimized/uglified and therefore not readable anyways, WebAssembly makes that even more of a reality, because it is essentially assembly code that’s sent to the browser. It does still call the same APIs under the hood as JS does, so content blocking shouldn’t be affected, but yeah, can’t try to understand the code itself. This can also make debugging during development somewhat more painful.
• Well, and it’s also yet another web standard that browsers have to support. It doesn’t make browsers simpler in the sense that suckless would like.

I’ve listed a lot of disadvantages, so just to point out that, yes, to me, the advantages are absolutely worth it. But I can totally understand, if others see that differently.

¹) See, for example, Bevy and this UI example in particular.

Yeah, I’m honestly a bit confused. I have basically the same paper bin and it’s not heavy at all. I’d expect a cat to be able to knock that over no problem. Like, maybe it doesn’t try to while you’re around, because it might fall over with the bin or hit itself with it, but I wouldn’t expect a real troublemaker to worry about that either…

The thing is, everyone would agree that it’s a strength, if the Debian-specific format was provided in addition to a format which runs on all Linux distros. When I’m not on Debian, I just don’t get anything out of that…

Damn, seems you’re right. For folks reading along: That’s not how that word usually works in German, but I guess, it is how it works in German legalese…

Yeah, Wikipedia tells me the longest word that was actually in use is Grundstücks­verkehrs­genehmigungs­zuständigkeitsübertragungs­verordnung. It was a decree from 2003 until 2007.

Basically:

• “Grundstück” is a plot of land.
• “Verkehr” is traffic “trade” in this context.
• “Genehmigung” is approval.
• “Zuständigkeit” is responsibility.
• “Übertragung” is transfer.
• “Verordnung” is decree.

So, it decreed that the responsibility of approving traffic on trade of private plots of land should be transferred (to a different government body).

Well, the thing is, if you’re developing a library, you usually do so, because you want it to be useful to people in the ecosystem.
By putting it under the GPL, you limit that usefulness to only those projects which are willing to also put themselves under the GPL. From an idealist point of view, I certainly also would like to say that people not willing to put their software under GPL don’t need to be my users. But from a library author point of view, I might as well not write a library then, since no one’s going to use it then.

Many open-source projects are under a permissive license themselves. I might disagree with their choice, but I don’t really want to exclude those from using my library. They’re still doing good things. I would love to exclude specifically any proprietary software from using my library, but that’s not really something you can require in your license without excluding all those permissive open-source projects.

So, to answer your question, I actually don’t think people are being tricked into it. I thought about choosing GPL for my libraries for a while (all my applications are under GPL) and decided against it. Which is a personal choice that others can disagree with, but all I’m saying is, I know what I’m doing, I wasn’t tricked to use a permissive license.

Yeah, I just put my whole collection on shuffle and have come to appreciate the simplicity of that.

I use this web music player at home, which only supports shuffle and because it’s a web thing, I can’t either use keyboard shortcuts to skip songs (without switching to that window).
And I actually like that I can’t distract myself with selecting just the right music. Because if I don’t distract myself and just get into coding or whatever, I’ll quickly stop noticing what precise music is playing.

Larger open-source projects tend to have forums. Here’s a few off the top of my head:

• https://forum.luanti.org/
• https://tavern.dcss.io/
• https://users.rust-lang.org/ (and https://internals.rust-lang.org/ )
• https://forums.opensuse.org/

You’d typically want Kate rather than KWrite, if you’re gonna do development. Basically the same editor, but with more power-user features.

Same. I guess, this is the Starship thread now. My config:

I adapted it from the Gruvbox Rainbow theme.
I can post my config, if anyone wants specifically that. (It does kind of assume a light background, though.)

Yeah, not a lot of distros they could’ve based it on, which are less rooted in the EU. 🫠

GIMP is generally geared towards photo-editing, so if you have an existing image, you can use GIMP quite well to e.g. cut out parts of it or to apply effects.
It’s not really geared towards digital painting or creating new images from scratch, like Krita and presumably IbisPaint are.

Yeah, that’s kind of the advantage and disadvantage of Markdown. It’s so simple that alternative implementations can be easily created, which helps with adoption. But because those alternative implementations exist and because there is a need to add more features, those alternative implementations will see custom changes for the format, ultimately making the format less standardized.

Yeah, it doesn’t make a whole lot of sense here. Codeberg uses a Markdown flavor which honors single line breaks and it kind of surprised me how well that is working. Like, if you’re used to Markdown, you can put those two spaces and they’re just ignored. If you’re not used to Markdown, it works like you’d expect.

I guess, the downside is that either each client needs to configure their Markdown renderer to behave like that, or I guess, the server software has to pre-process the Markdown to add in the double-spaces.
That’s more of a problem for Lemmy than it is for Codeberg, because there is a number of different clients available.

It’s the way Markdown works, for reasons, which is what Lemmy uses for its comment syntax.

If you want a regular line
break, you can put two spaces
at the end of a line.

Well, my initial reaction was “What year is it?”. As far as I’m aware, this practice has largely fallen out of favor in the industry. And it’s been more than a decade since the last GTA release, so their stance might have changed in a similar vein, or at least their management would have likely changed.

Neat, thanks for the response!

I think, we have to tag @turtle@lemm.ee , so they see it.

Hmm, but that seems to be again that there’s actually fields there, rather than proper nothing. At the very least, I would still say that the universe already existed before the Big Bang, if there was fields spanning all over the place and they just needed quantum fluctuation to turn into something you can touch. Especially, because “touch” is still just an interaction with a field.

And I’m not trying to say that the phenomenon itself is pop-sci misinformation, but rather how it’s portrayed. They’ll write a title like “How Quantum Fluctuation Creates Something from Nothing”, which is technically something you could say, because “nothing” doesn’t have a sharp definition. But it’s also misleading as people will not think that “nothing” could also mean that there is actually still fields there. Instead, they will interpret it as proper nothing. And pop-sci journalists do that, because it brings in clicks, unfortunately.