In my experience, this happens in two ways. Yeah, sometimes a senior just overdoes it due to a lack of experience or shitty requirements or whatever.

But it also happens a lot that juniors just don’t understand why the layer makes sense to introduce. For example, juniors will readily intermix IO and logic, because they don’t yet understand that this makes code untestable and adds a load of additional complexity into already complex logic code. From that viewpoint, pulling all the IO code out will look like unnecessary complexity, when it’s not.

I find that it depends on how niche the distro is.

Somewhat obviously, niche distros don’t have as many resources out there to begin with.
This also means you’re unlikely to be told to research yourself.

But users of niche distros also made a conscious choice to be on that specific distro and therefore tend to be more enthusiastic. Both, about helping others who made the same choice, but also about fixing problems or at least documenting a workaround for the distro that they plan to stay on for the foreseeable future.

Well, and due to survivorship bias, folks on niche distros tend to also be Linux experts, who can solve virtually any problem, given enough motivation.
If you find a kind soul, they will walk you through hell and back, which is worth so much more than any documentation in the world.

Python without UV/Conda is always somewhat of a pain on Linux, well, if you need a specific version that is. It comes pre-installed on virtually all distros, because the distros use it themselves to script stuff in the OS. That also means, if you install a different Python version OS-wide, you can break those OS scripts.

Admittedly, it is somewhat of a larger pain on Debian, though, because it will stay behind on older Python versions for longer than most other distros. After the Python 2→3 transition, they also continued to alias python to python2 for quite some years (I’m actually not sure, if they alias to python3 by now)…

Yeah, I mean Cinnamon matches what Windows does really quite closely, down to even the default keyboard shortcuts being virtually the same.

KDE doesn’t match it quite as closely, but it’s just power-user heaven…

One time, I got delivered teaspoons instead of spoons, because I couldn’t tell the difference from the picture (and the description did not bother mentionuing that at all).

Another time, I got delivered light bulbs the size of a toddler’s head, because the manufacturer decided to use a picture of a regular-size bulb. Well, and in the online store, the size only got mentioned as actual width/height values in the details.

But yeah, we do already have the technology to place a banana next to your product, and to take photos from all angles. Manufacturers and stores just don’t see enough of a benefit from actually doing that, so have a singular picture in a white void, which shows a different product. You’re welcome! 👍

With RickyRigatoni’s idea, it wouldn’t be a videogame. It would be a separate program you launch specifically to order things online. It just happens to use a game engine for its implementation, because game engines are the most advanced simulation tool humanity has developed…

I enjoy this comment. I don’t even know, if I’d rank NixOS as S-tier in general, but because I can handle it, yeah, don’t really have a reason to bother with other distros…

I mean, NixOS has lots of weird “defaults” in that sense, too. 🙃

Yeah, fair enough. I was thinking in terms of the more general-purpose text formats. I have heard good things about QML, too…

Eh, I don’t think it’s the be-all and end-all of describing user interfaces, but it deals well with the deep nesting that UIs generally have, and the attributes allow throwing in metadata for certain elements, which is also something you frequently need in UIs.

At the very least, JSON, YAML, INI and TOML would be a lot worse.

Personally, the zero-setup filesystem snapshotting was a big argument for it. I do not want to use an OS anymore, which does not have snapshotting or an equivalent.

Thankfully, this is becoming more commonplace, but for years, openSUSE was the only player in that game.

I can’t imagine the country matters.

Do you just not have the “User Interface…” menu entry?

Hmm, that’s weird. Are you on a semi-recent version of LibreOffice? I believe, it got shipped with version 6.0.

And just to be sure, you are checking here, right?:

Well, HTTP + HTML+JS+CSS. The “World Wide Web”, if you will.

You can switch to the “Tabbed” interface for something more similar MS Office: https://books.libreoffice.org/en/WG252/WG2521-UserInterfaceVariants.html#toc6

Okay, dude, glad to have talked.

Link for those wanting to subscribe from other instances: [email protected]

Having to make a decision isn’t my primary issue here (even though it can also be problematic, when you need to serialize domain-specific data for which you’re no expert). My issue is rather in that you have to write this decision down, so that it can be used for deserializing again. This just makes XML serialization code significantly more complex than JSON serialization code. Both in terms of the code becoming harder to understand, but also just lines of code needed.
I’ve somewhat come to expect less than a handful lines of code for serializing an object from memory into a file. If you do that with XML, it will just slap everything into child nodes, which may be fine, but might also not be.

Ah, well, as far as XML is concerned, yeah, these are very different things, but that’s where the problem stems from. In your programming language, you don’t have two variants. You just have (person (name "Alice") (age 30)). But then, because XML makes a difference between metadata and data, you have to decide whether “name” and “age” are one or the other.

And the point I wanted to make, which perhaps didn’t come across as well, is that you have to write down that decision somewhere, so that when you deserialize in the future, you know whether to read these fields from attributes or from child nodes.
And that just makes your XML serialization code so much more complex than it is for JSON, generally speaking. As in, I can slap down JSON serialization in 2 lines of code and it generally does what I expect, in Rust in this case.

Granted, Rust kind of lends itself to being serialized as JSON, but well, I’m just not aware of languages that lend themselves to being serialized as XML. The language with the best XML support that I’m aware of, is Scala, where you can actually get XML literals into the language (these days with a library, but it used to be built-in until Scala 3, I believe): https://javadoc.io/doc/org.scala-lang.modules/scala-xml_2.13/latest/scala/xml/index.html
But even in Scala, you don’t use a case class for XML, which is what you normally use for data records in the language, but rather you would take the values out of your case class and stick them into such an XML literal. Or I guess, you would use e.g. the Jackson XML serializer from Java. And yeah, the attribute vs. child node divide is the main reason why this intermediate step is necessary. Meanwhile, JSON has comparatively little logic built into the language/libraries and it’s still a lot easier to write out: https://docs.scala-lang.org/toolkit/json-serialize.html

Alright yeah, I half-expected as much when I wrote that sentence. Surely someone will post about a webpage they found, or will source something from e.g. Wikipedia. But well, hopefully it still happens less often, or at least there’s less of an expectation that you look at linked webpages. 🫠