Even though Earth orbit is 2/3 the way there, the rocket equation still applies.

So? Do it in multiple phases just like we've done for the ISS. Isn't that one of the points of SpaceX building cheap/reusable rockets that can be launched quickly? Even Star Trek did this.

There's a decent chance we're already watching the prologue to WW3, we just don't know it yet.

Sure, but that "prologue" could a couple thousand years (or more) for all we know. ;)

We aren't though. No current national governments are itching for a WW like they were in WW1 and WW2, plus now we have nukes. Possibly the only outlier is Kim Un who seems to think he can scare S. Korea into joining his clown show.

With absolutely no information about the future, there's actually no way to claim anything has a 'decent' chance.

We have the present, where we got:

* Russia showing how to get ahead with invading your neighbors for conquest in 21st century

* Everyone else with expansionist plans taking notes and making schemes

* Russia again, pouring gasoline to every fire they see

* And the usual powder keg that the Middle East is

Meanwhile nationalism is on the increase everywhere, military spending is breaking records in anticipation. Millions of people relocate because of wars and warming climate. So it's looking to me like this one will get a lot bigger before it dies down. How big before it counts as a World War?

That would be because at least some of the cash bypasses the cash register and the tax report.

Edit: alternatively they might not have same profitability requirement as other restaurants, because a cash-only restaurant is perfect front for money laundering.

And they're probably just not comparable restaurants on average.

We just need to agree on a 2^16 word dictionary, each 16-bit segment gets it's own word. Then we can write addresses such as correct:horse:battery:staple::one .

Depends.

An overflowing queue that drops jobs from the front while backend chugs along as fast as it can, is for many cases a better outcome than the backend overloading and everything grinding to a halt.

Compare it to a physical service desk. The one that has a queue, serves one person at a time, and people arriving will try again another day if the queue is too long. The one without queue has people fistfighting over who gets to go first, and no one ends up getting service.

That's loadshedding.

So it allows the dev team to blame the queue. Instead of “we decided to drop requests,” it’s “oh look, the queue is dropping requests.”

There is the case of "home laptop". Something that you rarely or never carry around, but you still don't want a stationary desktop PC for whatever reason.

My home laptop is my work laptop, a 30 mm thick ZBook 15 from HP. I move it in several rooms according to the season. Some rooms get too hot in summer, others are OK. Same thing for winter.

I could buy a desktop and remote desktop to it from a lighter laptop (maybe with a monitor, mouse and keyboard? too much stuff to move) but sometimes I don't work from home. Not every year now. Thankfully covid took care of nearly all of those days spent at a customer's premises.

If you aren't staying somewhere permanently but also aren't moving in the immediate future (eg: college dorm) or your living space is constrained (eg: a trucker or an RVer), it definitely makes sense to have something powerful in a form factor that is "temporary", low-maintenance, and mostly self-contained.

Not having a "PC desk" is common in some countries. They need laptop even if it's not quite portable.

I suppose the market for those is probably too small for the manufacturers to invest in.

Two more to the scientists' tab:

1. No tests of any kind. "I know what the output should look like." Over time people who know what it should look like leave, and then it's untouchable.

2. No regard to the physical limits of hardware. "We can always get more RAM on everyone's laptops, right?". (You wouldn't need to if you just processed the JSONs one at a time, instead of first loading all of them to the memory and then processing them one at a time.)

Also the engineers' tab has a strong smell of junior in it. When you have spent some time maintaining such code, you'll learn not to make that same mess yourself. (You'll overcorrect and make another, novel kind of mess; some iterations are required to get it right.)

Yes, the claim that the scientists' hacked-together code is well tested and even uses valgrind gave me pause. It's more likely there are no tests at all. They made a change, they saw that a linear graph became exponential, and they went bug hunting. But there's no way they have spotted every regression caused by every change.

Agree with those two problems on the scientist side. I would also add that they often don't use version control.

I think a single semester of learning the basics of software development best practices would save a lot of time and effort in the long term if it was included in physics/maths university courses.

> I would also add that they often don't use version control.

Working for corporate R&D, I once received a repo on a flash drive. The team would merge changes manually by copy-pasting.

I should've just turned around and left.

1 and 2 are features. Re 1, if someone doesn’t know what the output should look like they shouldn’t be reusing the code. Re 2, just think a bit more about it and you’ll realize fretting over ram that isn’t needed until it’s needed is actually just premature optimization.

To me, this seems like a positive problem.

Of course it is good, if the sales team succeeds. But it is bad if that means that the developers are unable to do their work.

I think what ends up happening is that you sell a lot of stuff that gets steadily worse over time.

Depends how you feel about $NOISE

(2005) with thin wrapper from (2019).

20$, and more freedom? Unless they settled for keeping the illegal contracts for a free lunch.