Can’t release data sets if they can’t be sufficiently anonymized so as to avoid Privacy Act/other non-disclosure statutes. Can’t anonymize data sets sufficiently if you’re banned from using the techniques data people use when anonymizing data sets. Not that difficult to follow.
That’s another reason there just isn't any point in looking at these articles anymore unless they take you on a trip deep in the weeds of some specific problem or example. We need deep case studies (pro and con), not bulleted lists and talking points.
Yeah, i’ve gone to the point where I will just stop reading AI posts after a paragraph or two if there are no specifics. The “it works!” / “no it doesn’t” genre is saturated with generality. Show, don’t tell, or I will default to believing you don’t have anything to show at all.
I’ll give you an example: the technology in the Instrument Unit on the Saturn V, which was the computer that controlled the Saturn V during launch, was largely derived from System/360. By technology here I mean things like the Unit Logic Devices (ULDs) out of which the logic boards in the Launch Vehicle Digital Computer (LVDC) were made. No surprise, I suppose, given that it was contracted to IBM’s Federal Systems Division.
> * I'm not seeing what makes SpaceX government funded beyond just that it provides services to the government*
Take away all of SpaceX‘s government contracts. You imagine SpaceX would still be in business?
As you said, every launch provider is basically dependent on government contracts to stay in business because the government is the only entity that has a legitimate need for launch capability such that it’s willing to pay for its development. There are no sufficiently profitable private contracts out there to sustain a launch provider.
Yes, this. And the reason why congressional appropriations plummeted was that no one saw any need to maintain such high expenditures. There hasn’t been an actually coherent vision of what NASA is supposed to be working towards since the Apollo Program. Everything after that is lurching from one project to another, justifying it based on short-term possibility rather than committing to a longer-term goal the agency is supposed to be achieving. Just look at Shuttle. It accomplished some nice things, but it was always a dead end. Everybody in NASA knew it. ISS: accomplished some nice things, dead end. Sure, you can talk about how these were steps along the way to learning about long-term human habitation in space, but we’ve never had a coherent vision for that that everyone is aligned with. What they really were: make-work projects that were at least short-term justifiable, executed in order to preserve NASA’s capacity to do anything at all.
Nah, that’s false. Miniaturization was already underway before the Space Race. The space program absolutely benefited from it, yes. But NASA wasn’t at the forefront of those developments.
Dude’s been arguing with people since at least 2012 that systemd is a good thing. It took me less than a minute to figure that out by searching his blog.
It was very odd to start a “review” of a book from 1992 by criticizing it for lacking all the things you think a book published in 2025 should have. And then searching GitHub for code related to it, like TFA is expecting this to be something widely read as an introduction. TFA never considers who the target audience for the book was—in 1992, hardly a year when books about compilation techniques were looking to reach a wider audience (like Nyquist’s book Crafting or something).
It’s almost like what really matters when something goes wrong is who responds to the incident. There are individual human beings who genuinely give a shit about customer service, and will move heaven and earth in order to help customers. And then there are other individual human beings who want to do as little as possible, when confronted with an issue, and blaming the customer is often the shortest route to minimal work.
It really doesn’t matter what the organization’s policies and procedures are. At most, an organization’s culture may affect this, by nudging marginal cases to align with the culture. But in the end, it always comes down to individual human beings.
No, because the first one isn’t talking about writing documentation. It’s talking about knowledge discovery as a learned skill that eroded when web searching replaced how knowledge used to be sought. They actually say: even in the new-fangled domain of web searching, which you would think web natives would be better at, it’s actually people who had learned the skills and techniques of knowledge discovery pre-web who were better at finding what they were looking for. Now, why they think that is the case is a bit harder to grok, having to do with their object-oriented (sorry, sorry) view of understanding/knowledge.
Contrast that with the second quote. Good documentation could be in a dusty book in the library or in a SPA. What makes the documentation good isn’t, however, related to people’s ability to navigate information spaces.
Yes, but it became more than just Linus and Greg’s view that couldn’t be overcome by outside argument, and became more formally Kernel Policy once they became a CVE number assigning authority.
This has to do with their policy on assigning CVE numbers, which is that pretty much any bugfix might be security-related because it’s the kernel, so it doesn’t take much to get a number assigned. See https://docs.kernel.org/process/cve.html.
Many other statutory schemes were enacted afterwards that placed additional restrictions on the tariff authority Congress gave the President. You can’t read one section of one statute and just assume it alone applies. Just look at the variety of crap you can find in Titles 19 and 50 having to do with trade policy.