Ooh, in Dungeon Crawl Stone Soup, when trying to enter the ability menu, it may tell you straight-up:

Thanks, game. Rub it in, why don’t you? 🥹

Oh man, I don’t want to get deep into all the politics involved, but man, this reads like complete non-sense:

The outage comes following Iranian attacks on the UAE as retaliation for US and Israeli strikes on Iran.

If they did specifically target US corporations in UAE, that would make some amount of sense as direct retaliation.
I guess, you can also attack UAE and hope that they pressure the US to stop invading.
But in any case, this seems like a really good way to drag more nations into the conflict, or at least to force them to become active, which is not in the interest of Iran.

Oh man, seeing folks suggest it as a Discord alternative always had me uninterested, because I don’t even use Discord and it just seemed like yet-another-standard.
Now I’m reading this really technical title for a talk which mentions XMPP and I’m instantly sold.

Well, to be honest, “Movim” also sounded like a VC-funded startup. Looks like it’s a bus-factor-of-1 open-source project instead, which I have significantly more trust in.

^This comment is talking about the deluge of log messages you may or may not see (depending on the distro) while booting the system.

Just thought I’d add that, since the meme doesn’t actually mention booting. Not sure, where you got that from. 😅

Yeah, but he has stated that he really doesn’t have an opinion. He just happened to install Fedora on the family PC a long time ago and now he neither wants to deal with two separate distros, nor switch the whole household over.

I also really hate that since AI slop has turned search engines useless, you virtually cannot find anything, even if you remember the exact words of the title.

Yeah, extremely cheesy way of putting it: The best work position is the next one.

I.e. don’t stay in one position for a long time, but rather switch it up regularly.

Well, I assume they had other concerns, too. For example, it adds a bunch of complexity for reformatting a JSON from single-line to pretty-print, if comments can appear in there. I’m certainly not saying that I’m always best friends with the decision to remove comments, just that I can somewhat understand it.

I can understand the sentiment and would 100% agree for programming languages.
But personally I actually like that it encourages a flat structure, because you do not want to be yakshaving the structure of your config file. Too much nesting means you will sooner or later run into configuration keys being nested under the wrong category, because your project context changed over time.

And well, as I’ve argued in a few other comments already, I think non-techie users have a disproportionally simpler time when no nesting is used. They understand the concept of a heading and then just adding a line underneath the appropriate heading is really intuitive.
You can just tell them to add the line certificate="/tmp/cert.crt" under [network.tls] and they will find a line in their config file which actually reads [network.tls] and they can just paste that line as-is.

With nesting, they’d need to add it under here:

network: {
    tls: {
        certificate: "/tmp/cert.crt"
    }
}

Which means:

• You need some awkward explanation where they should nest it, or an explanation that e.g. “network.tls” translates to nesting.
• They will ask whether they should indent the line you sent them.
• Well, and it’s also surprisingly difficult to explain between which braces they should put the text, and that’s at the end of the braces, but not after the braces etc., if you’re talking to them on a call.

It’s not even that I’m completely enamored with TOML, but this aspect is certainly growing on me…

VSCode is Electron, i.e. a webpage, so it’s not hugely surprising that they opted for the natively supported JavaScript Object Notation. And also shows that they don’t care for using the right tool for the job to begin with.

Personally, I much prefer TOML over YAML, because it does not have significant whitespace, and because you can read the spec in a reasonable amount of time. It just has so much less complexity, while still covering the vast majority of use-cases perfectly well.

They’re not supposed to contain data, but some parsers will allow you to access what’s written into comments. And so, of course, someone made use of that and I had to extract what was encoded basically like that:

<!--
    Host: toaster,
    Location: moon,
-->
<data>Actual XML follows...</data>

My best guess is that they added this data into comments rather than child nodes or attributes, because they were worried some of the programs using this XML would not be able to handle an extension of the format.

We just document that this is how you write the config file:

[network]
bind.host = "127.0.0.1"
bind.port = 1234

# etc.

And that seems straightforward enough. Yeah, technically users can opt to use inline tables or raw strings or whatever, but they don’t have to.

I can kind of understand it after having to work with an XML file where users encoded data into comments for no good reason. But yeah, it does make JSON awkward for lots of potential use-cases.

I don’t feel like it will stray very far from what’s dubbed “TOML 0.1” in the meme. Yes, it has inline tables and as of TOML 1.1, they’re allowed to span multiple lines, so it’s technically not anymore illegal to do what’s in the meme. But all things considered, this is still a miniscule change compared to TOML 1.0.

Well, you can still decide how much of the TOML features you actually use in your specific application. For example, I’m currently involved in two projects at $DAYJOB where we read TOML configurations and we don’t make use of the inline tables that OP memes about in either of them.

Ultimately, the big advantage of TOML over INI is that it standardizes all kinds of small INI extensions that folks have come up with over the decades. As such, it has a formal specification and in particular only one specification.
You can assume that you can read the same TOML file from two different programming languages, which you cannot just assume for INI.

I would try to avoid driving over them when safely possible, because they make an annoying noise, which I wanted to spare folks living nearby from. ¯\_(ツ)_/¯

Well, Wikipedia does say:

The [TOML] project standardizes the implementation of the ubiquitous INI file format (which it has largely supplanted[citation needed]), removing ambiguity from its interpretation.

https://en.wikipedia.org/wiki/TOML

Counterpoints:

• TOML is intended for configuration, not for data serialization, so you shouldn’t be sending it over the wire in all too crazy ways anyways.
• Most protocols will have a built-in way of knowing when the whole content has been transferred, typically by putting a content length into the header.
• Having to wait until the closing } or ] can also be a disadvantage of JSON, since you cannot stream it, i.e. start processing the fields/elements before the whole thing has arrived. (You probably still don’t want to use TOML for that, though. JSONL, CSV or such are a better idea.)

Well, TOML is essentially just an extension of the INI format (which helped its adoption quite a bit, since you could just fork INI parsers for all kinds of programming languages).

And then, yeah, flattening everything is kind of baked into INI, where it arguably made more sense.
Although, I do also feel like non-techies fare better with flat files, since they don’t have to understand where into the structure they have to insert the value. They just need find the right “heading” to put the line under, which is something they’re familiar with.

They serve largely different use-cases. JSON is good for serializing data. TOML is good for configuration.