Vorpal

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

What about the UV cured polymer that dentists use? Surely that is relatively safe, though probably way too high viscosity. (Note: While I know a fair bit about FDM, I'm not at all read up on SLA, so I may be completely wrong here.)

Let's Encrypt is meant yo be used with automated certificate renewal using the ACME protocol. There are many clients for this. Both standalone and built into e.g. Caddy, Traefik and other software that does SSL termination.

So this specific concern doesn't really make sense. But that doesn't mean I really see a use case for it either, since it usually makes more sense to access resources via a host name.

Thanks, didn't think about that. Two reasons I can think of:

• Vase mode should reduce stringing on TPU as it avoids retractions. Though I have found that just drying TPU + enabling "avoid crossing perimeters" usually hides most stringing.
• Additionally, it would let you have more precise control over how squishy/firm the TPU part is by adjusting the number of perimeters. Though you can use modifier volumes in the slicer to adjust infill and number of perimeters locally in a part.

Is there any other reason why this is good for TPU that I missed?