- Fighting wars (more than one, in fact) to force a country into permitting unrestricted sale of opioids has historical precedent of course. The victim then was China, which tried to enforce their laws on drugs ... to the dislike of English Businessmen with enough pocket money to buy the army.
I for one would prefer to buy wine in a Utah grocery store. Or maybe even just a NYC supermarket. Even if it's wine from Texas, though I know that really stretches the meaning of "wine". And I'd also like to carry the bottle publicly as least as proudly as someone can carry their gun.
(oh how easy it is to trigger libertarian impulses. I'm with Voltaire in that one, say what you want. I'll fight - alongside you for your right to do so, and against you when I disagree ...)
- on the m68k, the "cisc-y-ness" is in the many many addressing modes, whereas x86 in that particular aspect of the architecture has always been rather "risc-y" (read: rather limited compared to other CISC architectures, including m68k).
The core instruction set of the m68k, as far as ALU/FPU is concerned, is simple enough. But converting the addressing modes to "risc building blocks" (μops or whatever term you like to use) is harder.
- A mandate for government orgs including the military to exclusively use "all domestic" suppliers is laudable but also subject to graft and corruption - companies need to compete to get into the "in" club and admittance will be "gated" by favouritism, political alliance, and whatever grease needed to get you into that club. And once in, you're always tempted to collude ... partition the pie amongst the "competition" while petitioning the government to grow the pie ...
Yes, you _can_ try to regulate your way out of that. It'll result in a giant thicket of rulebooks, laws, procedures and processes. Exactly what a "slim" state would not want to see ...
(I am not sure there is a perfect way out; "extremely strong" gating criteria though tend to always favour the incumbents, and a prescription of "100% domestic all the way through" is a strong gating criterion if I've ever seen one)
- They weren't "starting a job" in the US. Their (foreign) employer sent them onto an assignment abroad (to the US) to do their job. That's the difference here.
Even under ESTA, you can do some such activities - call'em "job" - in the US. On behalf of your non-US employer.
The devil may be in the details, but the assertion these workers were "likely" (or even just "potentially) doing a _US job_ (subject to a Visum qualifying for _US employment_) is definitely misplaced.
- Berlin also invested billions into rebuilding much of its metro system in the 1990s and early 2000s. Now, 25y later, with investment having dropped off, it's occasionally creaking.
That said, to "beat BART" isn't a milestone for any public transport system anywhere. Except ... in the US, where even BART stands out as great. Hmm. Relatively.
(one part of me is kinda curious how the 101 would look like if you didn't do any work on it for 20 years. Mostly because it'd probably be a rather cool setting for some dystopian movie. Anyway ... transport infrastructure, whether public transport or roads, costs a f*ckton of money)
- fair enough to notice though that while the Soviet Union may have had agreed to enter the war with Japan (at the Potsdam conference ?), it had not done so by the time the nuclear bomb on Hiroshima was dropped. It did declare war on Japan the day before the Nagasaki bombing. In a way ... Stalin chose the "let's go to war with Japan" date opportunistically. When it was clear there could be much gain without too much pain.
Which is not a dissimilar thing to the US "wavering" over the commitment to an invasion of Japan. The nuclear bombs "resolved" that. We'll never know what would have happened otherwise.
- "secrets in env vars" (or program arguments) always triggers squeamy smirks off me.
It's a bullsh*t rule. One that would work is a clear mandate, "if you're found to use env vars / args for secrets, you must demonstrate within four weeks of finding that you have implemented code to clear your process' args/env vars immediately after program startup, for the lifetime of the process (and that you moved all secrets to non-cleartext memory)". Given how frameworky-frameworky much modern software is, such action items make folks think ("how on earth do I get state to openssl&Co without env vars", ...).
But alas, the regulations people shy away from any such precise prescriptions - because then, they have to involve themselves with SRE, SOC, CI/CD, and developers for monitoring, enforcement and training/assistance.
So instead, as you say, byzantine Reuben-Goldberg constructs are created exploiting "every loophole in the book" to comply with the rule but not the spirit; software becomes even more of a performance art.
I think, over time, I have moved into the camp that strongly believes all practical security is security-from-obscurity. Starting with the compliance rules around it.
- nuclear never got economy of scale? There were hundreds of nuclear power plants built across the world in the 1970s/1980s. Developed countries went from "no nuclear" to "~20..30% nuclear" or more in less than 20 years. If that's not sufficient scale to be economical, then I don't know what would have been.
Historical evidence therefore rather suggests nuclear isn't economical at any scale once active subsidies are out. Current nuclear power plants under construction in the US or Europe, or recently completed there add more than evidence for high cost and major overruns to the pile.
Of course, one can go all conspiracy and claim that's only because of the deep anti-atom lobby, and because the cheap SMRs have always been torpedoed, or because Thorium molten salt reactors have been secretly killed by the military-industrial complex or whatever.
Occam's razor makes me think though, could it just be that nuclear was, is, and likely, at least for quite a while still, will be just so friggin' expensive that pretty much any "alternative" is more economical?
(back-of-envelope calcs say that if ~1.5GW electric from a new nuclear power plant cost ~20..40G$ to build .. between ~13..28$/W ... solar is <1$/W, there's a lot of spare change for batteries in that. Ok, that's pub talk. Still, if I have influence where my money goes, I'd only grudgingly accept nuclear for base load, subsidised as needed. Economics say, build what's cheap capex to build and then gives zero-opex energy when "running". There's no economic alternative to the "alternatives")
- It won't make it impossible for junior engineers to learn.
It will simply reduce the amount of opportunities to learn (and not just for juniors), by virtue of companies' beancounters concluding "two for one" (several juniors) doesn't return the same as "buy one get one free" (existing staff + AI license).
I dread the day we all "learn from AI". The social interaction part of learning is just as important as the content of it, really, especially when you're young; none of that comes across yet in the pure "1:1 interaction" with AI.
- Amen to that. I wasn't trying to encourage anyone to try their hand on distilling without learning more about it.
Only highlighting that one can "humanly relate" to Kelvin-based temperatures. If one so wishes. And that "reference points" there needn't be any more "arbitrary" than for °F/°C.
- The space on tube carriages is used for ... passengers. Unlike long-distance trains (where the locomotive is a rather sizeable unit of its own and has pretty much an electric substation of its own in it), the parts of a tube train reserved for driver, engines, electrical distribution are comparatively tiny.
see https://tfl.gov.uk/corporate/transparency/freedom-of-informa...
Seems not trivial to just put extra batteries and the circuitry for regen breaking charging in.
- You can booked timed tickets at https://www.barbican.org.uk/whats-on/2025/event/visit-the-co... but when it's open on weekends, one can also often just walk in. It's a great place to visit. Entrance is free.
As far as I'm aware, the Barbican Conservatory (Greenhouse) will close for refurbishment at a point next year though. When you go currently, they'll have details of the plans for public consultation. So see it while you can (or then again in 2030 or so).
- Symbian was not quite as great as you describe it there. Asynchronous/message-passing-based alright but with a non-scaling message queue model (servers couldn't horizontally scale because there was only one request queue - you always had multiple clients hammering one singlethreaded server). The ability to scale I/O on Symbian (via shared mem/paging) came too late to benefit Nokia (who was extremely tardy at adopting newer Symbian releases ...), and no multi-core ARM-based phone ever ran Symbian. It only got multicore support in v9 (the last) anyway. Did I mention it didn't have an ARM64 port either (press releases notwithstanding)?
"Symbian C++" used to be a great search term ... for clubkiness horror stories. Or at least warnings that "don't expect this to be your pal's C++". Nevermind the kernel actually used a more crude form (a C++ "standard library" for kernel code is ... challenging). Definitely not "easy to read".
Symbian (and Nokia) recognised this to a degree; hence the "posix environment" or the Qt purchase. Symbian 9 was a great step towards scaling it. It only got into a phone ... with the last Symbian phone ever made. Bit of a pity - it could never really show what might have been.
They were steamrollered. Things just happened too fast for non-unix-kernel based systems to take the then-imminent multicore and 64bit ARM. Nevermind other misses like keyboard vs. touchscreen (Symbian UIQ was rather nice to use but nokia's S60 was not). Or in Nokia's case, not going all-in on Maemo/Meego.
(yes, been there. Only at its tail end, and only stayed as long as I did because in 2009, the job market wasn't great. Nonetheless, I remember a few things - great, sad and stupid. Symbian had all of that and then some. And definitely, Nokia also had a few "Varros").
- > > [ on ARM ] > Hiring data (both open jobs as well as LinkedIn) show otherwise. Their design presence in UK and US is similar in size, and the India one is not far behind.
If you're saying here that ARM is a company with a large and near-even (by headcount) presence in three countries (and much more distributed overall), then I agree with you fully.
Else, what was your point again ? You said in your first post that a majority of ARM (based on what metric?) comes off Austin, and that is not true by your own later words.
Anyway, I also agree we should be proud of the work done by companies such as (for example) ASML or ARM. Irrespective of where that happens, to be honest.
- Final assembly != "entirely manufactured". Cymer brings the EUV lightsource, Zeiss the optics, ASML the mechanics and metrology. Commercial EUV Lithography system(s) aren't "a single parent's baby" even if there is now only a single supplier.
ARM IP ? I gather in Cambridge/UK they'd disagree with you. Even if in classical English stiff upper lip style they may say it less brashly (but not less harshly) than a Texan.
This World is rather intertwined. Maybe more than we like or even more than is good for us. But all of us will loose if we strive to kill cooperation or trade "across borders".
It's definitely much easier and much much cheaper to send a single rocket there blowing the assembled rather large target into still sizeable chucks of orbital debris than it is to deploy and assemble the thing there in the first place. And there are a few terrestrial actors rather capable of this. More than there are who could make it happen under whatever optimistic assumptions anyway.
In itself, a structure of this size in orbit is an efficient catcher of micrometeorites and orbital debris. Over "non-eternal" timeframes you don't even need a bad actor with good rockets.
Nevermind that in such a case, the eventual fate of these sizeable chunks of orbital debris is to become rods of god ... just without particular steerability.
It'd be a sight.