Freaky

Ooh, awesome. I was literally just thinking the other day that it was a shame on-foot head tracking games pretty much started and ended with ArmA 3, because it's great both for situational awareness, and for just plain gawping at stuff.

Will definitely be trying out some of those :)

I guess so, given I have my TrackIR in a box!

That said, I have had issues with opentrack that involved some mildly irritating troubleshooting. Namely X4: Foundations didn't work properly with the standard freetrack output regardless of how I configured it, and I ended up needing to use "UDP over network".

I've never had a comparable problem with TrackIR, in spite of using it with a wider variety of titles over a longer period. I do kinda like having it as a backup in case more intractable problems crop up.

opentrack would be the one to beat these days: https://github.com/opentrack/opentrack

It's completely replaced my TrackIR 5, since it averts the need to wear headphones and dig out the tracking bracket every time I want to use it, and the accuracy feels about the same.

I found head tracking pretty much becomes second-nature after a while - to the point at which it feels weird to play first-person sims without it. Not quite as fancy as VR, but much more comfortable and much more practical.

I too have the previous generation Paperwhite and it's a laggy piece of junk. About the only thing it's even remotely zippy at is flicking through pages rapidly when I accidentally brush my wet hand against the stupid touchscreen while I'm in the bath.

Looks like my fix for CPU feature detection under clang made it in, so such builds should now have much faster addslashes/base64/etc.

They're still disabled by default on FreeBSD - my PR is pending, and the patch has been in testing in ports for a while: https://github.com/php/php-src/pull/12288

It appears to have a cool-sounding JIT server mode, allowing multiple clients to share a caching JIT compiler which does most of the heavy-lifting:

https://www.usenix.org/conference/atc22/presentation/khrabro...

https://developer.ibm.com/articles/jitserver-optimize-your-j...

It also has a "dynamic AOT compiler", so first-run stuff can be JITed and cached for future execution instead of it all starting out interpreted every time.

In addition to being a great game, I also find Syx technically impressive - in a genre where it's so common to start running into serious performance problems with just two or three digit populations, Syx still zooms along effortlessly as you approach five. I believe its pop cap is 40,000 units.

I'm sure they're greatly simplified in comparison - it isn't trying to simulate complex interpersonal relationships or painstakingly track everyone's hair growth, but they still have a decent amount of detail to them given the scale.

The demo is just an older version of the full game (usually lagged behind 3 major releases, not sure where it is now, I think it's more up to date?) - and far from making it feel like I didn't need to pay for the thing to enjoy it, it instead made it an easy buy.

We were very generous in terms of warm-up time. Each benchmark was run for 1000 iterations, and the first half of all the iterations were discarded as warm-up time, giving each JIT a more than fair chance to reach peak performance.

1,000 iterations isn't remotely generous for JRuby, unfortunately - JVM's Tier-3 compilation only kicks in by default around 2,000, and full tier-4 is only considered beyond 15,000. I've observed this to have quite a substantial effect, for instance bringing manticore (JRuby wrapper for Apache's Java HttpClient) down from merely "okay" performance after 10,000 requests to pretty much matching the curb C extension under MRI after 20,000.

You can tweak it to be more aggressive, but I guess this puts more pressure on the compiler threads and their memory use, while reducing the run-time profiling data they use to optimize most effectively. It perhaps also risks more churn from deoptimization. I kind of felt like I'd be better off trying to formalise the warmup process.

It's rather a shame that all this warmup work is one-shot. It would be far less obnoxious if it could be preserved across runs - I believe some alternative Java runtimes support something like that, though given JRuby's got its own JIT targetting Java bytecode I dare say it would require work there as well.

I encountered a weird bug with deserializing JSON in a JRuby app during an OpenJDK upgrade - it would sporadically throw a parse error for no apparent reason. I was upgrading to OpenJDK 15, but another user experienced the same regression with an LTS upgrade from 8 to 11.

The end result of my own investigation led to this quite satisfying thread on hotspot-compiler-dev, in which an engineer starts with my minimal reproduction of the problem and posts a workaround within 24 hours: https://mail.openjdk.org/pipermail/hotspot-compiler-dev/2021...

There's also a tip there: try a fastdebug build and see if you can convert it into an assertion failure you can look up.

FreeBSD had a pretty decent option in the base system two decades ago - FFS snapshots and a stock backup tool that would use them automatically with minimal effort, dump(8). Just chuck `-L` at it and your backups are consistent.

Now of course it's all about ZFS, so there's at least snapshots paired with replication - but the story for anything else is still pretty bad, with you having to put all the fiddly pieces together. I'm sure some people taught their backup tool about their special named backup snapshots sprinkled about in `.zfs/snapshot` directories, but given the fiddly nature of it I'm also sure most people just ended up YOLOing raw directories, temporal-smearing be damned.

I know I did!

I finally got around to fixing that last year with zfsnapr[1]. `zfsnapr mount /mnt/backup` and there's a snapshot of the system - all datasets, mounted recursively - ready for whatever backup tool of the year is.

I'm kind of disappointed in mentioning it over on the Practical ZFS forum that the response was not "why didn't you just use <existing solution everyone uses>", but "I can see why that might be useful".

Well, yes, it makes backups actually work.

Also, it's unclear to me what happens if you attempt a snapshot in the middle of something like a database transaction or even a basic file write. Seems likely that the snapshot would still be corrupted

A snapshot is a point-in-time image of the filesystem at a given point. Any ACID database worth the name will roll back the in-flight transaction just like they would if you issued it a `kill -9`.

For other file writes, that's really down to whether or not such interruptions were considered by the writer. You may well have half-written files in your snapshot, with the file contents as they were in between two write() calls. Ideally this will only be in the form of temporary files, prior to their rename() over the data they're replacing.

For everything else - well, you have more than one snapshot backed up, right?

1: https://github.com/Freaky/zfsnapr

Unfortunately, this is not true. You need to grab all the DB files (WAL, etc.) in a consistent manner. You can't grab them while writes are in progress.

Perhaps you could be more specific, because the former is exactly what a filesystem snapshot is meant to do, and the latter is exactly what an ACID database is meant to allow assuming the former.

Look at what Kanister does with its recipes to get consistent DB snapshots

I looked at a few examples and they mostly seemed to involve running the usual database dump commands.

They insist on adding it to the standard response path, but they're happy for you to remove it:

    header -Server

I'll see about getting it made the default for the FreeBSD port at least.

Caddy also supports Unix sockets, which should be rather more difficult to smuggle requests to, and can be protected by file permissions:

    admin listen unix//var/run/caddy/admin.sock

I make remote snapshot backups with Borg using this: https://github.com/Freaky/zfsnapr

zfsnapr mounts recursive snapshots on a target directory so you can just point whatever backup tool you like at a normal directory tree.

I still use send/recv for local backups - I think it's good to have a mix of strategies.

Nice, you reminded me of my own incomplete Rust rewrite of the Ruby ZFS snapshot script I wrote about a decade ago, and this bit of yak shaving that ended up derailing me: https://github.com/Freaky/command-limits

I ended up finishing neither, and should pick them back up!

(I snapshot in big chunks with xargs to try to minimise temporal smear - snapshots created in the same `zfs snapshot` command are atomic)

SMS 2FA was put behind the paywall - ostensibly because they saw "bad actors" abusing it, but more likely because it costs money to send text messages and they're bleeding like a stuck pig thanks to Musk.

App and keyfob-based 2FA is still free.

https://twitter.com/jeremyvaught/status/1687444457837187072

Oh wow, I didn't even think to look up the alternatives they were offering. THEY ARE ALREADY USED AS WELL! So if I choose one, I'll be complicit in stealing more accounts.

Take the Traders’ method of timekeeping. The frame corrections were incredibly complex—and down at the very bottom of it was a little program that ran a counter. Second by second, the Qeng Ho counted from the instant that a human had first set foot on Old Earth’s moon. But if you looked at it still more closely. . .the starting instant was actually some hundred million seconds later, the 0-second of one of Humankind’s first computer operating systems.

- Chapter 17, A Deepness in the Sky

https://freshbsd.org/freebsd?q=%22Sponsored+by+Netflix%22

3,975 commits.

C and Python have adaptive buffering for stdout: if the output is a terminal they flush on newlines, otherwise they only flush when their internal buffer is full.

Here's a C program counting, with a 1ms delay between lines. The second column is a duration since the previous read():

   $ ./out | rtss
   4.7ms    4.7ms | 1
   4.7ms          | 2
   4.7ms          | 3
   4.7ms          | 4
   4.8ms    exit status: 0

   $ rtss --pty ./out
   0.8ms    0.8ms | 1
   1.9ms    1.1ms | 2
   3.0ms    1.1ms | 3
   4.1ms    1.1ms | 4
   4.3ms    exit status: 0

Technically it unconditionally wraps stdout in a LineWriter (https://doc.rust-lang.org/std/io/struct.LineWriter.html), which always flushes if it sees a write containing a newline. To maximise throughput you therefore want to batch writes of multiple lines together, for example by wrapping it in a BufWriter.

OpenBSD is unique amongst the BSDs in that its halt(8) and reboot(8) commands use the rc(8) system to shut down services gracefully, so the only thing you're missing is scheduling and shutdown message broadcasts.

Elsewhere those commands simply broadcast SIGTERM/SIGKILL to all processes, so you should use shutdown(8) unless you're in single user mode.

poweroff(8) has halt/reboot semantics on NetBSD, but shutdown semantics on FreeBSD/etc.

Is this not just a cosmetic thing? Xfce wants to know if you have shutdown permissions so it can render the right buttons for what you can do, but so long as the code isn't running privileged it's not actually going to let you do anything — it'll just run /sbin/shutdown fruitlessly.

  block out quick on egress from any to <reddit>

.each_codepoint.size is more efficient than .codepoints.size, as it creates a sized Enumerator that avoids needing to build an intermediate Array. For strings with only single-byte characters it reduces to returning the already-stored stored byte length.

Same goes for .each_byte.size, but for that you have the faster .bytesize method that avoids the intermediate Enumerator.

I can find SIGINFO all the way back to 4.3BSD-Reno, released in 1990.

Dear ImGui has a special 'ListClipper' class which allows to iterate over the visible 'slots' of a list, so that the code which describes the list UI can skip clipped items early. Not sure if egui has something similar.

An egui ScrollArea can request only visible rows from a callback using show_rows:

https://docs.rs/egui/latest/egui/containers/scroll_area/stru...

Reflinks are basically CoW hardlinks — supported on Linux by btrfs, XFS, and I've seen some effort to bring it to ZFS.

DragonFlyBSD's HAMMER filesystem supports on-demand/scheduled dedup using the hammer(8) command, with configurable memory and runtime limits.

Its main benefit is it's memory-hard in addition to time-hard. You're not just repeating a hash function across a few dozen bytes a few thousand times, you're doing it over tens or hundreds of MB, thus making it much harder to scale up an attack.

Correct Horse Battery Staple 4 lg(100000) = 33

I think you mean 66. More realistically, 52 for Diceware's 7776-word dictionaries, or 44 for XKCD's 2000 common words.