Hacker Newsnew | past | comments | ask | show | jobs | submit | themafia's commentslogin

> $4 billion per launch lol

$1.3 billion for the mission hardware.

$2.2 billion for the single use SLS.

$0.5 billion for the launch pad.

> watching people go back around the Moon

Two of the missions were actually meant to land. One of them still may.


The price doubled in 6 years.

They underestimated Iran's unique mix of capabilities and strategy. It's not that Iran is undefeatable but it seems that the price is going to be far too high both globally and especially regionally for the tiny coalition of Israel and the US to succeed in the long term.

I think it says something that the US paid such a high price to try to produce a "viral military campaign" video of a Uranium heist. Straight out of the cold war. The palatable options must be steadily dwindling.


> tiny coalition of Israel and the US

This coalition is "tiny" insofar NATO & the GCC (well, apart from Bahrain and the UAE) refused to join the attacks, despite Iran's transgressions. The US could wage this war for many years all alone, and force the GCC to watch as the region burned. I guess, Trump's administration isn't willing to go as far as the current Israeli leadership may have hoped or wanted. That said, the war could very well still flare up, if the events from past 2 years following "talks" are any indicator.


Building coalitions is slow, deliberative work. Not a skills match for this administration, whatever your assessment of their overall aptitude is.

Using a single provider is a single point of failure. It may be that this provider has lots of internal failure modes, but you're still one credit card problem or fake legal request or one mistake away from experiencing the primary failure.

If you actually care for the resiliency necessary to survive a provider outage you should have more than one provider.

Which means you should be running your own origin and using the simplest CDN features you possibly can to make your use case work.


Again, there is no simple answer. It depends on situations and resources. Some systems might rely on multiple services. If those services are independent, in such system this might cause more frequent failures which might still result in serious outages even when only one service fails. For those kind of systems a single service provider might be more preferable, because a single provider might coordinate things more efficiently while with multiple providers you might wait longer until each one fixes its problem. For example, system A depends on system B. If both A and B depend on Cloudflare and Cloudflare has 1 hour outage, both A and B will have 1 hour outage. But if A and B depend on different providers, the situation might be similar for B but worse for A. This is because for A each hour of outage in any of the providers means 1 hour of outage. In such cases each additional provider might be an additional weak link.

> If you actually care for the resiliency necessary to survive a provider outage you should have more than one provider.

Well, that probably means duplication. This might be too expensive in certain situations. Also some occasional outages might be not a big concern for some, such as most bloggers.

I'm not downplaying the downsides of centralization. Certain things should be decentralized if it's reasonable. But it's not always that way.


> we locked a bunch of our most senior engineers in a room and said we weren’t going to let them out till they had a plan that they all liked.

That's one way to do it.

> When you create or modify files, changes are aggregated and committed back to S3 roughly every 60 seconds as a single PUT. Sync runs in both directions, so when other applications modify objects in the bucket, S3 Files automatically spots those modifications and reflects them in the filesystem view automatically.

That sounds about right given the above. I have trouble seeing this as something other than a giant "hack." I already don't enjoy projecting costs for new types of S3 access patterns and I feel like has the potential to double the complication I already experience here.

Maybe I'm too frugal, but I've been in the cloud for a decade now, and I've worked very hard to prevent any "surprise" bills from showing up. This seems like a great feature; if you don't care what your AWS bill is each month.


There is a staggering number of user doing this with extra steps using fsx for lustre, their life greatly simplified today (unless they use gpu direct storage I guess)

Good point. There's a wide gulf between being able to design your workflow for S3 and trying to map an existing workflow to it.

You literally missed the most important part:

"A transition from IPv4 to IPv6 seems far more easier especially since we already have 77% of people on IPv6."

So to the extent they're aware of the "issues" you bring up they're already on top of it.


ISPs providing IPv6 connectivity out of the box does not equal software and internal devices doing the same.

You can route internal IPv4 networks over IPv6. There are several mapping strategies so this can even be transparent at your v6 gateway.

I would love to see a relay switch at 1Mhz.

You will amazed. One reason is that relays are suitable for multilevel signalling. That is why the relays-only Fuji computer was on par with contemporary Amerikahito crap.

> though the red team did very much cheat,

My Army buddy once said "If you're not cheating you're not trying."

What did they expect? That's the whole point of a red team.

Reminds me of Admiral Ching Lee. He used to run red team exercises against US facilities. He once walked into a maximum security facility with a badge bearing the name and photograph of Adolf Hitler.


This is not a popular war. I would not use it as a milestone.

> If I played this for anyone and they said "it sounds like AI"

It sounds like AI.

> I'd confidently tell them they are full of shit.

Why are you getting offended on behalf of a computer? Or is there a deeper reasoning for this logic?


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

Search: