Freaky

Mirrored the way I implemented status=progress in FreeBSD dd, though there the flag was set by a SIGALRM timer: https://freshbsd.org/freebsd/src/commit/4767c42c1146459eb751...

It would appear GNU dd 9.9 still does a call for every block. Low-hanging fruit if anyone fancies it:

     dd if=/dev/zero of=/dev/null count=100000000 status=progress
    51200000000 bytes transferred in 18.644004 secs (2746191200 bytes/sec)

     target/release/dd if=/dev/zero of=/dev/null count=100000000 status=progress
    51200000000 bytes (51 GB, 48 GiB) copied, 20.8772 s, 2.5 GB/s

     gdd if=/dev/zero of=/dev/null count=100000000 status=progress
    51200000000 bytes (51 GB, 48 GiB) copied, 23.6744 s, 2.2 GB/s

> $Id: stable.sgml,v 1.1 1996-02-11 00:16:17 jkh Exp $

> FreeBSD-stable is our development branch for a more low-key and conservative set of changes intended for our next mainstream release.

..

> If you're a commercial user or someone who puts maximum stability of their FreeBSD system before all other concerns, you should consider tracking <em>stable</em>

..

> Please note that the <em>stable</em> tree endevors, above all, to be fully compilable and stable at all times, but we do occasionally make mistakes (these are still active sources with quickly-transmitted updates, after all)

Indeed, the first step to tracking stable is to join the mailing list:

> <heading>Using FreeBSD-stable</heading>

> <p><enum><item> Join the freebsd-stable mailing list.

So the nature of the branch hasn't really changed, it's more that there's now much less reason to track it - we have regular patch releases, and the ports system no longer only supports CURRENT and STABLE.

All my code lives on the other end of a Samba share. Guess what doesn't work reliably.

Will definitely be trying out some of those :)

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.

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.

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

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.

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.

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.

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.

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

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.

    header -Server

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

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.

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)

App and keyfob-based 2FA is still free.

> 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.

- Chapter 17, A Deepness in the Sky

3,975 commits.

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.

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.

  block out quick on egress from any to <reddit>

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

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

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