bsder

The ACA is, in fact, warmed over RomneyCare(tm) (a Republican, please note) from Massachusetts.

The fact that Kentuckians loved Kynect and hated Obamacare--which are the exact same thing (aka the ACA)--tells you everything you need to know about the Republican voting public.

I'm kind of especially surprised that an OOP person bounces of Scheme. OOP and Scheme both like to atomize things into webs of a zillion little functions.

The biggest advice I would give to the author is "If you're doing general programming instead of compiler construction, get off the goddamn lists, ignore recursion and use vectors and loops like somebody civilized. Don't write a macro until you have a gun to your head." Everybody I know who "bounces off" of Scheme/Lisps does so because of the idiotic "List Pedagogy" when the expert programmers almost invariably use vectors everywhere.

However, in this day and age, the lack of strong typing is a lot more of an issue. I've been more directing people toward OCaml rather than Scheme/Lisp nowadays--especially since they added multicore. However, similar advice attends: "Ignore the functional crap and type inference. Use vectors and put type signatures on all the things, you savage. OCaml works just fine as an "imperative" language."

Woof. Didn't even bother to proofread the AI slop. Wow.

I think we need a "Flag AI Slop" button.

I mean, if you have the boards, then you obviously have the definitive answer about layers. Can't argue that.

As you point out, if they designed this thing in the late 1970s, there is no reason for those giant arrays of drill holes. PCB design was definitely past this point by then and it would have been a hideous waste of time drilling all that just to fill them all up with wave soldering. It also blocks your routing terribly.

However, I assumed that this was likely a port of something from much earlier given the enormous lead times that aerospace requires (especially in the 1970s). There is absolutely no good reason to leave those extra holes which can become an assembly mistake otherwise.

"The Mitra 125, sometimes called "Mitra 15M/125" succeeded the Mitra 15 in 1975" That is the design that got used for the Spacelab Metra 125 MS in 1980, right?

I presumed that this was a port of a board which was a port of a board which was a port of a board given that design was obsolete even in 1975 since they apparently switched to the AMD bit slice processors even that far back.

And looking at Altair 8800 boards, you can see that the landing pads were very much NOT trivial, and look like they might even be hand drilled given the poor registration. Excellon/Esterline machines were still not that common outside of very high volume in 1975. By the time the Apple II came online a couple years later, though, the Excellon drilling machines were pretty commonplace.

Delimited continuation machinery? It seems like call/cc is becoming quite a bit more acknowledged as being overkill while the more restricted shift/reset, control/prompt, F-operator stuff, etc. compose better.

IBM was using flip chip in their mainframes in the same timeframe, too. That doesn't mean usage was widespread. This was 1970-1975, after all.

In addition, 2-layer has some big advantages over 4 layer for reliability (won't delaminate under launch vibration, for example)--which is an issue in aerospace.

And, to my eye, these boards simply don't look like the have 4 layers nor are the laid out like that: https://upload.wikimedia.org/wikipedia/commons/7/7a/Mitra_15...

Besides, even if it were 4 layers, the issue is still that drilling holes in a non-regular pattern simply wasn't something that could be done easily 1975.

> The PCB construction is curious (which you say is multi-layer) - why use a grid of 0.1" holes?

The claim is multi-layer, but I seriously doubt that. I suspect that these are two-layer boards.

And if that's the case, the pattern is most likely because the holes precede the etch. And possibly precede the copper deposition so that the copper deposition can coat the insides of the holes.

And the holes are in a regular pattern because CNC simply wasn't a thing yet. You probably had some fixed array of drill bits that were used to make the holes in a very strict fixed automation fashion.

I don't know how the author would feel. But, honestly, for a libc replacement, I'd personally be okay with that ...

If you can't be bothered to look at a Makefile (or ask an AI to look at the Makefile), you are almost certain to be more trouble than any possible benefit you will bring.

Especially in the realm of open source, I'm becoming increasingly comfortable with "If you can't be bothered to jump through even the most minimal of hoops, please get lost."

You could, of course, spend 30 seconds look at the code on Github which you would have to do if you were interested in using it anyway?

  TRIPLES = \
    x86_64-linux-none x86_64-linux-gnu x86_64-linux-musl \
    aarch64-linux-none aarch64-linux-gnu aarch64-linux-musl \
    aarch64-macos \
    x86_64-windows-gnu \
    wasm32-freestanding wasm32-wasi

Or you could actually try the compliance suite on an architecture and report back to us if it works?

> You can brute-force trying random things and checking the result and eventually learn something new.

And most of the mathematicians seem to welcome this "brute forcing" by the LLMs. It connects pieces that people didn't realize could be connected. That opens up a lot of avenues for further exploration.

Now, if the LLMs could just do something like ingesting the Mochizuki stuff and give us a decent confirmation or disproof ...

> It’s very easy to throw rocks at the greedy contractors, but I think the military is almost completely responsible for these costs. The acquisitions and contracting offices create these unfavorable deals, usually because of risk aversion and ignorance.

And outsourcing. The military doesn't want to hold inventory on these things, either.

So, the military wants to offload everything and then is so very upset that they have no leverage and get overcharged.

The solution is straightforward: in-house manufacturing capacity. Suddenly you have leverage against the contractors. And, since this is the military, they can make that change by command fiat. But they won't.

Outsourcing is only useful when doing it internally is an alternative. Once the external companies know that you've lost that ability to do it yourself and can't threaten them anymore, they're going to squeeze you for every red cent they can.

> So either all programming language constructs are merely remixes of existing ideas, or LLMs are capable of working in domains where no training data exists.

And yet LLM/AIs can't count parentheses reliably.

For example, if you take away the "let" forms from Claude which forces it to desugar them to "lambda" forms, it will fail very quickly. This is a purely mechanical transformation and should be error free. The significant increase in ambiguity complete stumps LLMs/AI after about 3 variables.

This is why languages like Rust with strong typing and lots of syntax are so LLM friendly; it shackles the LLM which in turn keeps it on target.

ContentID is generated internally by Google and you have to qualify (aka be able to threaten Google with lawyers) in order to effectively participate. It also seems to be defeatable by such advanced techniques as flipping the video left to right.

If SynthID works, this would allow people to tag their own videos with a watermark that is invariant across various levels of compression and editing. It would enable automated scanning of YouTube videos for uploads and the consequent class-action lawsuits.

Because of that, I can fairly confidently say that this doesn't work. However, it will function to divert some attention for a while. And that's what Google and OpenAI intended in the first place.

I guarantee this works poorly, at best.

If this actually works solidly, Google is in deep, deep, deep shit. It would mean that I can put a mark on my non-AI videos and demand that Google not allow upload of my identifiably copyrighted content.

This would completely obliterate YouTube.

The fact that they have to keep this closed source is a giant red flag. It means that you can copy it or strip it if you have the knowledge.

I'm not all that worried about stripping it (I'm sure that's trivial).

The problem that I am worried about is that it can be copied (I'd bet $20 that's trivial, too). People WILL put this on images so that they can be "discredited".

RNGesus is far, far, far too nice on this game. :)

In real gacha, the odds of pulling something good are generally super ridiculously low.

The odds are generally so bad that they will implement a "pity" system to avoid the awful PR from the common case of spending a ton of money and getting absolute garbage.

Because the tool will happily give you a "solution" that kinda works for a few inputs. It will happily correct itself when you give it more incorrect tests.

It will almost never converge on the general solution that will pass tests you haven't given it yet.

This is why AI is sooo good at Javascript and related slop. A solution that "kinda works" is good enough 9 times out of 10 and if some tests fail well ... YOLO and the web page will probably render anyway.

Contrast that to using Scheme or Lisp where AI will have trouble simply keeping the parentheses balanced.

> Well I can explain git to anybody who understands a DAG.

This. Right here. This is the difference.

I can explain Mercurial to people who don't want to understand a DAG.

For non-professional developers, the "merge machinery" is completely worthless.

The difference is that Mercurial lets you duck it until you need it while Git slaps you in the face with it at every commit.

For the non-professional developer, the flow is "commit, commit, commit, commit, whoops--how many commits do I need to go back to fix things?, oh, 2, okay--revert, commit, commit, commit, commit, ...

At no point in their day are they facing "merge". And that makes all the difference.

I'm already a quite happy jj user, but thanks for the recommendation. :)

> Possibly charged, but extremely unlikely to have a conviction stick if done intelligently. It would be a pretty massive Streisand effect, and almost certainly covered under first amendment protections.

What part of "The Orange Clown and his minions simply regard the justice system as a speed bump" are you not paying attention to?

> ICE has likely violated more court orders in January 2026 than some federal agencies have violated in their entire existence.

Ref: https://storage.courtlistener.com/recap/gov.uscourts.mnd.230...

In the meantime, you will sit in jail, pay money to lawyers, and possible wind up in El Salvador if you really pissed somebody high enough off.

But, sure, feel free to organize it yourself, please. We would all benefit from your actions.

I agree that the vast majority of punters don't care about "local AI".

However, if you can deliver 90% of the value of AI for 90% less cost, that is a really big incentive. Companies will spring up to fill that kind of gap.

Nobody can undercut the big AI players right now because they are all over-funded by VC money. Once the frontier companies try to match cost to expense, suddenly they become very, very vulnerable.

If you want to use Git with a sane UI, use Jujutsu. As a Mercurial user, you'll feel a lot more at home.

> About rm -rf ing a repo, I'm sure if mercurial was more popular it would also suffer from the types of coders that would do such things on a regular basis.

Nope. You are simply flat-out wrong.

I have taught Mercurial to CEOs, secretaries, artists, craftsmen, etc. It just worked. They understood the mental model and happily used it to protect their stuff. The people I taught Mercurial to who worked with CNC machines in particular loved Mercurial as it protected them against changing some wonky setting in their CAD program that screwed everything up that they somehow couldn't figure out how to restore.

Git I can barely even explain to CS majors. The fact that AI has so much training data and is so very, very good at explaining how to undo strange Git states is all the evidence you need for just how abjectly terribly the Git UX is.

Jujutsu has proven that the underlying structure of Git is acceptable and that the issues really are all about the UX.

> Is git really far worse technology than mercurial?

Git is far worse simply because of "staging". "Staging" may be necessary (I do not concede this) in big projects, but in small projects it's an absolute disaster to the mental model. Most people on small projects just want "checkpoint the current code in my directory and put a comment on it".

In addition, Git's UX is hot garbage. I would constantly be doing rsync on git repos before any operation that is slightly weird knowing that I may put the repo in some state that I cannot easily unwind. I never did that for Subversion. I never did that for Mercurial. I don't do that for Jujutsu. Those are all sane UX.

Side note: Thankfully AI is REALLY good at telling you how to un-wedge your git repo. That should tell you everything you need to know about Git UX and why you should avoid Git.

> the buttons on the 11C and 15C were awesome

What is the trick to engineering HP calculator keys? Nobody gets keys right like the old HP calculators.

In this age of 3D printing and fast prototypes, we really ought to be able to crack this.

> That's kind of already happened though.

It's a world of difference to the political standing of the ABC Vice President between "Nate Silver launched something and made a gazillion dollars" vs "Nate Silver bought FiveThirtyEight back for a song and made a gazillion dollars" even if Nate Silver did the exact same thing. In the second case, the ABC Vice President gets fired because he signed off on the purchase.

This is why long copyright is such a terrible idea. With long copyright, there is every incentive to sit on IP and do nothing with it because of political losses. With short copyright, the incentive is to do something quick because the copyright will expire otherwise.

> The question is - why do we still need the terminal abstraction at all?

Because nobody is willing to put in the work to create a GUI toolkit that doesn't suck ass.

It's not that people want the "terminal abstraction". What people want is "Put <thing> on screen without me needing a PhD in graphics programming." That's why the dominant desktop interface paradigms have become TUIs and a Browser-In-A-Trenchcoat.

Yeah, I mean, if I'm going to step away from the Python ecosystem and let AI manage/polyfill my dependencies, I might as well shift the whole way to OCaml/F# rather than Rust.

Then I get the benefits of GC and strong typing.

> Part of the practical degradation of traditional programmers over time has always been concentration and deep calculation, just like in chess.

I don't know if I agree that this is the bottleneck.

What I can agree on is that as I have aged I now simply REFUSE to learn programming knowledge that has a half-life.

Phone programming? Nope. Front-end web programming framework? Oh, hell, no. Build system of the month? Piss right off. etc.

AI lets me fill in that kind of programming with "acceptable" (read: super crappy but I didn't have to think about it) results because that code won't exist in 5 years anyway due to its half-life.

> People need to hear that startup success is maximal when the founders are older, not younger. VCs chasing youth are statistics deniers.

For building a successful business, older founders are more likely to succeed. They understand the business and see something that everybody else is getting wrong that they can correct and make money on. They will grind at it and have a profitable business for decades.

This is anathema to VCs.

VC's want a short term lottery ticket. They want your business to go big or go home. They would rather see your business fail quickly than grind profitably for a decade. Youth feeds into this in two ways. First, youth can align with the fad of the moment in the hopes of running a cashout while the iron is hot. Second, youth can be bullied into doing stupid things that a more experienced person will flat out tell you are stupid and refuse to do them.

This is the standard misalignment with founders and VCs.

The interesting question is whether experienced people can leverage AI to construct actual new businesses rather than just AI bandwagoning. The fundamental problem is that most successful businesses have to deal with customer service, and AI doesn't do jack to make that better.