Hacker Timesnew | past | comments | ask | show | jobs | submit | bch's commentslogin

Everybody else is a fungible cog.

TFA is a good little read - couple things come to mind

  1) Knoll’s Law [0][1]

  2) The ways I feel when I’m working on a hard problem in an area of my expertise and  some person starts in with “Why don’t you just…”. Enough people have come to me in such a situation with such a comment that I think it mostly translates as a sort of shibboleth for “I have no real idea what I’m talking about.” Now to find out if this is a teachable moment, if I have to maintain a sense of humour, or find out if I’m actually one of the days lucky 10,000.[2]

[0] https://effectiviology.com/knolls-law/

[1] https://en.wikipedia.org/wiki/Erwin_Knoll

[2] https://xkcd.com/1053/


> can’t remember ever meeting anyone who chose vi over vim

Pleased to meet you.

Most of my console dev time is spent in *BSD, where nvi is where I land. I find the the default creature-features of vim annoying, so I end up having to configure it to be a bit more quiet, and I don't know anything so compelling about it (a vi clone (to an extreme, acknowledged)) that nvi isn't a good enough place to be. I have vim installed, but it's not my go-to.


> I don't know anything so compelling about it

For me, it'd be primarily having more than one undo. Not being able to undo the second-to-last change is pretty bad. In fact, vim's undo being set up as a tree that can be walked with g- and g+ is excellent. It's impossible to lose a state of the buffer, even if you undo and make changes. It's a lot more practical to navigate than Emacs' undo, too.

EDIT: I just realized that nvi can undo more than one change by having u toggle the direction and . continue in that direction. I don't think ex-vi could. busybox vi seems like it can undo multiple with u but it seems to have no redo.


> It's a lot more practical to navigate than Emacs' undo, too.

What the heck are you talking about?

Emacs undo is simply the State monad over a zipper into a persistent tree of buffer states.

I can't see how you could make it more practical?


> For me, it'd be primarily having more than one undo

Do you mean infinite undo? nvi has that. I'm not sure what you mean "set up as a tree" wrt undo, but i'll look into it. I think of nvi's undo as linear - I can 'u' to "undo" and implicitly set my "undo direction" "backward in time" (as one would expect). If I want to "undo, even more", '.' (dot, period) to "do that last command again" is what I'll do. If I want to "undo an undo", 'u'. That has the effect of moving the "undo direction" back towards the state of the buffer we had at the beginning of our discussion here.

...and, now I see your edit ;)

^[u..........:wq


> I'm not sure what you mean "set up as a tree" wrt undo

:h undo-branches

There's also a plugin to show a visualization of the tree, but the tree is implemented within vim.

https://github.com/mbbill/undotree


Nice. I like it. Advanced history mgmt in between commits is compelling.

The only times I encounter vi (and so not sure what version, but likely barebones Linux), it doesn't indicate whether you are in insert or normal mode. So I immediately install vim (once possible).

Is that something you just get used to, or was I using some weird vi?


I always assume I am in normal mode unless I am actively typing. If I stop to think I ESC. Then, when I gave thought, I know what I need to do next.

So for me there isn't really any time of looking at the screen and not knowing. And if there ever was some ambiguity I would reflexively hit ESC to get to a known state.

So, not sure it would bother me. But my editor does give me an indication of whether I am in normal, insert, visual, visual block, or Emacs mode.


"The performance is off the chart!" <basic chart is displayed to illustrate(?) the point>

More seriously, obviously a ton of work in an incredibly competitive space, and an incredible machine (without getting into competitive comparisons/minutiae). Was watching a techtechpotato[0] quick post pre-launch about "why is this even being tried?", which was also interesting. What an age we live in.

[0] https://youtu.be/JdB722MK380?si=GnLAYqT9ZecMhWCS


> tray screen is very nice

If you're talking about the screen on the arm w grab handles, I'd say it looks very practical, but looks like a design for a public space - like an accessible screen for buying tickets in a fairground.


Pardon the pedantry, but I the current abbreviation of the price ("Shutterstock to pay $35M") should be "$35MM".


> No evidence is provided for the safety of THC vaping products.

That's not the point - gwerns article dismantled the NYT article. If one read (or heard about) the NYT article and used it as "proof" of "vaping is bad", gwern is saying: "not so fast". That's not to say "vaping is healthy", nor even "vaping is not unhealthy" - just that this article isn't the proof you're looking for. Vaping (legal flavoured nicotine (which is what's on trial)) could be horrible - simply citing instances of why this is so isn't actually done in the article.

If it matters, I'm not condoning vaping or smoking at all.


no. the critique has nothing to do with vaping. It picks apart nicotine vapes vs the THC specific, vitamin E specific illegally marketed/unapproved incident.

The NYT article was suppose to be about nicotine vapes and in it, they used an example that only appears related because it's a vape. The harm caused by the illegally marketed/unapproved incidence doesn't prove the new york times summary: nicotine vapes are harmful.

The fact presented about the THC vape incidences arn't categorically related to the use and marketing of nicotine vapes.

The point of the article is to showcase how examples can be technically correct (vaping superset) but not actually provide relevance (THC vapes w/vitamin E acetate caused lung damage).


> The beer went from local to Bud and Bud Light. Then according to my wife, it went from Bud to Kirkland (the brand you find at Costco)

So, back to local breweries? /s


Huge upgrade though ;)


sigh, have your upvote. :-)


I didn't realize he was Canadian - as a child I got so much mileage out of Machine Language for the Commodore 64[0]. I used to think of my program, get out sheets of graph paper and flip through a table of opcodes I wanted to use, get their decimal rep, and write out the list of numbers in a long column, then go to my computer and POKE them into place and watch a spite come to life, or the screen change colour. So much fun had with that book.

[0] https://archive.org/details/Machine_Language_for_the_Commodo...


>> monolith kernel written in C

> Who is really running anything like this in 2026 and for what purpose?

Am I parsing your question correctly?


No, I worded it badly. See below.


Its like rain on your wedding day - not actually ironic, just unfortunate.


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

Search: