Hacker News new | past | comments | ask | show | jobs | submit | abathur's comments login

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 :)


Ha.

My partner (who moved to Houston around middle school age) and her mom both call it the feeder, but I always assumed it was a midwest thing since mom's side of the family is all from Michigan.

That said, the old Harvard Dialect survey does suggest this is fairly widespread (though definitely more common in the Houston area): http://dialect.redlog.net/staticmaps/q_99.html


I'm pretty happy with it.

I try alts when they come up since I might like to use the same thing on macOS and Linux, but I've yet to try one that both has the right features and doesn't feel sluggish.


I will lightly defend a lot of this description in American Psycho.

I agree that I generally gloss over that sort of description, but in the case of this one book I felt like the obsessively-materialist descriptions in it did a great job of helping communicate the vacuuous frivolity of the culture the novel's picking at, if that makes sense?

That is to say, when I feel like the descriptions are ~fungible I'm probably right there with you in skipping over them, but they were one of my favorite parts of American Psycho.


Not op, but I wouldn't call it boring.

It's a lot like thinking, I guess. (Much of my thinking is already roughly abstract-lingual, so reading feels of-a-piece. I would characterize myself as having a running interior narrative, but this isn't a voice I "hear" as I gather it is for some.)

I generally prefer reading to listening since it's easier to back up and re-read if my attention has wandered.

I can have trouble staying ~oriented when there are lots of characters because I have no strong sense of what they look or sound like. (TBH I think this is an asset when it comes to adaptations. I may notice plot divergences, but I'm rarely bothered by the specifics of a place or character.)

A fair fraction of the enjoyment I get out of reading is about wordplay and language aesthetics, and much of the rest is about ~ideas and personalities.

Reading tends to drive a lot of synthesis/connection between divergent concepts for me. Some of my most intellectually-fertile (generative) time centers around reading.

I generally can't count on any kind of eidetic memory (unlike those I know who can, say, picture a page or replay a conversation to extract information from it). Instead, I generally lean more on deep conceptual synthesis. I am much more likely to retain some picky detail when it's integrated into my broader understanding than if it's effectively an arbitrary fact. I am the person who would rather take an essay exam centered on understanding than a picky multiple choice that hinges on arbitrary details like dates.

Likewise, I don't really vibe with arch/infra/service maps as much as narrative documentation. (This is not to say that they aren't sometimes helpful for understanding, but I do find them hard to ~grasp in isolation and not the first resource I reach for.)


A good example for lulz is https://github.com/zevweiss/booze, a FUSE binding for bash.

Aside: I've wondered aloud if we could figure out how to systemically compile coreutils into true bash builtins for performance benefits in nix builds, but someone did rightly point out that builtins can't be completely fungible with a separate process in all cases, especially where stuff like pipelines are involved. I don't recall the exact details and couldn't readily find the conversation but IIRC it had to do with signal handling.

Edit: Found the conversation: https://gist.github.com/abathur/74e7a63b25b7bbd4a6fa9ad7e728...


Presumably:

    #!/usr/bin/env bash


FWIW we can do this* with bash in the nix ecosystem (not that this knowledge should deter you from checking out scrapscript).

* you said locking the hash in the script, and in the nix approach these are generally locked in either a lockfile or in the nix expression.

Can elaborate if you're curious.


Multiple files adds just a tiny bit of friction when moving things around, putting on Gist, sending on Slack, etc.

I would love for the Nix lock to somehow be embedded in the script.


You can inline the script within nix and get them all in one file (but that implies buy-in on nix, or maintaining 2 copies of the script).

At the risk of overstepping (it sounds like you might be a little interested) here are a few links in to some basics just-in-case.

For context, I extracted my bashrc into its own repo, and it in turn sources bash libraries for my shell history and git status plugins. It's also leaning on some libraries that are pulled in through those two. (To be clear, this is just a general example of the flake pattern with a separate lockfile. I can find or synthesize something with the inline script pattern if you ask.)

- Source statements: https://github.com/abathur/bashrc.nix/blob/e7c437578e2a623f4...

- Nix expression responsible for resolving and ~linking these two dependencies in to the final script: https://github.com/abathur/bashrc.nix/blob/e7c437578e2a623f4...

- Flake inputs for the two dependencies. Note that these can be specified as just the repo or a branch and updated by updating the lock through Nix, or they can be ~pinned to a specific rev: https://github.com/abathur/bashrc.nix/blob/e7c437578e2a623f4...

- A gist with examples of the entire chain of scripts that get resolved together here: https://gist.github.com/abathur/09f06f1f34b003376017d7a5c031...

These all get handled separately, so they can technically have divergent implementations of the same external command (for example, one library could depend on libressl and one could depend on openssl--and each resolved library would independently point to the correct one.


Just writing to agree, since you are getting pushback.

@Foxboron wrote a compelling if clickbaity post a few months back to poke at the bit-for-bit interpretation of what reproducibility means in nixland: https://linderud.dev/blog/nixos-is-not-reproducible/

It didn't get much traction here (https://news.ycombinator.com/from?site=linderud.dev) but there was more lively discussion on lobsters: https://lobste.rs/s/jpoy4q/nixos_is_not_reproducible

(That said, the nix ecosystem does have levers and practices for working to weed out common sources of build reproducibility problems and the community is reasonably interested/active here. But there isn't any magic in it that fixes all bit-for-bit issues. People still have to catch, tag, and fix them.)


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: