Busy Beaver gets a lot of love, but the fast growing hierarchy is both constructive and can go way, way, waaaaay beyond current known BB bounds. This makes their size much more viscerally apparent than gesturing vaguely at BB(BB(BB(100))) or whatever, IMHO.
David Metzler has this really cool playlist "Ridiculously Huge Numbers" that digs into the details in an accessible way:
By the end, you're thinking about functions that grow so fast TREE is utterly insignificant. Surprisingly, getting there just needs a small bit of machinery beyond Peano Arithmetic [0].
Then you can ponder doing all that but making a tiny tweak by replacing succesorship with BB. Holy cow...
Only the part for which we have well-defined fundamental sequences is constructive. As far as I know, there is no such system of FS defined up to
PTO(Z_2), the Proof Theoretic Ordinal of second order arithmetic, while growth rate at that ordinal can be programmed in under 42 bytes.
> waaaaay beyond current known BB bounds
I have to disagree here. The Proof Theoretic Ordinal of ZFC + infinitely many inaccessibles can be reached with a program under one kilobyte in size, and that is already extremely high up into the FGH.
By default, you get snapshots every minute for the last hour, every hour for the last day, and every day into perpetuity. This is configurable. You can set as many cadences as you wish, with the ability to configure their frequency and lifetimes.
Actually, snapshots are like btrfs volumes in many ways, meaning they can be mounted, read from, and written to as desired. This allows the filesystem root to just be another snapshot with a default backup cadence as described above.
The gefs(4) manpage [0] has more info for those interested. It's a short and sweet read. The source [1], is under 12k lines of well-written code, comments and whitespace included. The author is also extremely responsive to issues and a pleasure to talk shop with.
Anyway, given the parsimony of the OS and the small community size, I find 9front to be a really nice incubator for playing around with new ideas.
FWIW that snapshot system sounds almost the same as zrepl with zfs. The only difference being the zfs snapshots are read-only so you'd have to do a zfs send+recv to a dataset to mount it read/write. That and the defaults for the tiered snapshotting are different (mine is set to a snapshot every hour for the past day and every day for the past 2 weeks but I don't know what the default is).
zfs clone creates a writable dataset initially backed by a snapshot (and will prevent that snapshot from being deleted without first deleting the clone, even if entirely ship-of-theseused out of sharing any data with it)
IIRC, K rationalizes arrays and dictionaries with functions, e.g. you see arr[x;y] and fun[x;y]. Interestingly, this also highlights the connection between currying and projection, i.e. we can project/curry the above like arr[x] and fun[x].
Googol, googolplex, Graham's number, Ackermann's function, TREE, BB, Rayo's number ... For some reason big numbers seem to tickle some childlike fascination in me.
I randomly stumbled across this series that incrementally walks through the construction of truly gargantuan (computable) numbers. The fact that this touches on deep areas of math feels unexpected and fascinating.
> This is by design. ... The federal government was never intended to lord over everyone's lives.
So behavior of the system fails to meet its design goals? It honestly sounds like you kind of agree with the excerpt you quote.
> The expansion of the federal government ... [is] what needs to change
What are you proposing though? Even assuming the premise here, achieving said goals requires changes to lots of little details and incentives. It's not like there's a single potentiometer controlling Gov't Size™. So what are you actually suggesting?
Certainly, the details of fundamental electoral structure engage deeply with the operation of our government, and the legal scholars in the article seem to be honestly pointing out levers (and big ones at that) we could possibly pull to create a less expansive federal government, or whatever the goal may be.
Imagine a plane crashes and analysts start attempting a root cause analysis, discussing control system specifics and whatnot. To me, your stance reads like "This is by design. Plane parts are united but independent. Control systems were never intended to lord over every part of the plane. The expansion of control systems is what needs to change."
I mean... maybe? But even if we agree on that point, any random contraction of the control system seems unlikely to make a plane that flies better. We have to actually engage with the details of what's going on here.
It actually has quite good UX affordances. More than that, however, I find the code imminently hackable, even as someone with very little Prolog experience. Reading through the plwm code really demystified the apparent gap between toy and practical Prolog for me. Heck, even the SWI-Prolog codbase itself is quite approachable!
I'm also mildly surprised at some of OG's gripes. A while back, I ran through Triska's The Power of Prolog[0], which crisply grounds Prolog's mental model and introduces standard conventions. In particular, it covers desugaring syntax into normal predicates, e.g. -/2 as pairs, [,]/2 as special syntax for ./2 cons cells, etc. Apparently, I just serendipitously stumbled into good pedagogical resources!
I'd be interested in ways that people utilize logical programming concepts and techniques into non-LP languages.
Last year I picked up a bamboo Hemi and worked through the (70yo!) workbook. The trigonometric scales are cool. Making a single slide to find all the sides of a triangle is surprisingly satisfying. It got me to realize that, sliderules with the right scales can solve the roots of any 3-variable equation. I guess this is why there was a proliferation of industry-specific sliderules back in the day.
More generally, aren't simple, well-engineered analog tools so satisfying?
That's so cool. Like mathematical primitive archeology. The history of these sorts of analog computing devices that physically encode non-linear mathematical relations is fascinating.
With much tutoring, I learned to use a sextant and doing that gives one some sense of the "sorcery" and power achievable with blue-water navigation.
Boyer and Merzbach cover some of the development of these tools in their "History of Mathematics". Highly recommended.
One of my favorite pieces of software is edbrowse[0]. Perhaps surprisingly, I find it quite useful:
- Main developer is blind, so accessibility has priority;
- Easily scriptable; think automating captive portal clickthroughs;
- Reading articles (e.g. Wikipedia) feels closer to reading a book;
- It even supports JavaScript to a degree!
- The affordances of line-oriented editing carry over nicely.
In particular, when using line-oriented interfaces, it's quite natural to build up a small collection of context-dependent snippets from documentation, source code, sample code, whatever. Putting a small collage of these on the screen is effortless and an experience I do miss with other UI paradigms.
The main developer appears to tinker on the project daily and is quite nice to chat with over on libera's #edbrowse. The project does have a small, dedicated following, but I wish more people knew about it!
edbrowse is awesome. I fear that most people, like OP in this case, don’t really understand the difference between "TUI" (where a terminal is used to display a GUI) and "CLI", where every interaction is a written command resulting in a output.
I’ve a perfect sight myself but I really like the comfort of linearity with CLI: I ask my computer something, I receive an answer.
(that’s probably why I’m developping my own CLI browser but is more graphical and less advanced than edbrowse)
> I fear that most people, like OP in this case, don’t really understand the difference between "TUI" (where a terminal is used to display a GUI) and "CLI", where every interaction is a written command resulting in a output.
I'm not sure how you could infer that, since OP didn't mention "TUI" or "GUI" or "CLI" anywhere in this post, and a text-based browser UI could come in either form.
So based on the first paragraph, I would’ve assumed “CLI” and “graphical” were mutually exclusive? Did you in fact mean to type “TUI” here? Or is your program something like a hybrid between command-based input and graphical output?
No, Offpunk it's command line driven, it just happens it can output images due to sixel support (and maybe in a near future with the w3m's image displaying tool).
> Main developer is blind, so accessibility has priority;
Never thought about it before, but doing development work as a blind person sounds extremely impressive.
Vision is just such a fast and easy way to acquire information. Without it, it seems quite difficult to check your existing code, easily read prior documentation, take notes, and just various other conveniences that one take for granted.
I'm sure there are various tools and methods to ameliorate these problems, but still.
I usually go with w3m for my weirder needs that lie somewhere between a pure HTTP client and a regular web browser, this seems like it might be even more convenient sometimes.
> The history directory contains information on the history of edbrowse, how it came to be and what it is trying to accomplish. This includes a wikipedia article, written in markup. It was deleted by the wikipedia maintainers, for lack of sources. If edbrowse is described in a book or mainstream magazine in the future, perhaps this article can be reintroduced
I think you nailed the drive behind my ~3 decades of Emacs use: "I can get at all the text" (possibly above the customization/automation benefits despite this being the "advanced" pov above "it's just a text editor isn't it?"
I used to use that to fetch odd Japanese translated ROMs from CD Romance. Inb4 some Copyright holder says "buy them legally"... these games won't be released in the West ever.
In Europe most people played Earthbound (and USA only releases for SNES/MD) under emulators. That's how Nintendo put it in the Super Smash Bros roster. They say the hate emulation; but these tools cemented themselves into retroemulation like no other system, and helped to bring new sagas to the West. For free. You say you lost money because of retro-piracy? You got free marketing for physical scraps technically resting in a warehouse.
Altough nowadays I'm 100% pro libre gaming; tons of indie/FOSS philosophy overlap: FreedroidRPG, Battle for Wesnoth, Nethack/Slashem, ReTux, SuperTux2...
Back to edbrowse, it's a mail, irc and SQL client too; and you can script it, a la ed/vi, so you can do magic here.
One use case I've not seen covered is sending blobs asynchronously with forward secrecy. Wormhole requires synchronously communicating the password somehow, and Signal requires reasonable buy-in by the recipient.
Basically, I'd like to just email sensitive banking and customer data in an encrypted attachment without needing to trust that the recipient will never accidentally leak their encryption key.
One of the projects I alluded to in that post makes a technological solution to what you want easy to build, but the harder problem to solve is societal (i.e., getting it adopted).
My current project aims to bring Key Transparency to the Fediverse for building E2EE on ActivityPub so you can have DMs that are private even against instance moderators.
One of the things I added to this design was the idea of "Auxiliary Data" which would be included in the transparency log. Each AuxData has a type identifier (e.g. "ssh-v2", "age-v1", "minisign-v0", but on the client-side, you can have friendly aliases like just "ssh" or "age"). The type identifier tells the server (and other clients) which "extension" to use to validate that the data is valid. (This is to minimize the risk of abuse.)
As this project matures, it will be increasingly easy to do this:
// @var pkdClient -- A thin client-side library that queries the Public Key Directory
// @var age -- An implementation of age
async function forwardSecureEncrypt(file, identity) {
const agePKs = await pkdClient.FetchAuxData(identity, "age");
if (agePKs.length === 0) {
throw new Error("No age public keys found");
}
return age.Encrypt(file, agePKs[0]);
}
And then you can send the encrypted file in an email without a meaningful subject line and you'll have met your stated requirements.
(The degree of "forward secure" here depends on how often your recipient adds a new age key and revokes their old one. Revocation is also published through the transparency log.)
However, email encryption is such a mess that most people don't quite appreciate, so I'm blogging about that right now. :)
David Metzler has this really cool playlist "Ridiculously Huge Numbers" that digs into the details in an accessible way:
https://www.youtube.com/playlist?list=PL3A50BB9C34AB36B3
By the end, you're thinking about functions that grow so fast TREE is utterly insignificant. Surprisingly, getting there just needs a small bit of machinery beyond Peano Arithmetic [0].
Then you can ponder doing all that but making a tiny tweak by replacing succesorship with BB. Holy cow...
[0]:https://en.wikipedia.org/wiki/Theories_of_iterated_inductive...
reply