I'm going to place the blame on the party committing the crimes, not the person exercising free expression.

No. We need spam filters for this stuff. If it isn't obvious to you yet, it will be soon. (Or else you're one of the spammers.)

They are:

- https://github.com/orgs/community/discussions/159749

- https://github.com/orgs/community/discussions/169148

470k feet is 143 km. The altitude record for an air-breathing aircraft is 38 km. There are some very low earth orbit satellites that orbit in the sub-200 km range (https://en.wikipedia.org/wiki/Very_low_Earth_orbit). The ISS orbits at about 400 km and typical LEO is 800 km. ICBMs have an apogee altitude of 1000 km or more.

(Of course, the energy required to get up to some altitude is only a small fraction of the energy required to get into orbit at that altitude. https://what-if.xkcd.com/58/ is a relevant read.)

Comments URL: https://news.ycombinator.com/item?id=41443188

Points: 1

# Comments: 0

The alternative requires a scenario where waymo is especially likely to get into fatal accidents while being very good at avoiding non-fatal ones, right? Seems far-fetched.

I used to gvim but realized that I was getting almost no benefit (and occasionally the differences between gvim and my terminal caused minor annoyances).

Two things I do that help in this regard:

I use a tweaked config for the "editor" instance of the terminal that has a slightly different background color from my main terminal. This keeps them separate in my mind.

I use dedicated shortcuts for focusing each application I use (browser, terminal, slack, etc) and the "editor" terminal has its own shortcut. (The --class flag that the post mentions kitty has would be pretty helpful in this regard. My terminal doesn't have that so my shortcuts are based on title, which works well enough most of the time.)

I own a variety of monitors and can easily tell the difference between 60hz and 120hz. All things being equal, I of course prefer 120hz (or 165hz as some of my gaming monitors support).

I also own monitors at resolutions from 1440p to 4k.

For doing work (programming, where I'm mostly looking at text), resolution makes a huge difference. I only do coding on high DPI screens and I would upgrade to 5k or 6k or 8k displays if I were confident that my hardware and OS would support them well. (TFA was very helpful in that respect.) In these settings, high refresh rate makes only a marginal difference to my experience.

For gaming, refresh rate makes a much bigger difference, and resolution makes a somewhat smaller difference -- my hardware can't reasonably drive many of the games I play at 4k or higher anyway. So I just use cheaper, lower-resolution monitors that operate at high refresh rates for gaming.

Someday I guess I'll just be able to spend $300 for an 8k monitor at 240hz and then I won't have to make this kind of choice. (In fact, in the several years since I last bought gaming hardware I think the options for high-refresh-rate 4k monitors have gotten much better; I might use 4k for gaming if I were buying today.)

But for now, I'll always pick resolution over refresh rate for doing work, and it's not because I can't tell the difference.

Considering it again now, I do think it's essentially a bug, but it seems to be a known thing at this point. What I described is the same issue addressed by this unmerged patch: https://lkml.org/lkml/2017/9/18/739 (see discussion here: https://lwn.net/Articles/814535/). And it's mentioned in the article in this HN link:

> Those dentries still take up valuable memory, and they can create other problems (such as soft lockups) as well.

A deploy that was normally very fast would sometimes hang for a few minutes during a phase where all it had to do was delete the old application directory and move the new one into place.

Turned out that the application was writing a bunch of tempfiles into the cwd and then immediately deleting them. Nothing ever touched that directory while the negative dentries accumulated for weeks or months. When someone finally deployed, the first rmdir that came along bore the cost of deleting all those negative dentries. It hung for seconds or minutes while the kernel essentially cleared out the entire dcache, deleting linked list elements one by one. It showed up in perf as being stuck inside shrink_dcache_parent.

This is actually easy to reproduce:

  $ mkdir /tmp/foo
  $ touch /tmp/nodelete
  # create and delete 100k files
  $ for i in $(seq 1 10); do bash -c 'for i in $(seq 1 10000); do rm $(mktemp /tmp/foo/XXXXXX); done' &; done; wait
  ...
  $ time rmdir /tmp/foo
  rmdir: failed to remove '/tmp/foo': Directory not empty
  rmdir /tmp/foo  0.00s user 0.02s system 91% cpu 0.024 total
  $ time rmdir /tmp/foo
  rmdir: failed to remove '/tmp/foo': Directory not empty
  rmdir /tmp/foo  0.00s user 0.00s system 81% cpu 0.003 total

At some point we probably would've noticed the memory leak as well (I found an 18 GB slab on one host while this was happening) but the machines in question have huge amounts of ram.

I worked around the issue by making the application reuse tempfile names.

This is only true if you want the module to be publicly 'go get'-able. Private modules can be named whatever you want.

(Some tools use whether or not the first import path segment contains a '.' as a heuristic for "is this package stdlib", and those won't work correctly on a module that doesn't use a dot. There's a proposal, not yet accepted, to document this as a naming requirement for modules: https://github.com/golang/go/issues/32819 This is of course a looser requirement than "must be a domain name".)