Freaky
Joined 18 years ago
Karma
1,399
Submissions
520
Member since
Aug 24
I run http://freshbsd.org/
View on Hacker NewsRecent submissions
Comment · 1 month ago
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/sComment · 1 month ago
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.
Comment · 3 months ago
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.
Comment · 5 months ago
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 :)
Comment · 5 months ago
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.
Comment · 5 months ago
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.
Comment · 2 years ago
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.
Comment · 2 years ago
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
Comment · 3 years ago
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.
Comment · 3 years ago
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.
Comment · 3 years ago
> 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.
Comment · 3 years ago
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.
Comment · 3 years ago
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?
Comment · 3 years ago
> 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.
Comment · 3 years ago
They insist on adding it to the standard response path, but they're happy for you to remove it:
header -Server