swap files make setting up hibernation a bit more complicated - in most cases the file has to be contiguous, e.g. you have to defragment it once after allocating. Then, you need to tell the bootloader the byte offset of the file on the partition.

Does contiguousness matter these days? Especially since all disk locations are lies anyway as SSD firmware has its own layer of indirection too?

In this case, IIUC the swap-restore mechanism just can’t use fragmented files because it runs before filesystem drivers can do their work. So it just gets an offset and probably derives the length from a header stored there, using raw disk accesses to thaw the RAM contents.

In general terms though, I hear disk fragmentation still makes a difference, f.ex. because disk page sizes don‘t match filesystem extent sizes, and disk optimizations like prefetching or even garbage collection work better with contiguous data.

If you want to share step-by-step, I’ll update the gist.

That’s my point, it’s different for each distro & partitioning setup, so I wouldn’t know what to share here. Having a swap partition makes it as easy as adding `resume=/dev/sdXYZ` or `resume=UUID=…` to your kernel parameters.

And using LVM for "partitioning" bypasses a lot of this silliness. Do 'lvcreate --contiguous' and you should be good to go if you're using most any non-toy initrd.

Given that every r/w filesystem you're going to use as your '/' on a Linux desktop or server supports online growing (and most support offline shrinking), it's nuts to me to hear people worrying about getting partition sizes correct. With LVM, if you get it wrong you just resize the LV and the filesystem it contains.

Hell, LVM makes swapping out disks a really easy online operation. [0] If you don't have nice hot-swap drive caddies, you might have to power off the box once to add in the new disks and again to remove the old ones, but all the data transfer can happen while the system is in use.

[0] Assuming the new and old disks have the same logical sector size, which they usually do.

It‘s going to be a godsend for people with M1 macs when Apple or App vendors decide to drop support for them.

The hardware is super capable and will make a great fileserver, TV box or HomeAssistant instance once I‘m done using it as daily driver.

Similarly, because of distros like Fedora and Ubuntu, I can keep using a 15y old Samsung notebook with a modern firefox, whereas Windows 8 already broke Samsung‘s display brightness driver and thermal management, and 10&11 are entirely unusable.

Demand would go down, so meat companies would reduce breeding to reduce output. Or start an ad & lobbying campaign to increase demand again.

A couple years ago, I was at a station waiting for a (delayed) ICE train. I couldn't buy a ticket at the machine or with the app, since the train had already departed (if it had been on schedule). The ticket machine also wouldn't take VISA / MasterCard, only the more common Girocard (most people still call it EC)

Later, in the train, when I asked the conductor to buy a ticket with my Girocard, he said "That's not a commonly used payment method" and asked for VISA, or cash (not having any to provide change, obviously).

For other readers' benefit: Girocard is not related to Girobank https://en.wikipedia.org/wiki/Girobank or using said Girobank's Girocard to pay bills or collect dole.

If my math is right, that gives you 83 clock cycles to calculate a single sample. on a 16 core, theoretically 1333 cycles. that‘s not a lot, considering you don‘t nearly 100% of the cpu all the time.

That same graph had me jump towards the sampling theorem - playing back an animation with linear interpolation creates hard edges, e.g. frequency spikes. I‘m not sure if the movement space is comparable to audio here, but I can‘t see why not.

so; if the sampling theorem applies; having 2x the maximum movement „frequency“ should be enough to perfectly recreate them, as long as you „filter out“ any higher frequencies when playing back the animation by using something like fft upscaling (re-sampling) instead of linear or bezier interpolation.

(having written this, I realize that‘s probably what everyone is doing.)

Most languages with macro or templating should be able to define this behavior as a library. Rust and C++ come to mind, for example.

Can you provide an example of a Rust HTTP routing library that can generate a compile-time error for overlapping routes?

I don't know of one, but you seemed to doubt not that it's actively being done, but that it's even possible, which is a very different proposition.

Remember C++ actually implements checks at compile time for the modern std::format function. That is, if you mess up the text of a format string so that it's invalid, C++ gives you a compile time error saying nope, that's not a valid format.

You might think that's just compiler magic, as it is for say printf-style formats in C, but nope, works for custom formats too, it's (extremely hairy) compile time executed C++.

is this satire? I honestly can’t tell.

It is, and blatently so.

Fellow German here, I’ve experienced a total of ~2 hours, in one single outage, about 20 years ago. Not even a single brownout since.

What are the golang- packages about in OpenSUSE? Go doesn‘t support dynamic linking (except for non-go-pieces like glibc or via cgo). Do they contain source-code? Or pre-built .a‘s? Both would have a hard time not conflicting with go‘s own build tooling, right?

I've just installed `golang-github-burntsushi-toml` that should be the well known Go TOML library; asking `rpm -q -l` shows mainly `*.go` files, thus I assume they are mainly used as build dependencies?

Hmm… That makes sense. Though if you are building from source, the only gain you have over regular go tooling is downloading from your favorite mirror rather than github&co. I hope it doesn’t install these source-packages for prebuilt binaries…

I believe they don't allow internet access during the build (so everything needs to be vendored, or things stuck into GOPATH); those packages are probably for the second option.

My impression is that OpenSUSE go packaging is a bit behind though. But I'm not an active packager so this may have been fixed.