But not "non human-powered" flight? If Icarus flapped a little, that counts.

If you can’t maintain altitude without losing significant airspeed, you’re just falling.

Thanks, hadn't heard of this! In homebrew, too.

https://github.com/apple/container

An SO question indicates "10 GB of memory should show an ECC event every 1,000 to 10,000 hours,"

https://stackoverflow.com/questions/2580933/cosmic-rays-what...

You don't need a robot arm, just mimic a usb keyboard.

https://pikvm.org/ and similar exist.

This is maybe not as good as the article solution, because it requires you to secure the pi too.

Regarding 2, I believe that talking on mobile phones drives older people crazy. They remember talking on normal land lines when there was almost no latency at all. The thing is -- they don't know why they don't like it.

Yeah, I remember the time when we had to use satellites to connect. The long delay was really annoying and so unusual that most people without "training" could not even use the phone for conversation and just wasted the dollars.

A former boss of mine took off to Everest for a month leaving me (a 22 year old, at the time) in charge of the office. I was out to dinner with my now wife when I got a call from a very long phone number I didn't recognize, so I ignored it. I then got another one right after, and picked it up. It was my boss, he needed me to log into his personal email to grab a phone number for the medical insurance he purchased for the trip, because he had been vomiting for days due to altitude sickness, and needed a medical evacuation.

That was the most stressfully hard to use phone call I've ever had. The delay was nearly 10 seconds, and eventually I just said I was only going to speak yes or no, if he needed a longer answer he needed to shut up. And that worked. We no longer talked over eachother.

Maybe you bring back radio etiquette and just say "over" at the end of every thought?

I've done some Uber driving. Chatting in a car is great because there's no awkwardness of whether to look at one another. I've met some really interesting people, from all backgrounds. I can recommend it if you have time to spare and want to chat with people.

Not everyone wants to talk but you can pick up on that pretty quickly.

I noticed that but I guess it's to avoid the vertical river.

I'll bite. What's a vertical river?

I don't understand the use of "I'll bite" when the message you're answering to is obviously not... bait. Are we now saying "I'll bite" before every question we ask?

part2: https://www.inconspicuous.info/p/the-man-behind-the-upside-d...

That is hidden behind a paywall. The curious part of me wants to know what the guy said, but the logical part of me knows it was likely little more than “oops”.

Did you edit it to fix it? Is HN refusing to include the period as part of the URL?

A gotcha for me originally and perhaps others is that while using ordering like

   $ ./outerr  >blah 2>&1

sends stdout and stderr to blah, imitating the order with pipe instead does not.

   $ ./outerr  | 2>&1 cat >blah
   err

This is because | is not a mere redirector but a statement terminator.

    (where outerr is the following...)
    echo out 
    echo err >&2

Useless use of cat error/award

But also | isnt a redirection, it takes stdout and pipes it to another program.

So, if you want stderr to go to stdout, so you can pipe it, you need to do it in order.

bob 2>&1 | prog

You usually dont want to do this though.

The point is that the order in which that is processed is not left to right.

First the | pipe is established as fd [1]. And then 2>&1 duplicates that pipe into [2]. I.e. right to left: opposite to left-to-right processing of redirections.

When you need to capture both standard error and standard output to a file, you must have them in this order:

  bob > file 2>&1

It cannot be:

  bob 2>&1 > file

Because then the 2>&1 redirection is performed first (and usually does nothing because stderr and stdout are already the same, pointing to your terminal). Then > file redirects only stdout.

But if you change > file to | process, then it's fine! process gets the combined error and regular output.

Try it without the `cat` and tell me what you get.

You can pipe the fd directly:

# echo 1 >&2 2>| echo

Why would that second one be expected to work?