The nukes are to deter the US. They have been steadily increasing their missile range to first reach regional bases like Guam and now the all the way to the continental USA, and are now even launching a nuclear powered and nuclear armed ballistic missile submarine https://www.hisutton.com/DPRK-SSN-Update.html
The nukes are a bargaining chip (disarmament). Basically, if your country has the human and tech capital to develop a nuke, you probably should because it's free money.
I don't believe that NK's nukes deter the US from doing anything. Would NK nuke Guam and risk getting carpet-bombed with nukes for endless days and nights until even the ants are dead? Artillery on Seoul doesn't matter. The US would just ask SK to evacuate it.
The US doesn't do anything about the DPRK because it's not economically relevant (i.e. it doesn't have the world's largest oil reserves etc). In an ironic way, their economy being closed-off and mostly unintegrated with the Western world maintains the peace.
The nukes have many roles perhaps but I think the fully developed weapons are for retaliatory strike.
They are the North Korean leadership saying that if the US (or China or anyone really) tries to surgically decapitate them (like the US just did in Venezuela) then the nukes are used to take the attackers with them
Yes that's the orthodox doctrine of nuclear deterrent. To be truly effective you need a triad of land-based ICBMs, nuclear-armed submarines, and aircraft-based delivery systems so that your second-strike capability remains intact through any decapitation attempts.
If you don't have the triad then you need to brandish your capability more ostentatiously, like France does with its deliberate refusal to commit to a no-first-strike policy. This is (one of the many reasons) why North Korea does so much sabre-rattling: they don't have a (publicly known) nuclear triad for deterrence.
Just a note that the importance of the triad is a very American perspective on deterrence and most other countries don't seem to approach this the same way the US does.
The Russians really have a quad (they also have mobile, truck mounted ICBM's that form a significant part of their deterrent, offering some of the guaranteed second-strike advantages that the US gets from SSBN's- and which their SSBN program does not provide nearly as well as the USN does). The Chinese only recently added a manned aircraft leg of their triad with the JL-1. The Indians technically have a triad- just no silo based systems, all of their land based missiles are from TELs, and they only have two SSBN's and do not do alternate crews so more than 1/3 of the time they don't have any deterrent at sea. The Israeli's are not believed to have any sea-based ballistic missiles, their sea-based deterrent would be Popeye cruise missiles and so vulnerable to interception. The Pakistanis are still building their first sea-based deterrent. The French and the UK have no land-based missiles, they are only sea-based and airplanes. The South Africans invested in the Jericho missile more for its space launched capabilities than its warhead delivery abilities, and never really looked at anything sea-based, so far as is publicly known.
I don't think they fill the same strategic purposes, though. The value of silo based missiles to the US is as a missile-sponge, taking most of the warheads from a Russian first strike and keeping them from American cities (forcing any Russian first-strike to be counter-force instead of counter-value). This is not particularly valuable, honestly, which is why only the USSR during the height of the Cold War (largely in reaction to Minuteman) and China very recently have also made the investment into large numbers of ICBM silos.(1)
I won't claim to be as much an expert on Russian doctrine, but they seem to consider their mobile missiles to be a survivable second strike weapon, while silo based missiles are obviously not. Because their boomer fleet does not offer the same assured second strike, they rely on those mobile missiles to play a greater deterrent role then the US does.
1: That is the official justification for the US silos. The real reason for silos is, if you want to build a truly insane number of strategic warheads, silos are the only way to afford it- ships and planes and even TELs are too expensive. So first the US (worried they were behind because of the Missile Gap) built a thousand Minuteman (then tripled the deployed warheads with MIRV on the Minuteman-III). Then the Soviets responded with 1000 SS-11s of their own. But if you are only building a few hundred warheads total, you don't bother with silos, they don't add as much value as other delivery mechanisms.
I'm saying: Whether or not the Russians consider their silos to be more or less survivable than their truck-based missiles is immaterial, and doesn't change the calculus at the strategic level, because one of two things has to happen in a first-strike situation:
- You blanket the entire country in nuclear detonations and pray that you catch all the trucks scurrying around like nuclear-armed mice
or
- You spam dozens of missiles at a small number of hardened targets and hope you dent them (missile sponge silos)
Either way, you're severely depleting your arsenal to an infeasible level to do this. These are both counter-force attacks where targeting is the only difference, which the Strategic function does not concern itself with. That's a tactical consideration. Survivability of a land-based asset achieved by different means is still survivability of a land-based asset. In other words, it's still functionally a triad.
In the case of France in particular, the argument I recall reading is that: a) France was entering a period of austerity in defense spending as the Cold War ended, b) its siloed missiles were obsolete and in need of upgrades which promised to be costly, and c) France isn't very large geographically, so the "missile sponges" were limited to that little plateau north of Marseille which is pretty darn close to several major population centers, where an Ivy Mike-sized airburst could endanger Avignon and Marseille, not to mention leave a plume of fallout all the way into Germany.
But I'm just an ex Air Force officer who's been to France a bunch, so idk how accurate that is.
>The real reason for silos is, if you want to build a truly insane number of strategic warheads, silos are the only way to afford it
Yeah, I guess I mentally slot road mobile missiles as more like "less effective SLBM on the cheap," at least for a country the size of Russia (not sure that is as true for someone like North Korea where I speculate there is a larger use-it-or-lose-it penalty). There is definitely more of a continuum here between "missile-soak" and "survivable deterrent"- e.g. at the limit you could, in theory, vaporize all of the oceans with nuclear weapons to kill all the boomers, which turns them into missile soaks, but at a truly insane level.
I've seen open-source estimates that the 33rd Guards Rocket Army can distribute their three divisions of mobile missiles across something like 5,000 square miles of Siberia, mostly steppe/taiga (which the 7917/79221 are supposed to be capable of launching from, again according to open source reporting). That's more than 10% of all of North Korea, to give an idea why it would be different for the two countries. Being open-source, I don't have a good estimate for the survivability of the TEL, but let's somewhat arbitrarily say 5PSI is the limit. A 300kt W87 can put 5PSI over 3 mi^2, so doing 5,000 mi^2 would be about 1700 of them, for a grid-square blanket search. That seems to be impracticable, just for one third of their missiles(1).
So I think it's more about guaranteed second-strike than soaking (e.g. at three warheads per silo you'd need ~600 missiles to soak up that many warheads, instead of the 70-odd from mobile). Which is why I have seen some people consider those missiles as more about assured second-strike than missile-soak, with hints that the Russians consider that their role. The Russian doctrine does not align exactly with the American one (2) for sure and there are hints that the Russians consider road-mobile to be different from silo deployments.
1: I'm not as clear on how much deployment space the 27th Guards Rocket Army, in the European parts of Russia has, and whether they will run into similar problems to the French wrt population centers. There is also a whole separate discussion about how much counter-force and counter-value are truly separate on the receiving end, given, e.g. if Barksdale gets nuked Shreveport is going to be very very sad. But the RAND people were sure they were distinct!
2: At least, as far as this monolingual American can tell. My main source for this is the Arms Control Wonk blog and podcast, which actually does read and report on what the Russians describe as their doctrine, they are my source for the "Russians seem to consider road-mobile as more survivable second-strike than silos."
> To be truly effective you need a triad of land-based ICBMs, nuclear-armed submarines, and aircraft-based delivery systems
The core parts for MAD land-based missile silos (to soak up the enemy's missiles) and submarines (to ensure a second strike). Planes are largely a diplomatic deterrent inasmuch as they're easy to send out and easy to recall.
But Pyongyang isn't playing MAD. It's playing credible threat. And for a credible threat, you just need missiles. (On land or on subs.) The point is that you raise the stakes of e.g. a Maduro operation to risking Los Angeles.
Strategic bombers are just as important because MAD itself is fundamentally a political and diplomatic tool. The reason you have strategic bombers is, as you correctly said, so that you can signal your posture and intent by stationing them, dispersing them, launching them, and (most critically) recalling them.
But again, because MAD first and foremost is a deterrent, you want to provide diplomatic offramps for both you and your adversary. This is crucial. Putting the B-52s on airborne alert sends a very strong message, but so does recalling them from airborne alert.
By their very natures, SSBNs and ICBMs are not capable of playing this role.
It’s oblique but this puts me in mind of an old adage I recently heard about war: Of 100 men, one should be a warrior, nine should be soldiers, and 90 shouldn't be there at all.
I think this is true of software developers too: only in companies, the 90% don’t really know they shouldn’t be there and they build a whole world of systems and projects that is parallel to what the company actually needs.
My memory is there were a spate of SO scraping sites that google would surface above SO and google just would not zap.
It would have been super trivial to fix but google didn’t.
My pet theory was that google were getting doubleclick revenue from the scrapers so had incentives to let them scrape and to promote them in search results.
I remember those too! There were seemingly thousands of them!
Reminds me of my most black-hat project — a Wikipedia proxy with 2 Adsense ads injected into the page. It made me like $20-25 a month for a year or so but sadly (nah, perfectly fairly) Google got wise to it.
Honestly, if I'd gotten in earlier I bet it would have made more. I also made zero attempts to SEO it -- there were no links to it anywhere else on the Internet, so it would have been in the very first tranche of useless duplicative spam sites of that type to be cleaned up. It was up from like 2010-2013 or so.
Another plausible explanation is that the new owners didn’t develop the community in a good way. Instead of fixing the myriad of issues that were obvious to almost all contributors they instead basically let it die?
The new owners (well, not really new any more) are focused on adding AI to SO because it's the current hotness, and making other changes to try to extract more money that they're completely ignoring the community's issues and objections to their changes, which tend to be half-assed and full of bugs.
No. I suppose I’m less confident in that, but I still don’t think it’s very likely. The American oil companies with contracts in Guyana would certainly be unhappy about it and it’s not clear what political benefit anyone in the US could hope to gain.
My application's primary task is to move JSON objects between storage and front-end. It does a lot more, but that's it's primary task. So document storage is a logical choice. There are no real reasons to join records, although it sometimes is more efficient to do so. MongoDB's join operation has one advantage (for 1:N relations): it groups the joined records as an array in the document, instead of multiplying the answers, so whatever function operates on the original data, also works on the joined data. The data itself is hierarchical in nature, so back-end operations also preferably work on structured data instead of rows.
You can argue that you can imitate that in Postgres or even SQLite by storing in JSON fields, but there are things they can't do quite as efficiently (e.g. indexing array contents); storage itself isn't very efficient either. But ignoring that, there's no functional difference: it's document in, document out. So then the choice boils down to speed, memory usage, etc. One day I'm going to check if Postgresql offers a real performance advantage, but given the backlog, that may take a while. Until then, MongoDB just works.
I consult for a small company which feeds some of the largest market research companies. This company finds data providers for each country, collect the data monthly and need to massage it into a uniform structure before handing it over. I help them scripting this. I found importing the monthly spreadsheets into mongodb and querying the set can replace an awful lot of manual scripting work. That aggregator queries are a good fit for an aggregator company shouldn't be that big of a surprise, I guess.
The mongodb instance is ephemeral, the database itself is ephemeral, both only exist while the script is running which can be measured in seconds. The structure is changing from month to month. All this plays to the strengths of mongodb while avoiding the usual problems. For eg one stage of the aggregate pipeline can only be 100MB? A source csv is a few megabytes at most.
Ps.: no, Excel can't do it, I got involved with this when the complexity to do it in Excel has become unbearable.
To be honest, I don't think it was a stand-out 'it's better for X than Y because of Z' kind of choice for us. We are a bank, and so database options are quite limited (it's Oracle or Mongo, essentially for certain applications).
I have one application at the moment which needs to handle about 175k writes/second across AZ's. We are not sharding at the moment, but probably will once scale requires (we are getting close) -- so just one big replica-set and it's behaving .. really nicely. I tried to emulate this workload on Postgres (which is my favourite database over my entire career so far (many scars)) and we couldn't get it to where mongo was for this workload, multi-az is painful, automatic failover is still an unanswered question really, I've tried all the 'right around the corner' multi-master Postgres options and none of them did anything other than make us sad.
From the developer standpoint, it's very nice to use, I just throw documents at it and it saves them. If I want an extra field, I just add it. If I want an index on something, also just add it. No big complicated schema migrations.
Especially what helps is we have absolutely incredibly great support from MongoDB. We have a _weekly_ call with them with a bunch of their senior engineers who answer all our stupid questions and proactively look for things to improve.
Ops story is also good, we aren't using Atlas, but the on-prem kube setup while a bit clunky has enough CRDs and whatever to keep devops happy for weeks at a time.
tl;dr -- it's boring and predictable, and I rarely have to think about it which is all I ever want from a database. I'm sure we could achieve the same results with other database technologies, but the ROI on even investigating them would not be worth it, as at best I think we would end up at the same place we are at now. People seem to have deeply religious feelings on databases, but I've never really been one of them.
> From the developer standpoint, it's very nice to use, I just throw documents at it and it saves them. If I want an extra field, I just add it. If I want an index on something, also just add it. No big complicated schema migrations.
This sentence summarize all the issues developers working with Mongo will have: multiple version of documents living in the same DB and unpredictable structure
Best thing MongoDB have it's definitely their marketing (making everyone think it's amazing to invest hundreds of millions to deliver an "OK" tier database) and their customer support
Eh, not really. I've done both at considerable scale, and I don't hit these problems. Perhaps you need better developers? For sure, having your database enforce guardrails on what $thing should look like means your code can be lower quality, but you should pick the right tool for the job. For scenarios where I have one 'thing' that's not very relational, it works well. If your application dies because your $thing expects some field which isn't there, that's a you problem not a storage problem.
reply