Show newer

@xentrac I don't remember we talked about this, but OpenZFS 2.3+ should do reflinks fine (it's called feature@block_cloning).

I think more people should know about , which I learned about from @leah years ago.

(100% human-written prose. I use em dashes and bulleted lists because they make the prose clearer. Also, I like them.)

Immutable copy-on-write snapshots of things are kind of a superpower for computer systems design. (FP folks call this "persistence.") An awfully large fraction of computers' time is spent copying things from one place to another to keep them from changing. In a lot of cases, this is unnecessary, because they weren't actually going to change in the first place, but it can be hard to be sure in advance. If you have some kind of system that will copy *only* the things that get modified — or the *parts* of those things that get modified — it will often be much more efficient. So, in Linux, we use this a lot in copy-on-write memory mappings of files, process memory following a fork(), and things like that. rsync has a --link-dest option that allows multiple backups to share space while being just as convenient to use as regular non-incremental backups. There are many other examples.

Some OSes and some filesystems support making a copy-on-write "copy" of a file, sharing the space between the original file and the "copy" until and unless one of them change. This feature is usually called "reflinks" after the Solaris system call that supports it.

In particular:

On :
- Bcachefs,
- btrfs,
- XFS, and
- OCFS2.

But *not* OpenZFS.

On , neither OpenZFS nor .

On Solaris, ZFS (with `cp -z`).

On MacOS, APFS (which Apple is switching to; with `cp -c` or the `clonefile` system call)

And, on Microsoft Windows, NTFS and its DUPLICATE_EXTENTS_TO_FILE.

These are from Daniel Aleksandersen's 02020 blog post ctrl.blog/entry/file-cloning/. I don't think anything has changed on that front since then, which is sad, if true.

@maya @OmegaPolice @britter Most banking apps work on GrapheneOS but many have memory corruption bugs and incorrect anti-tampering code requiring our per-app exploit protection compatibility mode toggle.

Around 10% of banking apps are unavailable due to banning using a non-Google-approved OS. Around a dozen banking apps began specifically permitting GrapheneOS in addition to a Google-approved OS which is growing.

There's a good list based on ongoing user reports:

privsec.dev/posts/android/bank

I'm pleased to find that I have a Mathstodon account now. I'm trying it out, and I'm pleased with its \(\LaTeX\) support.

@shapr Anubis (and Hashcash) lacks a crucial thing that postage stamps supply: payment to the providers of the service being DoSed.

@shapr Yes, Anubis is the latest incarnation of Hashcash, but it probably is not strong enough to be effective against intentional attackers.

@shapr I've been enjoying reading the Durants' "Rousseau and Revolution"; evidently this was the case in France at the time too, and at times Rousseau couldn't afford to receive his mail.

@cr1901 And, of course, without any centrally trusted kernel, you can implement some kinds of capability systems with public-key cryptography, where it's not actually impossible to guess someone's private key, just conjectured to be too hard to have a significant probability of success within the next few billion years.

@cr1901 uses a different approach from : it lets you store the capability bits in normal memory, but it maintains a bitmap where you can't reach it which tells the CPU hardware which memory words contain capabilities. Only a small amount of code (as I understand it, the virtual memory code in the kernel) has the authority to set those bits on existing data. But I don't understand CHERI as well as seL4.

@cr1901 Unix file descriptors are capabilities. If you have an open file descriptor to a file, you can read and/or write to that file, regardless of what the filesystem permissions say. The operating system maintains an array of the inodes you have open on your behalf. To specify which file descriptor to operate on, you specify a numerical index into that list, such as "2". Guessing "2" won't give you access to anything you don't already have, and guessing inode numbers won't give you access to anything, because you can't open a file by inode number.

This is the same mechanism used in ocap systems like seL4, except that it calls your thread's associated array of generalized file descriptors a "CSpace".

@chemoelectric Yes, this is a very good technique. It is called "shallow binding" in Lisp, and it was crucial to efficient Lisp implementations when they used dynamic scoping. You may enjoy reading Baker's "Shallow binding makes functional arrays fast" from 01991: dl.acm.org/doi/pdf/10.1145/122

@raganwald Yeah, that's a big part of why I'm here. LI may be a requirement to find work nowadays, but I've never felt it was trustworthy, and the hard sells feel like constant harassment. The racism thing is an additional minus, but hopefully that's more "racists advertise on LI" than "racists run LI".

@cr1901 I anticipate a difficult debugging process that will force me to learn anyway. Too bad the bots can't tell me where my FPGA board went

@cr1901 Yeah, but one of the things I want to exist is platforms that aren't such a pain to bootstrap on. And it turns out that the bots are passable at basic Verilog, and I am not.

Show older
CleverLibre Social

CleverLibre Social is an inclusive social instance for open discussion, learning, and community.
All cultures welcome.
Hate speech and harassment strictly forbidden.