Normal industry: Your factory has an expensive milling machine and a cheap stamping machine. Thankfully, customers actually seem to prefer stamped parts for most cases and you can produce those quickly; so you keep stamping out parts and rolling in cash.

Tech industry: As above but your entire c-suite believes that the milling machine with turn into mecha-jesus and end history; so you are bulldozing everything you can to build more milling machines.

It seems likely that the answer to this question is 'yes'; but it seems like a mistake to be distracted by it when we are talking about people who are, busily and intentionally, building 'AI' products against the public.

It's mildly comical when they attempt to emulate humanity; but the important bit isn't the cluelessness; it's the malice.

I suspect that this would be more tedious(and potentially less flattering); but you'd think that the metric you'd really care about for the juche-computer would be component availability.

Going by cost is interesting if you are trying to get the attention of balance-of-trade types and tariffs and dumping hawks; but it's an almost perfectly wrong measure if you are trying to catch any "oops, turns out that only the Chinese vendors so hungry they are considering offshoring to Vietnam still make a random passive or unexciting tolerances switching IC because it's a zero-margin part with no real room for differentiation that everyone who could got out of years ago" type situations.

If it's a real, drop-dead, 'national security' problem some of those are probably less serious, if there's a much fancier TI part that is overkill for the job but could be subbed in for only 3-4 factors of ten more; but if you want to keep economically viable civilian production open or it doesn't have a direct upmarket analog that could get really awkward; even if you've ensured that all the fancy logic ICs, copper, and gold are geopolitically friendly.

That's basically the Nexperia story, slightly simplified. Philips decided to private equity semiconductors generally; NXP decided to shove a bunch of the boring parts out to WingTech; then 'oops' European manufacturers who need diodes and ESD protection parts they thought were cheap jellybean stuff have cars piling up on the line because they can't get them.

Obviously losing a really cutting edge capability isn't preferred; but it's also the sort of thing that people notice because those tend to be pretty valuable; while low and middling capabilities, including ones that are sophisticated enough that you can't just throw money at restoring them fast, are things that are voluntarily surrendered because getting rid of low margin products makes line go up.

This seems like a great pick if you want to be absolutely sure that your computing stays between you, the techbros, republican loyalists in 'national security'; and possibly an Israeli software partner or two.

At least no chicom lithium stealing your thoughts.

"with some employees complaining about issues with style, paragraph formatting, blank pages, and challenges with tracking changes." sounds like they got the replacement they were looking for to me.

I didn't mean to imply that it is a single monolithic application, it does consist of several, but the relations must be pretty tight for there to be an article not even about language-independence; but about support for a single additional language, one often targeted by "C but cleaned up" efforts,

I was honestly surprised to see this myself. Regardless of its reputation for being more monolithic than classic init systems it still is, and has to be, capable of interacting with basically any flavor of service you'd want a service manager to manage; and I would assume that it doesn't include a d-bus implementation in order to not be capable of abstracted inter-process communication.

No doubt there are considerations at work here that I'm not smart enough to grasp; if you aren't having a bad time handling x.509 certificates you probably aren't doing it carefully enough; but I would not have expected it to be remarkable at all for a certificate-wrangling component to be implemented in a different language than some of the other components.

I assume that this is more pragmatic than just waiting for Sam to finish lying about transcendent AGI; but it feels a little dissonant to have the botmongers going back and forth between praising the glorious natural-language suitability of their progeny and putting together an entire platform, with more apparent effort than they have dedicated to human UI/UX considerations since sometime in win7(excluding dark pattern R&D) to aid you in discovering your sins against bot comprehensibility and fixing them.

You'd have to either discipline or expel cheaters. You can't discipline cheaters because then their mommy and daddy will stop giving money to the endowment. You can't expel cheaters because the school will lose the tuition revenue on top of that.

There is no financial justification whatsoever for solving the cheating problem.

This anti-AI bullshit has got to stop. If an AI finds a real bug in your program, sing hallelujah and move on with life. Computers will always be able to execute algorithms faster than humans, and with greater depth and accuracy. That's the whole point of their existence - to do stuff that is too complex for humans to do, and to do it quickly.

Bolsonaro: "We cheated fair and square and didn't win, so we're going to sue."

It's the same playbook Trump is going to use to try to overturn the midterm results because "we couldn't possibly have lost because we rigged the election with gerrymandered election maps!"

You'll see. Just wait.

I'm not really qualified to deliver a good holy war; but it does seem like there may be something to the criticism that monolithic integration has gone a bit far if supporting one utility being written in a different language is a special feature rather than a matter of the rest of the system not knowing or caring what is on the opposite side of an interface so long as it can act as expected.

You can't really beat the fundamental economics of software development: expensive to do right but cheap to copy means that you really, really, want to share a problem with as many other people as possible(unless your whole business is being uniquely good at solving whatever the problem is; but that typically isn't the case for this sort of software). Applies to both proprietary and FOSS: relatively mass-market software is often pretty cheap for what you get; really oddball niche stuff is frequently both pricey and terrible; while your life is going to get steadily more miserable if you are personally responsible for handling backports and fixes for some internal fork of a long-EOL version of an OSS package.

The big difference, at least potentially, is that, while it tends not to be economic to DIY, licenses that give you the right to DIY also give you the right to pay someone else to do it for you; or to form a coalition of people with similar problems and have everyone pitch in to pay someone to do it for you. You still need to either eat the cost of maintaining an internal fork or putting together some sort of coalition of people with similar problems to be the openJDK 8 forever pals and share the cost of maintenance; but the vendor can't just stop selling you licenses if they want you to move to their cloud offering or whatnot.

Random intermediate CA. They got a couple of commonly used root CAs to sign for them; and everything just works from there.

That's the problem. It's relatively easy to fire a certificate issuer; but it can get surprisingly fiddly surprisingly fast to ensure that all your stuff actually distrusts one(unless you are responsible for basically nothing but a a handful of in-support major browsers and are OK with the choices their vendors make, in which case it will be handled for you relatively quickly; and was in this case). Basically any network connected widget is going to have at least one trusted root store embedded in it somewhere, possibly not updated anymore; and a number of software packages either bring their own or only partially track the OS-provided one.

You also have very little control over what other people do; both what CAs they chose to get certs from and what...questionable...partnership decisions the root CAs you do chose to trust. It's not technically secret; but unless you are practically a full-time PKI nerd you probably didn't know until after the fact that Comodo, now Sectigo, had quietly trusted eMudhra for you.

I fully admit that this might be a 'me' problem, not a them problem; but I just don't understand why this agent monitoring setup was so vulnerable and is being treated as so novel.

Sure, the monitoring of whatever goes on inside the LLM is comparatively new and exotic; but when you set it loose on the internet it's going out through one or more of your WAN links, presumably with your router and firewall and so on in the way, and is mostly doing HTTP(s) stuff. Keeping an eye on what an internal host is doing when you can insert whatever trusted roots you want for TLS MiTM and you 100% own the pipe that it is using to communicate is not necessarily a desperately enjoyable task; but it would have been a relatively banal requirement a quarter century ago.

I'd also think that, when you are spending $$$$$ on the exercise in Nvidia compute gear, and it's a test of a 'frontier model' whose behavior and capabilities you are trying to better characterize and refine, allocating the handful of terabytes necessary to just store a full packet capture of the session in case it is relevant would be a no-brainer item.

Is there something I'm missing that makes this case more complex? I'm not talking about the 'grubbing around in the LLM's vectors and such' side; just the "a host is doing HTTP stuff through a WAN link we control, can we observe what it is doing?" aspect.