HNHacker News
TopNewBestAskShowJobs

Freaky

1,399 karma · joined August 24, 2008

I run http://freshbsd.org/
submissionscomments
Freaky··on Ubuntu 26.10 completes transition to Rust-based coreutils
Neat. I touched this code about 8 months later to avoid the per-block elapsed() call: https://github.com/uutils/coreutils/commit/cf7b90bbe7cb87099...

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
Freaky··on FreeBSD 14.5-Release
The description of STABLE as a development branch to be followed with caveats, and that using it is an active process with risks you need to mitigate has been in the handbook since at least 1996 (https://freshbsd.org/freebsd/doc/commit/827b1b2b292dd02f9bc9...):

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

Freaky··on Zed DeltaDB
How about accommodating basic fundamentals like file change notifications not being universally reliable?

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

Freaky··on Webcam head tracking, webcam to control in‑game FOV
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 :)

Freaky··on Webcam head tracking, webcam to control in‑game FOV
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.

Freaky··on OpenFOV – Webcam head tracking for iRacing
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.

Freaky··on Amazon reveals first color Kindle, new Kindle Scribe, and more
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.
Freaky··on PHP 8.3
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

Freaky··on YJIT is the most memory-efficient Ruby JIT
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.

Freaky··on Songs of Syx: A city-builder with complex mechanics (2020)
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.

Freaky··on YJIT is the most memory-efficient Ruby JIT
> 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.

Freaky··on Java 21: The Nice, the Meh, and the Momentous
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.

Freaky··on Kopia: Fast and secure open-source backup software
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

Freaky··on Kopia: Fast and secure open-source backup software
> 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.

Freaky··on Caddy is the first and only web server to use HTTPS automatically and by default
They insist on adding it to the standard response path, but they're happy for you to remove it:

    header -Server
However as this isn't global configuration it'll tend to pop back up in implicit configs like HTTP redirects and error handling if not overridden.
Freaky··on Caddy is the first and only web server to use HTTPS automatically and by default
I'll see about getting it made the default for the FreeBSD port at least.
Freaky··on Caddy is the first and only web server to use HTTPS automatically and by default
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
Freaky··on ZFS for Dummies
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.

Freaky··on ZFS for Dummies
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)

Freaky··on X glitch wipes out most pictures and links tweeted before December 2014
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.

Freaky··on Jeremy Vaught spent 16 years to build @music on Twitter, then X took it away
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.

Freaky··on NASA mistakenly severs communication to Voyager 2
> 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

Freaky··on FreeBSD at 30: Its secrets to success
https://freshbsd.org/freebsd?q=%22Sponsored+by+Netflix%22

3,975 commits.

Freaky··on 55 GiB/s FizzBuzz (2021)
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
You can see they were all written in one go. When allocated a terminal, they come out line by line:

   $ 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
Rust lacks this adaptive behaviour for output, and will always produce the second result, terminal or not.

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.

Freaky··on OpenBSD: Shutdown/reboot now require membership of group _shutdown
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.

Freaky··on OpenBSD: Shutdown/reboot now require membership of group _shutdown
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.
Freaky··on Reddit.com appears to be having an outage

  block out quick on egress from any to <reddit>
It's for your own good.
Freaky··on It’s not wrong that "🤦🏼‍♂️".length == 7 (2019)
.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.

Freaky··on Linux tool to show progress for cp, mv, dd
I can find SIGINFO all the way back to 4.3BSD-Reno, released in 1990.
Freaky··on Emerging Rust GUI libraries in a WASM world
> 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...

Page 1 of 17Next →