A great read, thanks for sharing.

I really hope this is successful, it’s really got the spirit of what made the early internet great.

It’s interesting that the author and most others went with 403, when 426 seems to be the most appropriate.

Neither are perfect matches, since 403 is about authentication and 426 is for Upgrade semantics (i.e. the upgrade is over the same transport protocol, not switching from http to https). npm isn’t sending an Upgrade header, which is required, but I think if it sent Upgrade: TLS/1.0, HTTP/1.1 then that would be claiming they supported TLS on port 80 (STARTTLS style) - possible but unconventional.

I haven’t used atuin yet, but I believe the histories from other machines is more like accessible than mixed - you don’t just hit ↑ on machine1 and see machine2 commands.

Lisp variants like Clojure are being used for new projects (e.g. Logseq) but I’d be surprised to hear of anyone choosing COBOL for a greenfield project.

I wasn’t saying that unit tests replaces readability, I was saying that back in the 60s they’d reason and debug using their brains (and maybe pen and paper), with more use of things like formal proofs for correctness. Now that we write more complicated programs in more powerful environments, it’s rare to do this (we’d use breakpoints, unit tests, fuzzing, etc).

For such an influential letter, I don’t find his arguement all that compelling. I agree that not using go to will often lead to better structured (and more maintainable) programs, but I don’t find his metric of “indexable process progress” to satisfyingly explain why that is.

Perhaps it’s because at that time people would be running the programs in their heads before submitting them for processing, so they tended to use more of a computer scientist mindset - whereas now we’re more likely to use test cases to convince ourselves that code is correct.

I used to have some with e-ink displays that showed how full they were, but I always wished I could use them to show a label instead.

CNLabelContactRelationYoungerCousinMothersSiblingsSonOrFathersSistersSon

The label for the contact’s mother’s sibling’s younger son or father’s sister’s younger son.

I thought it was just a male cousin, but it doesn’t include a cousin who’s your uncle’s son. Which culture needs this?

Compare to MessagePack’s example from their front page:

It answers 90% of my questions in a quick example.

function delete-branches() {
  git branch |
    grep --invert-match '\*' |
    cut -c 3- |
    fzf --multi --preview="git log {} --" |
    xargs --no-run-if-empty git branch --delete --force
}

This is really slick.

A great post, interesting and to the point.

Back in the naughties PCLinuxOS was at #1 and people suspected them of cheating. I’m sure some people do try to game it, but there’s plenty of organic and bot traffic to compete with.

Besides, I think the popularity thing’s kinda backwards - I’d never visit Ubuntu or Fedora because I know what they are, but I’ll be clicking on something novel out of curiosity.

As far as I know I made it up, but I stand ready to be surprised!

Thanks for the link, I forgot about CLAs. Interesting - this kind of thing seems to be controversial but common.

I’m not saying OpenTofu is doing any accusing, but I am. I was thinking an original author had the sole right to relicense code but I guess they found some legally plausible way to get it done. I wonder if the author was an OpenTofu employee.

Pretty shitty attempt on Hashicorp’s part. Come to think of it, are Hashicorp themselves in the legal clear for grabbing code from an incompatible licence?

I like it too, even though it didn’t notify me when the trial was up like it said it would. I was planning on buying the lifetime (or uninstalling) but it autobilled me for a year instead.

Anyway, here’s mine:

Distro watch rankings are just which page gets the most hits. Get a bunch of different IPs to load LemmyLinux and it’ll be number one (and then actual people will click on it to see what it is and why it’s number one).

Finally, when you reference a Git hash for posterity, e.g. in another commit message, I’d recommend always using the full value.

Good advice.