Freaky

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.

This is why I made https://github.com/Freaky/zfsnapr

Instead of working out how to teach my backup tools about snapshots, I just mount them in a subtree and use that as a chroot env.

XKCD estimated 11 bits per "common word", corresponding to a dictionary of ~2000. But that's assuming even distribution across that dictionary, which isn't a reasonable thing to expect a human to do themselves.

Diceware - an actual formalisation of the approach, including recommended means of generating the entropy and specific wordlists - uses 7776 words, for a shade under 13 bits each. EFF have a nice one - https://www.eff.org/dice

The recommended 6 words gives 77.5 bits of entropy per password. At Lastpass's current default iterations of 100k that's about 2^93 SHA256 operations to have better than even odds of breaking it.

To put that into perspective, the Bitcoin mining network is reportedly hashing at 256 quintillion hashes per second right now. At that rate it would take on average 72 weeks to crack.

One extra word bumps that up to 11 millennia, if that's a bit too tractable for comfort.

The default handler for SIGINFO is a non-fatal process summary, like this (from FreeBSD):

    load: 0.15  cmd: sleep 52109 [nanslp] 0.27r 0.00u 0.00s 0% 2132k
    mi_switch+0xc2 sleepq_catch_signals+0x2e6 sleepq_timedwait_sig+0x12 _sleep+0x1d1 kern_clock_nanosleep+0x1c1 sys_nanosleep+0x3b amd64_syscall+0x10c fast_syscall_common+0xf8

SIGUSR1's default is to terminate the process, which makes it awkward to use as a SIGINFO alternative on platforms without it.

Twitter's infamous for encoding video into little more than mildly suggestive compression artifacts.

Here's a 4k60 YouTube video: https://youtu.be/VGnuGnOWeTE?t=605

borg-backup.sh, which runs my remote borg backups off a cronjob: https://github.com/Freaky/borg-backup.sh

zfsnapr, a ZFS recursive snapshot mounter - I run borg-backup.sh using this to make consistent backups: https://github.com/Freaky/zfsnapr

mkjail, an automatic minimal FreeBSD chroot environment builder: https://github.com/Freaky/mkjail

run-one, a clone of the Ubuntu scripts of the same name, which provides a slightly friendlier alternative to running commands with flock/lockf: https://github.com/Freaky/run-one

ioztat, a Python script that basically provides what zfs-iostat(8) would if it existed: https://github.com/jimsalterjrs/ioztat

Many of Peter Watts books and short stories - including Blindsight, and the short story set in the same universe "The Colonel" - are free to read on his website: https://www.rifters.com/real/shorts.htm

There's also a non-free sequel novel - Echopraxia - together making the Firefall series.

Be sure to check out the "Vampire Domestication" multimedia presentation on that page, for some background on the "vampires" in the series.

I wrote https://github.com/Freaky/zfsnapr a few months ago so I could finally have point-in-time consistent Borg backups with ZFS snapshots, without having the mess of teaching Borg where every .zfs directory was.

It recursively snapshots mounted pools, and recursively mounts snapshots of the mounted datasets into a target ready to point your backup tools at. I do so via a chroot so I didn't need to make any changes to my Borg setup - just to how I run it.

A great deal of the benefit of Option comes from where it isn't used - you know most things can't be null and simply don't have to think about the possibility.

unwrap() bugs are annoying, yes, but at the end of the day they're just a fancy assert(), helpfully spelled out in the code and confined to bits of it where the value is Option<T>. This is a much better situation than a language where nulls can in principle turn up anywhere.

> A delightful take from a non-Western newsmonger, using the language the West uses when analyzing corrupt far-flung lands

Author has a vast megathread on Twitter using similar language: https://twitter.com/gathara/status/1351038226581118986

"Winter storm batters huge swathe of covid-ravaged, politically troubled US, as it struggles to emerge from deadly coup amid dire humanitarian crisis that has killed nearly 500,000 and left one in seven households, including 18 million children, without enough to eat."

Here's what I'm using: https://gist.github.com/Freaky/b5cd807d518a176298c1d0e612dcc...

No, the benefit of the GMMK Pro is supposed to be build quality. There are plenty of cheap hot-swap boards about.

I'm using a Hexgears K705A - it cost me £60, with BOX White switches and cheap double-shot ABS keycaps. That's less than a bare non-pro GMMK. I replaced the keycaps with a pretty expensive set of sculpted PBT's and it still worked out less than a bare GMMK Pro.

And my space bar doesn't stick :P

Each server does share a "proto env" object, but it is duplicated for each Client:

https://github.com/puma/puma/blob/0cc3f7d71d1550dfa8f545ece8...

and Client objects are not reused:

https://github.com/puma/puma/blob/0cc3f7d71d1550dfa8f545ece8...

It certainly has a fast path, it just mixes it up with lseek() for filesystems like /proc: https://github.com/coreutils/coreutils/blob/9de1d153f82243ae...

FreeBSD just uses fstat: https://github.com/freebsd/freebsd-src/blob/e4b8deb222278b2a...

Having written a Rust wc implementation a few years ago (https://github.com/Freaky/cw), I had a look at theirs.

It's pretty naive - a simple linewise read_until loop, a conditional to avoid word splitting and such if it's not needed, and for some reason it collects results into an array and prints when it's done rather than printing as it goes.

It doesn't support --files0-from like GNU wc, so isn't a drop-in replacement from that perspective. It also has the sadly common Rust trope of only supporting filenames that are valid UTF-8.

It doesn't seem overly slow considering its simplicity - usually trading blows with GNU and BSD wc. Perhaps the most glaring omission is the lack of a fast path for -c, which should reduce to a stat() call. Also unfortunate not to use the excellent bytecount crate to provide a very fast -l/m path.

The read_until loop also makes its memory use unpredictable compared with other wc's. If you run it on /dev/zero it will try to eat your computer.

Nothing so fancy.

Each worker thread runs in a loop executing a queue of jobs. On every iteration it sets an atomic progress flag to true.

The runtime in which it's contained polls its workers every 1-10ms, atomically swapping in false and checking to see if the previous value was also false - if so, it steals its task queue and spins up another worker to execute it.

https://github.com/async-rs/async-std/blob/ceba324bef9641d61...

Read the first sentence.

> This blog post describes a proposed scheduler for async-std that did not end up being merged for several reasons.

I don't think it's a particularly good idea in the first place - it's basically an automatic watchdog-driven block_in_place(). It doesn't remove the problem of blocking in futures, it just limits the damage to the local task rather than blocking the entire executor.

That's fine in the simple case of future-per-task, but it's pretty common to be polling multiple futures concurrently within one, so it's not a general solution.

It's beaten by half a dozen sync Ruby implementations, which should be a pretty good hint that something else is going on.

Lack of HTTP keep-alive is probably the most obvious thing holding it back.

Probably the lack of HTTP keep-alive support - it's explicitly disabled due to bugs in the older HTTP library the stable version uses (seen as a large number of errors in previous rankings), so each request needs a new TCP connection.

https://github.com/TechEmpower/FrameworkBenchmarks/blob/f340...

Further reading - uggcf://ra.jvxvcrqvn.bet/jvxv/Yvdhvq_qebcyrg_enqvngbe

Only handles a single symbolic name per commit, and doesn't necessarily pick one that's meaningful in that sense. It's what I'm trying to get away from.

e.g. projects/aio_writev has 8 commits, but if name-rev is allowed to name that branch, it'll gleefully use it to name thousands of commits to main as well.

No. The problem is that to git, a branch is just a reference to the commit currently at the tip of that branch - the rest of the commit graph is completely anonymous sans its position in that graph.

Where in SVN it's implicit in the paths a commit touches and in CVS it's a specific field in the RCS metadata for a commit, in Git it's a big graph problem it isn't overly interested in solving.

And yes, people keep asking about the legacy username thing - I'll get to it :)

As the maintainer of FreshBSD.org, git gives me headaches regarding what to do with branch naming.

SVN and even CVS include branch information on each commit, but git couldn't care less - it's up to you to infer it by unspecified means if you really care.

It's telling that the conversion metadata includes tags indicating the SVN path identifying the branches a given commit was made from - because this otherwise wouldn't be available. In principle I can just use that, but I still need a reliable solution for new commits.

Not convinced I'll find one.

> Any command that evaluates to a valid path will automatically change the current working directory to that path

You can get similar behaviour on Unix shells with options like:

• zsh: `setopt auto_cd`

• bash: `shopt -s autocd`

• tcsh: `set implicitcd`

I think fish has it by default but only for paths prefixed with tilde, ., /, etc.

> I guess what I don't understand then is what big advantage "enterprise ECC" has left over this DDR5 "non-enterprise ECC"

ECC should be end-to-end, so it detects and (hopefully) corrects errors anywhere along the path, not just within a chip.

Step 1 of handling a lot of ECC correction events is to reseat the DIMM, because often it's just an issue with the connection, not actually a memory defect.

And you may not care too much about reports of correction events, but you definitely want to see correction failures reported - the point is, after all, to avoid corruption.

One I made in async Rust: https://github.com/Freaky/tarssh

I currently have 22 clients stuck it in across three machines. When I started out it was more like a thousand, so seems they've largely adapted.

... and it's useful how? It obscures the assignment at the end of an arbitrarily long statement instead of giving the value a name right up front.

It feels a bit like a new method definition syntax that allows you to put the name after the `end` for... reasons.

Yes, to highlight that this "horrible rigmarole" and "irritation" you describe is entirely on the basis of there being a Perl script involved. Something I suspect the majority would overlook without even really noticing.