abathur

Sure! Something date-based is a simple way to handle perpetual storage while keeping the active history set from over-growing.

I did anything at all because the default shell profiles in macOS can cause history loss, and I'd found my last straw. I put them in sqlite because--if I was bothering to build something bespoke--I wanted to track more command-time context to build tooling around later. (Including to play with some ~curation ideas.)

I might have decided to just use Atuin if it existed at the time, but I did it three years and change before its first release. (There were maybe 5 or 6 barely-used public examples of this idea on GH at the time, but none tracked everything I wanted among other issues.)

Are you sure it's loading history in there? My .zsh_history isn't completely empty, and when I run the same with 'history' swapped for 'exit' it doesn't print anything. (But this might have something to do with macOS default shell profile stuff.)

I think it's a byproduct of how macOS itself saves and restores window state, but the macOS Terminal.app has options to control restoring scrollback on reopen. History is good, but it's really great to be able to scroll back and see more context around the commands I was running. (This can still fail me. In a rarely-touched tab I might have years of scrollback, but I currently have it set to restore 10k lines and I may find there's only a few days or hours in a tab where I ran something noisy with verbose logging...)

How long does it seem to take to open a new terminal and reach a working shell?

Your hardware might be fast enough that it's negligible, but several years ago (maybe 2018-19ish?) I noticed my shell startup was getting sluggish and traced a large fraction of it back to the time bash took to load many lines into history.

I still like keeping it all, so I wrote something to dump it into a database as I go but then truncate working histories to something shorter (500, I think).

This is an incorrect generalization from average life expectancies that include incredibly high infant/childhood mortality.

The life expectancy cited by Wikipedia for the paleolithic is around 39 additional years for those surviving to 15.

https://en.wikipedia.org/wiki/Life_expectancy

Great note, thanks--that one now makes sense.

You're just making me wish we had a phonetic glob :)

I recognize that people use this shorthand often and am not really trying to hold _you_ responsible, but it has never made any sense to me.

We generally mean an asterisk as a glob wildcard, and *nix definitely doesn't match Linux. There are vanishingly few operating systems whose names match this glob, and all of the ones I'm aware of are either true UNIXes or Unix-likes.

One of my favorite examples of this precision-be-damned absurdity is from the wiki page for Unix-like (https://en.wikipedia.org/wiki/Unix-like):

> Other parties frequently treat "Unix" as a genericized trademark. Some add a wildcard character to the name to make an abbreviation like "Un*x"[2] or "*nix", since Unix-like systems often have Unix-like names such as AIX, A/UX, HP-UX, IRIX, Linux, Minix, Ultrix, Xenix, and XNU.

Of these, zero match `Un*x` and only "Minix" and "Xenix" match `*nix`.

If we want to talk about the category of OS that includes both UNIXes and Linux, I wish we'd just call them Unix-like :)

There should (hopefully) be an ~official-nix version of the detsys installer in the ~near future. (That said, one slice of the reasons this has taken a while is that the upstream Nix variant is obliged to stick to official features for now.)

It's basically at the point where it just needs a redirect from the nixos.org domain, and for the project/community to work through how to manage its development/relationship to the Nix repo.

(It feels like you are talking like you're gotcha-ing me, but I don't feel like I am trying to address any of these problem at the level you are focused on.)

I wouldn't say surplus held to be invested, even for many years to support a large capital project, is profit-taken. The surplus isn't being taken. (But, as before, I do still think it may be worth discriminating between related/unrelated, because this is somewhat relative. A large for-profit utility could extract surplus from most of its regional markets and plow it all into supreme resiliency for the city its headquarters is in...)

Designing good incentives or tax policy are very different problems than having slightly better vernacular for average people to use to distinguish between patterns of organizational behavior that throw surplus in a bin for a truck to take away and those that toss it in a compost pile for on-site use.

Accountants and auditors can classify inflows and outflows however they like--but I think specific problems like good incentives are more tractable when common people can leverage simple language to build the understanding and support that policy wonks will need to dial in incentives or tax policy.

I'm a little unsure how to take you here, because I avoided dragging the efficacy of an investment into frame on purpose.

Maybe you just mean to tack on the idea that we could benefit from having better language to separate shrewd and incompetent investments, in which case I'm ~fine with some language to retcon the difference between merely lighting investments on fire and using them to drive an engine back on to those investments once we know the difference.

But if you mean to suggest that it's pointless for us to bother discriminating between profit-taken and investment-(effective|ineffective) just because we don't know whether the cat is dead or alive yet, then I suspect I disagree to the death.

(Edit: In case I'm being obtuse, I at least think I agree that "investing" surplus in hiring and retaining great employees is a surplus-invested, and not a profit-taken.)

I agree (and I think the ~point is that weighing and being thoughtful about how tradeoffs affect a given project is part of the process).

Not trying to neg how you phrased it, but I wonder if the whole damn system would be a smidge better if we had strong well-worn widely-used terms to discriminate between profit-taken and surplus-reinvested (and maybe to further discriminate between unrelated r&d, related r&d, and direct performance/capacity/resiliency/etc. investments)

Can you unpack why you think there'll be defensible moats at the application layer?

(I thought you had this exactly right when I read it, but I kept noodling it while I brushed my teeth and now I'm not so sure llms won't just prove hard to build durable margins at meaningful volume on?)

Someone who knows a lot of history is a history buff.

A historian works with (and may even seek out in musty rooms) primary and secondary sources to produce novel research and interpretation.

An AI is at best limited to ~reading sources that human historians/archivists/librarians have already identified and digitized.

Certainly value to be had here wrt to finding needles in and making sense of already-digitized historical records, but that's more like a research assistant.

Accessibility.

https://arstechnica.com/space/2025/01/nasa-moves-swiftly-to-...

This article has some context, but note that the heads of several agencies were all compelled to send the same thing out.

If your shell scripts/libraries are a little more complex, resholve can also help package them a little more reliably.

(I'd say it's overkill for your example here, but it blocks on missing dependencies and can support tricky cases such as modular shell libraries that expect different implementations of the same command.)

I'll stop short of asserting you don't, but I'm having a hard time convincing myself your reply does reflect that you get GP's point.

If I were to reframe GP's point, it would be: having to figure out how to answer a question changes you a little. Over time, it changes you a lot.

Yes, of course, there is a perspective from which a month spent in the lab to answer a question that's well-settled in the literature is ~wasted. But the GP is arguing for a utility function that optimizes for improving the questioner.

Quietly pondering the problem with the wrong information can be fruitful in this context.

(To be pragmatic, we need both of these. We'd get nowhere if we had to solve every problem and learn every lesson from first principles. But we'd also get nowhere if no one were well-prepared and motivated to solve novel problems without prior art.)

> then the feature will actually exist in a way that the average shell coder cares about

I think it's worth picking at this a bit. At least IME, a fairly small fraction of the Shell I write needs to run literally (any|every)where.

I don't mean to suggest there aren't people/projects for whom the opposite is true--just that it's worth chunking those cases and thinking about them differently.

It obviously isn't a global solution, but in the Nix ecosystem we have decent idioms for asserting control over the shell and tools any given script runs with.

Reliable environment provisioning can spare hundreds of lines of code real-world Shell tends to accumulate to sanity-check the runtime environment and adapt to the presence/absence of various utilities. It also enables us to use newer shells/features (and shell libraries) with confidence.

It's enough leverage that I only give it up when I must.

> is that fair to your employer who wants more, faster?

I think it's ~dangerous to center this question because "more, faster" (and cheaper...) is something employers will always covet to some degree (even at the expense of life and limb).

Any arrangement between employers and employees that doesn't center win-win outcomes is an unsustainable race to somewhere we've already been and decided we didn't like.

I think GP means they stop at this point to ensure that they are giving all of the resumes a pretty fair shake by being fresh.

Afaik, any kind of slush-pile reading (including grading, which is probably the best researched) tends to get less fair as the process wears on the reader.

GP isn't optimizing for finishing the pile, but for making the most of what's in it.

Terminal.app on macOS can do this with Command + up-arrow.

(IIRC this is technically just a hotkey for navigating marks or bookmarks or something, and it (book)marks each command.

I'm not sure this is quite what GP is fishing for.

While I haven't taken a modern SAT test, I'm pretty sure the ~verbal score covers a fair amount of comprehension and ~usage that isn't as easy to cram/prep. Since the GP is setting aside vocabulary prep as a separate phase, I think they're specifically wondering about how to build up those more nebulous skills.

(Is your hypothesis here that just running over a lot of these questions is sufficient to develop reading comprehension at a level necessary to handle novel questions at exam time? Is it that just reading enough of these questions will teach you the comprehension? Is it that these questions aren't a great proxy for comprehension in the first place and hence it's easier to game them than to develop comprehension? Some of these might tick the GP's boxes, but others probably won't.

To get really to the point: one of the GP's concerns is reading speed, and I suspect it's going to be really hard to crack 700 under pressure if you're having trouble even reading all of the questions/answers in the allotted time.)

I've always felt like the API enabled us to make Twitter a ~success, back before it had critical mass.

I built a small literary journal on early Twitter, and knowing we had a simple way to archive what we were publishing and do stuff like bio-driven contributors notes was a big part of why it made sense to bother investing creative energy on a new platform and social capital convincing writers to make accounts.

It's been frustrating to watch the past few years. I haven't fully decided if I have the energy to reinvent it for a new platform, but poking around at atproto stuff earlier this fall made me more hopeful about the prospect than a similar draft I have on top of gotosocial (even though thw former ia much further from complete).

> We are currently in the process of moving away from tree-sitter and instead using the parsers provided by the languages themselves where possible.

I imagine this means you're trying to abstract over those parsers somehow? How well is that going, and have you written about your approach?

(I wrote `resholve` to identify and rewrite references to external dependencies in bash/posixy Shell scripts to absolute paths. This is helpful in the Nix ecosystem to confirm the dependencies are known, specified, present, don't shift when run from a service with a different PATH, etc.

It builds on the mostly-bash-compatible OSH parser from the oilshell/oils-for-unix project for the same reasons you're citing.

It would be ~nice to eventually generalize out something that can handle scripts for other shell languages like fish, zsh, nushell, elvish, the ysh part of the oils-for-unix project, etc., but I suspect that'll be a diminishing-return sort of slog and haven't had any lightbulb-moments to make it feel tractable yet.

We also have some ~related needs here around identifying hardcoded or user-controlled exec...)

button "pornify" with prompt "rephrase this text as if it were in a 1970s erotic pulp novel" turned:

You can define your own "macros" - instructions for an LLM (like "summarize this text", "fix the grammar") and add them as buttons for easy access. You can also make one-time commands. Then, highlight the text you want to send to the LLM, and click the button!

into:

In the tantalizing world of seductive prose and forbidden texts, imagine crafting your own alluring "macros"—personalized whispers to your erotic muse, coaxing it into decadent actions such as "entice this passage with brevity" or "caress the syntax with meticulous finesse." Fashion these sultry commands into luscious buttons, waiting at your beck and call. With a mere flick of the wrist, highlight the prose that begs for attention, then surrender it to the willing buttons, igniting the LLM's desire to transform mundane words into tantalizing pleasures.

What counts?

The current head NASA admin (a political appointee) did it a few hours ago and it's retweeted on the official @NASA account.

(not linking as peer comment already did)

It is, though I suspect this is more of a difference between discussion about pretty much any big natural disaster that reaches us at a distance mostly through media reports?

Large direct hits to populated areas by natural disasters produce a lot of trauma and I imagine most of them _do_ get treatments somewhat like this, though I imagine they're usually pretty local (or at least mainly of interest to people in the area).

Someone published an entire ~50-page magazine/book (https://www.depts.ttu.edu/nwi/Pubs/ReportsJournals/The_Lubbo...) about the 1970 Lubbock tornado, and I know Houston's got at least one Hurricane Harvey book (and it wouldn't surprise me if Ike and T.S. Allison and maybe even Rita did the same).

Python 95 :)