jolmg

Such a generic word. I imagine there are tons of CLI utilities out there with a --passkey option that refer to simply files with a key inside. Kind of crazy that it's being used to mean specifically devices that implement a specific protocol.

Kind of feels like "crypto is a type of currency and not all cryptography", or "SQL Server is a specific product of Microsoft".

Wonder if how it happened this time was people read the specs and explanations of WebAuthn, saw "passkey", never seen that word before and assumed it's only ever been used in the super narrow context of WebAuthn so it can only mean that. Maybe "header" can only ever mean "HTTP header".

Thinking about it like that, it may be more like how "latte" is specifically espresso with milk (it's really just milk), or "queso" is specifically cheese dip (it's really just cheese of any kind), or "masa" is specifically made of corn (it's really just dough of any kind, or it's mass like atomic mass is masa atómica).

Is "passkey" only supposed to mean devices that implement specifically U2F, WebAuthn, etc.? I would have thought TOTP and challenge-response hardware tokens to count, including cellphones with apps that implement such.

As to

No major bank revokes your password when you setup a passkey, either.

If we're talking about requiring 2FA via TOTP or challenge-response hardware tokens or banking apps implementing such, that depends on the country. It's the status-quo in some places. Some banks even put the input field for the token output as a third input in the login form on their website because all customers have them. The rest separate their login form in multiple steps, but they likely require it of all customers too.

I've not seen any insist that a passkey _must_ be used, and you can always log in with your password (or worst case, email magic links) as a fallback.

With the exception of Github, and banks.

The link provided by cydodon is about emulating a battery.

I mean, that's a positive feedback loop. It takes longer to review, because they're expecting them to be big. Big PRs/MRs are left there until there's a big enough free time block to tackle and discuss. If the PRs are small, obvious things, they can be merged in minutes.

(Depending on what the PR's about and how the team organizes. Ideally, there's consensus on the goals or who's responsible for what. Reviews can be limited to finding bugs and e.g. organizational problems)

  man git-bisect

Right, maybe a better way to get what they're going for would be

  git checkout @~ ^tests

Yeah, there's a balance. I try to make my commits so they make sense on their own.

commits around it to figure out why that change was even made.

A commit should be such that the message can articulate the why.

No one is ever going back and reading individual commits.

Straight from the git-log, maybe not, but sometimes you see code that makes you wonder how it came to be and it can help a lot to see it in context of the commit that introduced it. That'd be less helpful if that commit were some huge thing making lots of different changes at once.

Maybe the issue is they think of a PR as an expensive thing. Would be best if they could just do the small thing and make a PR of that from the get-go. If they want to base future changes on the ones they just did, they can just create a new feature branch from right there, and just not create the PR of the second feature until the first is merged, or create it and add a note to the reviewer that it includes the changes of the other PR so they should review that one first. Should they want to add changes to the first feature, they just need to checkout that branch, do the changes, and merge to the second feature branch so they're available there.

Huh.. That's a shame :(. Maybe what it refers to is if you had a branch on B rather than D, it might update that.

EDIT: Yeah, this seems to be it. `git branch b` on b, then `git rebase -i --update-ref @~3` from main caused branch ref `b` to move from d86229e to 02fcaf7:

  * 1e354fb (HEAD -> main) fix b
  * 40e6f70 c
  * 02fcaf7 (b) b
  | * f4188e0 (branched-feature) d
  | * d86229e b
  |/  
  * 5fe78fa a

but branches can be moved around with less ceremony than tags

`git tag -f` to move a tag.

Personally, I just do `git show` when I'm feeling cautious, but I can generally just scroll up to find the last `git commit` I did with the hash in the output. `git reflog` should also have record of it, so everything else is kind of extra.

Exactly, but the second graph where untouched E is reparented to B' is not something that git would allow.

I'll end up with this state, where `E` remains untouched?

Can't, because a commit's hash takes into account the parent hashes.

Haven't used --update-refs, but reading it, it should result in your third graph. So,

is there a way to get `git rebase` to have the same behavior?

is already the case.

One can also use that, or just `git log -n1` and taking note of the commit hash. So many options.

scary rebase -i commands that can leave your tree in a half-broken state if you so much as sneeze

`git rebase --abort` exists. One can also set a tag or something before doing the rebase, do whatever, then `git reset --hard $set_tag` to go back. Nothing to be scared of. Not like the prior state is lost.

Yeah, the benefit of audiobooks is being able to do it while doing chores or being out and about. The medium's ideal for being hands-off.

it could not be any more of an equal experience absorbing a book through my eyes or my ears.

With stories, probably. With nonstories, and depending on what kind of nonstory book, I might jump around a lot. I might like to skim quickly (e.g. chapters/sections, starting sentences of every few paragraphs, etc.), then skim more thoroughly (e.g. recheck paragraphs of a chapter to get a general flow of it and how they connect, etc.), then read thoroughly on some sections and less others. You just can't do that with audiobooks. You don't have the same level of control.

Depending on how thought-provoking something is, my mind may stray on thinking of implications. Then, it's easier for my eyes to dart back by the time I notice and reread x or y, than rewinding, listening a little bit, rewind some more, etc. I might just stare at some words sometimes. You can't stare at sound.

Memory in relation to sight and sound is probably different, too. With sight you can kind of make more associations. You read an idea, and you can associate that with the location of where you're reading it (what part of the page, around how many pages have been turned in the chapter, what chapter, thickness of pages on left and right side of the spine). With sound, it's just a single stream. You're not staring at the timestamp location in the file of everything you're hearing and there isn't like this hierarchical location structure.

Anyway, I would’ve thought it’s an acceptable cost from e.g. Google’s perspective to block ranges that did something bad once in spite of collateral damage.

Almost nobody is on a static IP. ISPs have an interest to keep their customers connected and not affected by other customers, so they'd probably use as large address pools as possible for their dynamic IP rotations. "Did something bad once" is short-lived unless address ranges are large.

Tech companies like Google are interested in being global monopolies to dominate markets and also having as good and large-sampled statistical data as possible from everyone. Blocking thousands of users for each bad user that can likely easily switch to another block if they really want to doesn't seem effective. It would also affect their reputation. Who wants to rely on an email service that may block you because of other users on your IP block? Having a reputation for being reliable is important for businesses.

With small personal sites/blogs like the ones you mentioned, they can just block most of the planet without a problem. There's not as much reason to be as reachable as possible (some may be satisfied with an audience of a handful of people), and they're also more budget conscious.

In the case of Google blocking an Apple service, they not blocking users; they're blocking Apple. The users can just not use Apple's service.

There must be countless individuals all over the world who suddenly can't log into their Gmail or create any new accounts because a fraudster sent spam from their IP.

Places with open WiFi like hotels and restaurants would be having the same problem. People on CGNATs would be having the same problem. An IP doesn't correspond with a single user.

Mmm... your quote (IDK where it's from) mentions them having consent from device owners, but your FBI link cautions on how to avoid getting infected by malware.

If they have consent, they're not really botnets. Botnets involve infecting devices without the owners knowing.

With consent, it wouldn't be much different from e.g. open WiFis at restaurants and hotels, companies using a single ISP and single public IPv4 address for all their employees, and most VPN services.

Emacs' usage of ‘client’ and ‘server’ here refer to [...] simple control commands

Despite that, it still enables this:

where runtime state is synchronized between the client and server over a network

On graphical X11 frames:

https://news.ycombinator.com/item?id=48864196

but it also enables having multiple TUI `emacsclient -c -nw` frames over SSH.

`ssh -X` has awful performance for some reason. You can see each line render individually when invoking the Info manual on Emacs even while within LAN.

It's better if you enable TCP connections on your X11 server, setup a Wireguard VPN between your Emacs host and your X11 server host, and a firewall to only permit X11 connections over that. Throughput and latency then should be so good the remote Emacs window/frame will be indistinguishable from local ones (at least within LAN, haven't really tried over the internet).

Do beware though that if you use the non-PGTK GTK build, closing this new frame will crash the remote Emacs.

Guess I've used the good one. Haven't had this problem. What I do have is that if you open a frame in a host that you then put to sleep long enough for the X11 connection to timeout on the Emacs host, then `emacs --daemon` will crash. When I've used it, I've just made sure to save buffers often. systemd would start `emacs --daemon` again on its own.

`emacs --daemon` has no problem using multiple simultaneous X11 connections to different hosts, but it just doesn't handle the connections closing on their own. It also doesn't itself close X11 connections when all frames to an X11 server have been closed. So even if you close all of a machine's Emacs frames prior to putting it to sleep, it still causes `emacs --daemon` to crash.

Generally, because they're discriminatory. It's like how racial profiling in law enforcement can be a heuristic that can work. Though, in the case of blood donations, it seems that tests aren't accurate enough to be able to rely solely on them. Also, being discriminated against on being able to donate blood is not as big of a deal. Though in some places with public health systems, stuff like getting a surgery may somewhat depend on you and family/friends donating a certain amount of blood.

"Linux, the open-source language of the internet" comes from the linked akamai.com press release, not the blog post author. Their putting that as a section title to the quote may be their poking light fun at it.

Wouldn't be interesting enough to nerd-snipe people.

I keep trying to explain to people that private companies harvesting your data, while not good, is done solely for the purpose of trying to get you to voluntarily buy more toilet bowl cleaner.

A reminder that governments can buy from private companies. A company like Palantir can buy data from private companies then incorporate it into the software it sells to governments.

Well, the brackets thing and the necessity to repeat name of every element twice,

As a document format, it's supposed to be hand-written by humans. If you have paragraphs between the opening tag and closing tag, it makes sense to let the reader know what they're seeing the closing of.

After deciding you do want to repeat the element name, the angle brackets make more sense. Otherwise, you can have a syntax like LaTeX's.

The worst part about it is the tags vs attributes fights. They both do the same thing and the only difference is preference.

They're not the same thing. If you look at it as the extensible markup language for documents that it is, "tags" (i.e. inner content) would be visible and "attributes" would not. If your XML document was processed by an application to convert to another type of document (PDF, etc.), and it didn't recognize a particular tag, it would be sensible for attributes to disappear, but inner content ("tags") to remain.

It's only seems like a preference thing if you look at XML as a structured data format like JSON is.

developers must become domain experts [my emphasis] in a rich and complex space that is essentially unrelated to the application itself.

XML is a markup language, but most people that used it just needed a standard structured data format. In comes JSON which is more easily compatible with the object systems of various languages and in particular is compatible with Javascript syntax, and XML loses most of the people that used it.

As a markup language though, it seems pretty good. It's just that the amount of people that actually need an extensible markup language is much smaller.

I do hate the strictness of it. The header

  <?xml version="1.0" encoding="UTF-8"?>