Vorpal

I would go back to your CAD model and tweak it for better printability. If it was a model you downloaded and without a source CAD model I would just remodel it myself to be more printable.

I too run an Arch and am happy with it, and I would like to know why Cachy. The only reason I can see is having x86-64-v3 packages instead of baseline. That is nice, but on it's own doesn't feel worth the effort of switching over.

Defaults don't matter to me much, as I automate and manage my system config in git (using a tool I wrote myself: https://github.com/VorpalBlade/paketkoll/tree/main/crates/konfigkoll inspired by https://github.com/CyberShadow/aconfmgr). It makes it a breeze to set up a new computer as I want it.

The solution is to not use Http based validation of the cert, but use dns based validation. Possibly combined with a wildcard cert for your whole domain. This is what I do for internal services on my LAN, along with split DNS so that the internal services aren't even listed in public DNS.

Agreed, I run arch on my desktop and laptop, because it is more stable (in the sense of fewer bugs, things like suspend/resume works reliably for example) than any other distro I have used.

But on my VPS and my Pi I run Debian because it is more stable (in the sense of fewer upgrades that could break things). I can enable unattended upgrades there, which I would never do on my Arch system (though it is incredibly rare for those to break).

Also: if someone said they were a (self proclaimed) "semi noob" I would not recommend Arch. I have used Linux since 2002, and as my main OS since 2006. (Furthermore I'm a software developer in C/C++/Rust.) While Arch is a great distro, don't start with Arch.

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?

That seems to be for dns resolving, not for ddns? Or am I missing something?

Most registrars also run DNS servers as part of the fee you pay for the domain. Usually they have an API. You can just use that to implement Dynamic DNS, there are even often tools for it. Do a search for your DNS registrar and dyndns.

Afraid.org is better than DuckDNS. (DuckDNS is not reliable and have been slow or down a lot.)

But it is still American.

12th verse: I’m sane, I promise

Hmm...

As to LLVM and alloca, it doesn't optimise or even work well in practise. Some basic cases work, others are less well tested. There are lots of "should" that "doesn't" in practice in LLVM.

I have not looked at alloca in LLVM myself but from what I have heard from those who are experts on this, it is quite brittle.

Second of all: sub is my favourite allocator

https://docs.rs/bumpalo/latest/bumpalo/ (and bump allocators in general).

Fourth of all: second point is literally a skill issue idk, especially if your compiler is already proving bounds anyway.

In general proving bounds for stack growth is very difficult. With recursion it is undecidable. This follows directly from Rice's Theorem. (This is my favourite theorem, it is nice to know that something is impossible rather than a skill issue.)

(Of course you could have a static analyser that instead of yes/no returns yes/no/don't know, and then you assign don't know to be either of the other classes depending on if you care more about false positives or false negatives. This is how the rust borrow checker works: forbid if it can't prove it is safe, but there will be safe code that it doesn't allow.)

Alloca for buffers is generally a bad idea:

• If you have an upper known bound, just use that. If you don't you risk stack overflow. Especially on a malicious input.
• Alloca optimises poorly (especially with LLVM) since the compiler can't really see how large the stack frame is.

The only reasonable usage I have seen is in the Swift ABI. See this blog post on the topic by a rust compiler developer: https://faultlore.com/blah/swift-abi/ (and even there it is only for some cases that it can be used).

Not really. Heapless uses compile time sized backing buffers to implement Vec, string etc with a max upper size. You would typically use heapless with a statically allocated variable, but it is possible to use it on the stack too.

Alloca is different and allocates a dynamically sized block on the stack. Rust doesn't really support alloca, but there is a crate for it that works by calling through a helper function in C: https://lib.rs/crates/alloca

Also worth noting is smallvec and compact_str crates. These are useful when you most of the time have small data that you want inline, but are OK with falling back to heap allocation for the occasional outlier.

I have used both inside structs to optimise cache usage. For these uses i tend to use rather short smallvec.

And smallvec in particular is also useful on the stack in a larger variant in hot functions where you might have a Vec that almost always is less than (say) 32 elements, but the program should gracefully handle the occasional long case. I found this offered a small speed up in some batch data processing code I wrote.

• https://docs.rs/smallvec
• https://docs.rs/compact_str