topspin

> but, uh--why only 10 or so photos?

The instrument is operated according to a detailed schedule that spans years. It takes a committee to create the schedule, and each separately scheduled observation is then organized by a team, with different teams organizing different observations.

They cannot simply aim the instrument at one system and forego everything else. The result you see is a campaign credited to at least four team members, and enough schedule time committed to make approximately one observation per year.

> If this remains a long term design limitation

It is not a long term limitation. One might design any number of stages to fly in place of Starship on top of the Super Heavy booster.

Also, large science payloads can be launched by SLS. Back in the days of the Ares program, there were proposals to launch an 8 meter reflector (ATLAST-8m)[1] using Ares V. SLS anticipates payloads of such size as well.

So there are at least two viable platforms on which enormous space mirrors might launch, and one of them is likely to be highly cost effective. It's up to the science establishment to propose such missions and get them funded.

[1] https://ntrs.nasa.gov/citations/20100004890

Yes, I don't argue that IBM's ways are advisable. The revenue of the top ten big tech companies are all 2-10x greater than IBM, which is ~21 on that list.

IBM won't entertain your recommended strategy. IBM wants deep-pocketed institutional money: the sort of broad-based popularity you hope for has no value at IBM. Governments, banks and monster health care operations are the only customers IBM really cares about for their computing products.

I know IBM has been employing a large number of people to work on Linux. I'm not as concerned about the eventual wind-down of that as I might otherwise be: Linux is the global lifeblood of enterprise computing, and there are a lot of other existing and potential sources of wealth in this world to employ Linux developers. A dispersion of this talent, with the inevitable shift in focus to things that are not strictly IBM's prerogatives, might have a real benefit for Linux.

Past that, software development has suddenly become cheaper in any case: Linux is in the optimal position to benefit greatly from the good parts of that, largely due a legacy of good leadership, so perhaps employed developer headcount doesn't have the importance it has always had.

In any case, I have every faith that Linux's future is not tightly coupled to the fate of whatever Red Hat withers into: there is too much at stake for too many well-resourced entities to permit Linux to suffer at the hands of IBM. If you need evidence for this, consider the outcome of the IBM's attempt to tighten their grip on the RHEL distribution, and the stampede to rapidly established alternatives this induced. If more of that is in Linux's future, so be it.

The best theory I've heard (Alex Hollings) is that NASA is doing an exterior refurb to get the plane ready for a big reveal of some other exotic aircraft: putting it on stage with the new thing for glamor shots.

> because Google is a little bit more frugal and focuses on how to make providing AI models financially feasible

That feels right. It's not as if they've been missing out on great profits.

> but the V8s probably isn't one of them

You can credit card as many ready-to-run 9L+ V8 engines as you want[1], built to modern tolerances using high quality tooling, tested on a dyno and equipped with a warranty. Maybe different mounts and/or couplers are needed, but that's a very finite problem.

I suspect one actually difficult problem would be finding a refiner that can make the special fuel used in the unique engines of the SR-71. Then again, the US has a great many agile refiners at its disposal.

The SR-71 is a rather awkward thing to operate. Fuel leaks out of the tanks until atmospheric friction heats the aircraft enough to make them seal. It's a big mess, and the cohort of people that were actually capable of making these things work is aged out of the workforce. Assuming any of this real, NASA must have something truly extraordinary in mind to consider this.

1. https://blueprintengines.com/

> "Nerf"ing models isn't real in the vast majority of reported cases.

That sentence... This conversation is indistinguishable from a billion conversations had around multi-player online gaming.

It's worked for online PvP gaming for a long time. Nerf stuff the min-maxers "earned" through game mechanics and sell over-powered "premium" things to everyone else to pwn them. Then nerf the old premium stuff and make new premium stuff. Forever.

I don't know if that's the actual origin of the term nerf, but it was the first time I'd heard it.

"The one thing plan mode helped is for the humans to get an understanding of the strategy"

For me, this phase still happens, but a distinct "plan mode" is unnecessary: I just tell the model, "This is discussion; no code changes yet." and spend hours figuring out what will and will not be done.

"Are there any special rules"

Yes. Paragraph #1, sentence #1 of the US Constitution: "provide for the common defence[sic]". This is further elaborated upon in other original Constitution articles and subsequent amendments.

From that, we derive a long, storied history of things, among the more recent of which, and the operative matter here, is the Defense Production Act circa 1950.

The US is fundamentally based on the obligation of mutual military defense, and delegates the authority to call military balls and strikes, such as who will and will not be permitted to contract with the US military, exclusively to POTUS. Anthropic et al. are way out of their depth when they imagine their "terms and conditions" imbue them with some sort of military veto power in the US. Trump's action here, given his nature, is actually moderate: he could take this much further if he wishes.

> outsourcing

One of the more popular means of diffusing responsibility. A mere symptom, in other words. Not a cause. There is a abundance of qualified contractors in our world that could provide a functioning fail-over solution using whatever medium one might imagine. Somehow, this does not happen. The problem is elsewhere.

But what if the actual bottleneck isn't the size of the various cohorts of people, but a bureaucracy that inflicts some irrational set of conditions that impedes competent operation? If so, then changing media won't help; whatever scheme you envision will fail.

I'm rather certain the FAA does indeed either employ or contract people that are capable of providing the solution. I'm also quite certain those people live in a perpetual blizzard of responsibility diffusion bullshit: the FAA is a venerable and highly risk-adverse operation. If someone told me it takes months of meetings and sign-offs to so much as log into a router and perform a benign check of some setting, I wouldn't blink.

Competency appears to be the limited resource here.

The goalpost in a on a trailer, cruising on the highway.

GE9X aircraft engines have 3D printed low pressure turbine blades, so I think the view that jets are somehow exceptional is already disproven. There are real benefits to using additive processes for turbojet/fan applications: many jet components have intricate passages and bizarre shapes to conduct gasses, and they are hideously expensive to manufacture with conventional tools.

Yes, that's the usual way. With SpaceX, however, Raptor engines are gimbled with electric actuators.

And yes, the TVC adds very little to the complexity of Raptor 3's appearance: it still looks like science fiction, even when operating in Starship. Had TVC been present in the original SP1 image that had Tory accusing SpaceX of misleading everyone, it would have made no difference.

> TLDW

That video has beautiful shots of Raptor 3 firing and gimbling. It's worth watching.

It depends. This product is pretty niche, and when a ~$3 MCU gives you the headroom you need without a team of career engineers on the payroll, it can make sense. Also, it's running USB power as opposed to batteries.

MCUs are getting crazy. ESP32-S31 running Linux. 40MSPS/12b ADC+DSP on dsPIC33A. New Renesas parts running a 1GHz. RP2350 roflstomping things with PIO. The Cortex M7 in this story is actually pretty old now: circa 2019.

Fun times.

> Being the first country to put weapons in space

The distinction of first (known) deployments of orbital kinetic weapons belongs to the Soviet Union. In 1968, they tested an anti-satellite system by intercepting a target satellite with a interceptor satellite and detonating it (Kosmos-249/Kosmos-252).

Later, in the 1970's, the Soviets deployed and test fired Rikhter R-23 23mm revolver cannons from Salyut military space stations.

> except the high priests of the LLMs / nascent Cthulhoid godlings

Let's not be this flippant about where the real pressure for this is coming from. Presidents and their appointees come and go. The people pushing the regulators[1] are not subject to US election cycles. It's important to know who they are when we aim our finely honed fingers, even if we find that these folks were formerly virtuous and mighty green energy advocates, because if your solution is merely different figureheads, all that will really change is the scale of the bribes.

[1] https://www.datacentercoalition.org/members

mmap(2) in Unix predates Linux itself by several years (1988 Sun, 1990 BSD). mmap(2) was present in Linux well before any of the high performance databases, file systems and other applications that use(d) O_DIRECT appeared on Linux.

O_DIRECT was resisted by Torvalds and others, but it's there today, and used by supposedly important platforms. Nvidia even has an API to DMA data to and from GPUs that uses O_DIRECT. There are folks working on new async WAL O_DIRECT for PostgreSQL as well.

So what can be said? mmap(2) isn't sufficient for certain cases. Torvalds has faced and successfully navigated difficult design choices in a pragmatic manner. What else?

The lesson I take is this: there are levels to implementation complexity and value. The wisdom to decide the appropriate abstraction level is crucial. You are unlikely to be equipped well enough to beneficially utilize O_DIRECT, but it's not impossible and some, in fact, are so equipped.

It's more about frequency than priority. When something has to be serviced tens of thousands of times a second, "a dozen or so" becomes a problem. If you have the silicon that solves this, you can retain the model. If you don't then you have to resort to workarounds.

Fortunately we typically have more efficient means to deal with such hardware, but not always, and it would be a shame to break the intended model when this is the case.

SpaceX has >11,000 satellites whipping around the planet. They increased the number of LEO sats by nearly one order of magnitude in bit more than 5 years.

So apparently, in the US, the culture, expertise and infrastructure do exist to do these things.

Whatever OS/applications you have run in low priority ISR contexts, taking however much time they wish. When a high priority interrupt happens, the lower priority ISR contexts are preempted and then resumed after the high priority ISR is complete. Go have a look at the design and the SRP model behind it; your questions are directly addressed there.

> On more complex systems there is a pretty good chance you will end up with locked up hardware if your ISR is long enough.

That is true of all such systems, from MCUs to the greatest CPUs ever made, and all prevailing software stacks running on them. Nothing about RTIC precludes servicing interrupts in a timely manner. It is based on a mathematical model of concurrency called Stack Resource Policy (SRP) and is entirely capable of reliably implementing whatever interrupt regime you imagine your "complex" system requires, with zero risk of priority inversion.

> prioritization is a job for the OS, not the hardware

So say you. The long and storied history of fragility and failure related to scheduling and interrupt handling suggests there is opportunity for greater rigor than the conventional muddle you assert as best.

I am aware. That "dozen or so" is a problem: when everything is an interrupt, there are no interrupts: it's just scheduling, and things that must be scheduled frequently can't suffer "a dozen or so" overhead. For the SRP model to really hum, you need the silicon that solves this.

> The best case latency is higher than doing the work at interrupt level

One approach is to do everything in ISRs, a la RTIC. That requires efficient, vectored, nested, tail-chained, base priority-ed interrupt silicon, and a lot of it, but it is feasible and elegant where this exists, such as Cortex NVIC. Emerging RISC-V devices with xCLIC (ch32v, gd32v, newer ESP32 and others) are potentially even better.

I really appreciate that the author took the time to add the Embassy vs RTIC addendum.

> How does one convince business leaders to bring it back?

There are precisely 1.0 ways to do that: make all of the alternatives more expensive.

That's it. Nothing else will move the needle.

I don't believe it is possible: every policy one can imagine, short of establishing a GULAG system to compel compliance, has powerful opposing interests, including workers themselves. It would require the sort of comprehensive and sustained focus that a nation aspiring to nearly suicidal liberalism can not deliver.

> I believe the math says the I6 is smoother than the boxer 6

Both designs (I6 and boxer) can have perfect primary and secondary balance. An I6 should be a smooth ICE, but there are other sources of vibration in these systems beyond inherent balance of reciprocating components.