Signal is pretty good.

XOR lists are obscure and cursed but cool. And not useful on modern hardware as the CPU can't predict access patterns. They date from a time when every byte of memory counted and CPUs didn't have pipelines.

(In general, all linked lists or trees are terrible for performance on modern CPUs. Prefer vectors or btrees with large fanout factors. There are some niche use cases still for linked lists in for example kernels, but unless you know exactly what you are doing you shouldn't use linked data structures.)

EDIT: Fixed spelling

It is common custom to indicate quotes, with either "quotes" or for a longer quote a

block quote

The latter can be done by prefixing the line with a > here on lemmy (uses the common markdown syntax).

Doing either of this help avoid ambiguity.

I don't know the answer (I don't care about numlock myself), but the arch wiki has an article on this: https://wiki.archlinux.org/title/Activating_numlock_on_bootup

Perhaps that will be useful to you. In general checking the arch wiki is a good idea for any Linux issues, even if you don't run arch, many things still apply to other distros and the articles are of very high quality.

In this case, "Early bootup (mkinitcpio)" would likely not apply to most other distros that aren't based on Arch, but the rest looks to apply widly.

It is worth noting that in the KDE section it mentions the need to apply two settings, perhaps that could be it?

I have read it, it is a very good book, and the memory ordering and atomics sections are also applicable to C and C++ since all of these languages use the same memory ordering model.

Can strongly recommend it if you want to do any low level concurrency (which I do in my C++ day job). I recommended it to my colleagues too whenever they had occasion to look at such code.

I do wish there was a bit more on more obscure and advanced patterns though. Things like RCU, seqlocks etc basically get an honorable mention in chapter 10.

Yes, Sweden really screwed up the first attempt at switching to Gregorian calendar. But there were also multiple countries who switched back and forth a couple of times. Or Switzerland where each administrative region switched separately.

But I think we in Sweden still "win" for worst screw up. Also, there is no good way to handle these dates without specific reference to precise location and which calender they refer to (timestamps will be ambiguous when switching back to Julian calendar).

That assembly program the author compares to is waay bloated. This guy managed with 105 bytes: https://nathanotterness.com/2021/10/tiny_elf_modernized.html (that is with overlapping part of the code into the ELF header and other similar level shenanigans). ;)

All kidding aside, interesting article.

Swedish layout. Not ideal for coding (too many things like curly and square brackets etc are under altgr. And tilde and backtick are on dead keys.

But switching back and forth as soon as you need to write Swedish (for the letters åäö) is just too much work. And yes, in the Swedish alphabet they are separate letters, not aao with diacretics.

I don't feel like rust compile times are that bad, but I'm coming from C++ where the compile times are similar or even worse. (With gcc at work a full debug build takes 40 minutes, with clang it is down to about 17.)

Rust isn't an interpreted or byte code compiled language, and as such it is hard to compete with that. But that is comparing apples and oranges really. Better to compare with other languages that compile to machine code. C and C++ comes to mind, though there are of course others that I have less experience with (Fortran, Ada, Haskell, Go, Zig, ...). Rust is on par with or faster than C++ but much slower than C for sure. Both rust and C++ have way more features than C, so this is to be expected. And of course it also depends on what you do in your code (template heavy C++ is much slower to compile than C-like C++, similarly in Rust it depends on what you use).

That said: should we still strive to optimise the build times? Yes, of course. But please put the situation into the proper perspective and don't compare to Python (there was a quote by a python developer in the article).

I really don't see what niche it is trying to fill that isn't already occupied.

Rust is as successful as it is because it found a previously unoccupied niche: safe systems programming without garbage collector and with high level abstractions that (mostly) optimise away.

I don't think "better C" is a big enough niche to be of interest to enough people for it to gain a critical mass. I certainly have very little interest in it myself.

Be sure to treat state and configuration separately. It doesn't matter on Windows as far as I know (they go in the same location), but on Linux those are supposed to go in different places.

Many programs get this wrong, and it is quite annoying as I track my config files in git. I don't want a diff just because the list of recently opened files changed! Or even worse: the program stores the last window size and position in the config file... (looking at you KDE!)

Here are some libraries I found to help with this in a cross platform way:

• https://lib.rs/crates/dirs
• https://lib.rs/crates/directories

I haven't tried either, haven't written such a program yet.

As for how to store data, there are indeed many options, depending on your needs:

• Plain text based formats (toml, yaml, JSON, ini, ...) can be good for configs and basic state. As a bonus it let's the user easily manage the file in version control if they are so inclined.
• Databases (SQLite mostly)
• Custom formats (binary files in a directory structure is often used for browser caches for example) .

Without knowing more it is hard to give specific advise.

A few crates do document this, but it is often missing indeed.

Sometimes I have seen it documented as comments in Cargo.toml as well.