ericbarrett

I was once standing outside a night club in Brooklyn, next to a construction site, when a rat came charging around the corner being chased by a cat. The rat smacked straight into my ankle and bounced off, briefly stunned. The cat also froze, trying to take in the situation. A split second later they charged down the sidewalk into the gloom.

The rat was so big my ankle hurt the rest of the night.

But ChatGPT is a product, not a model. Might there be an augmenting OCR process feeding it the image's text?

MechJeb + Realism Overhaul offers a "Primer Vector Guidance" ascent controller that (I think) is based on the space shuttle's Powered Explicit Guidance. It's definitely designed to work with more realistic spacecraft; it can ullage with RCS, doesn't need to throttle, etc.

Lawyer. Lawyer lawyer lawyer. This is the only answer. You don't need to go in guns blazing, but you do need good legal counsel even before you talk to your business partner. A lawyer will be able to tell you your rights, what you don't have rights to (even more important), and the probable result of various courses of action. You will also have much more confidence when it comes time to have the discussion, because you have gotten help and will understand the situation a lot more clearly. Seriously: GET. A. LAWYER.

I was recently gifted a recipe book via Amazon. I was excited until I opened it up—it was just low quality LLM generated recipes, poorly typeset. There's no escape.

Nah, even the big ones are shown sauntering through the atmosphere at maybe Mach 3, trailing smoke and flames like lit pitch.

A city-sized asteroid wouldn't be more than a bright dot until the last seconds before entry, and at interstellar speeds it would take about three seconds to go from the vacuum of space to ground impact unless it had a very shallow vector.

Awesome link. Reminds me that one of my biggest gripes with movies is that when they show meteors (or whatever) entering Earth, it's never at realistic speeds. They're always super slow and floaty, hovering in the sky to menacing effect. Great, that's the artist's choice. But the real thing is so much scarier, like this footage! And it's still a fraction of the speed of an interstellar object.

The story: https://www.baen.com/Chapters/0671878522/0671878522___1.htm

That's a pretty good list.

For a meteor impact, I'd cite the Tunguska Event, which was a "3-5 megaton explosion" in Siberia in 1908: https://en.m.wikipedia.org/wiki/Tunguska_event

Seconded! Also check out a complex shadow (like that of a bush) just before or after totality. The camera obscura effect will generate many images of the eclipse crescent, it's really uncanny.

> debug symbols

In ye olden days it was common to distribute a binary without debug symbols, but to keep a copy of them for every released build¹. If an application crashed (panicked, signalled, etc.) you got a core dump that you could debug using the stripped binary together with the symbol file. This gave you both smaller binary sizes and full debugging capability at the cost of some extra administration. I'm not sure if this is possible with "stock" Rust, but if you need lean binaries but want to do forensic investigation it's something to look into.

1. https://sourceware.org/gdb/current/onlinedocs/gdb.html/Separ...

> .ch

Switzerland?

I've been shocked by 300V DC @ 500mA and I'll take the equivalent AC any day. Obviously both can kill you, but the DC was far more painful and instantly gave me 3rd degree burns. Also made me ululate some kind of tone I didn't even know the human throat could emit.

This is commonly avoided by not putting memory pressure on your O_DIRECT application, which is probably an RDBMS on a dedicated single-purpose host.

Not saying more work in the space wouldn't be welcome and interesting, just that it's generally the assumption whenever I've seen O_DIRECT (since the Solaris days and through today) that what's using it is the only thing of substance on the box.

I think you give the whiteboard far too much credit. In the succeeding two decades I have worked at many companies filled with past, present, and future FAANG engineers, and I can definitely say knowledge of algorithms isn’t a defense against writing silly bugs when implementing a complex, novel project from scratch. Just a dumb oversight that would have been caught quickly by user reports—had all the engineers who cared not quit from misanthropic management. There were many such issues, and I only remember these two because I found them myself.

I was in support and only had two good resources for tracking this kind of stuff down, a burnt out but kind SCSI specialist and a brilliant, massively overworked Russian kernel dev on visa. They both lasted an extra year. Bless them both for answering my pestering questions, I learned a lot.

Good times, but all this was about a year too late to make a difference, then the Great Recession hit and it was done.

Was a long time ago, way before them. I agree though, glad to have changed fields.

I worked for a storage startup in the South Bay in the late 00s which did something like this. After staff crunched to deliver the base operating system and kernel controllers, management gave across-the-board poor reviews to all IC staff to justify no raise. Those with the ability quickly left for greener pastures; Google hired some of the best. Only those who had to (work visas, lack of experience, etc.) remained.

The product, being a v0.1 release implemented in C, was of course plagued with data corruption and poor performance. It read /etc/password from disk on every file access. An uninitialized int caused indirect inode corruption every ~millionth write. And so on.

Because of the poor product quality, they lost multiple opportunities, including a bid for early Facebook photo storage. The company never had more than 250 customers and ended up being sold to a Valley stalwart. The CEO and VP Eng were paid out handsomely, of course; preferred converted stock tranches or whatever. My options from 4 years of employment ended up worth $500.

I was an FB infra engineer in 2010. It's not accurate, there was already a "retro" SEV analysis process with a formal meeting run by Mike Schroepfer, who was then Director of Engineering. I attended many of them. He is a genuinely kind person who wouldn't have said anything so passive-aggressive. Also, many engineers broke the site at one time or another. I agree this is just a mutation of the Watson quote.

The only time I ever saw an engineer get roasted in the meeting was when they broke the site via some poor engineering (it happens), acknowledged the problem (great), promised to fix it, then the site went down two weeks later for the same reason (not great but it happens) and they tried to weasel out of responsibility by lying. Unfortunately for them there were a bunch of smart people in the room who saw right through it.

Not GP but I was just starting my career back then. I remember commute traffic on 101 through San Jose and Sunnyvale going from bumper-to-bumper to smooth sailing, where you never even had to touch your brakes.

From the crash of April-ish 2000, it was 6-9 months before the best of the best could even get an interview, and about 36 to something approaching normality.

I really like Rust's answer in this space. Check out all the useful methods on the u64 type that can make this kind of code explicit: https://doc.rust-lang.org/std/primitive.u64.html

No. One example of many: https://www.nps.gov/jotr/learn/nature/cryptocrusts.htm

This is really not true in natural Southwestern US desert, because the worst thing you can do is trample the biotic crust, which takes years (even decades) to regenerate. It is an established biosystem, with its own birds and insects and arthropods and mammals. Trucks driving on it and earth movers leveling it will do nothing good. TBH I’d rather see us put panels on existing buildings before we trample some of the last undeveloped space in North America.

You could back in the early days (I did it), not sure today.

True, it’s nicely stateless, but it does allow precomputation. E.g. you could spend a few weeks doing PoW for a future date and submit when you reach it. Whether that’s a problem is a matter of taste!

Agreed. I have another suggestion, which would require continuous investment of compute and (hopefully) not make things too much more complex:

Every N seconds, publish a "generation" string, randomly generated. This string must be prefixed to the nonce of the winner of the contest for [marquee, color, grid square].

When performing the "winner test" for new submissions, before the comparison to find out which is less, both the challenger and incumbent hashes are subject to the operation H << M where H is the hash and M is the age of their generation string (current = 0, previous = 1, second-previous = 2, etc.). This means incumbents weaken over time unless the incumbent's submitter continues to defend them by brute-forcing with newer published generation strings.

Since the hash (SHA256) is 256 bits, you'd need to keep 256 previous generation strings, and this could get a bit expensive for testing new submissions. But computers are pretty fast nowadays!

Wow this really fun. Nice web client too. Makes me want to relearn CUDA...

Thanks, this is great info!

Thanks for linking the actual post—it was a great read. I'm not an ML expert, but the author really made it easy to follow their experiment's method and results.

Nope.

It's only been a couple times a week on random days and times; I'd basically have to camp on my roof to catch them. And they're going full tilt (at least 90 knots) so there's only 5-10 seconds of opportunity. I do have a pretty good long lens on my digital camera, maybe I'll set it up and have it by the door.