Nextgrid

I am not a lawyer, I am just "making up" what exculpatory evidence I would prefer to have on my side when potentially confronted with a charge of destruction of evidence after pulling a stunt like this.

Until very recently, creating arbitrary USB/PCIe devices has been out of reach of hobbyists, as a result the device drivers (running with kernel privileges and written in memory-unsafe languages) generally have no hardening against a malicious device. You wouldn't need this exploit to get root (for that matter, this exploit _already_ requires root).

Presumably you must disclose that "doing that" would wipe the device... and you better hope this is caught on some neutral party's camera so there is a record of you saying that.

Nobody _wants_ it, but in practice if all cars/TVs/smartphones break every two weeks, what choice do people have?

In tech, the era of competing based on quality is long gone. The winning strategy is to get a monopoly/oligopoly and then you can let the quality decay to zero and people will have no choice but to keep paying you money (or to your handful of equally-mediocre competitors).

> I continue to produce work better, faster and more reliably than my colleagues who have outsourced their brains to Claude.

It matters little if your employer does not recognize/value that? Given the quality of most software nowadays, the output of Claude driven by a monkey appears to be perfectly acceptable for a lot of companies.

(yes, there's likely a big reckoning coming where all the slop and tech debt suddenly catches up with them, but that could be a decade off and you still need to pay rent in the meantime)

Nobody is wasting nation-state exploits to launder stolen phones.

> Are these outages caused by introduced bugs, though, or by load issues?

Probably both. But it still throws a thorn into the theory that LLMs are about to replace software engineers any day now.

You'd think they could LLM-code their way out of this situation easily if LLMs were the software engineer replacement they are being marketed as.

Hard disagree.

Self-hosting a service like GitHub that operates at GitHub scale is difficult.

Self-hosting a service like GitHub that operates at the typical small/medium company's scale is trivial.

A single machine (with separate runners for CI) will cover many companies' needs. It being a single machine eliminates a lot of the complexity and failure modes associated with a distributed system and makes backups/restores/maintenance easy.

I am talking more about the knowledge of the code rather than an objective/subjective measure of code "quality".

Code might be bad by some objective/subjective measure, but if you (or the author) can understand, navigate and work on it, that's often better than good quality code that nobody understands because it was written by an agent, especially under the time pressure of an ongoing incident where you need to fix it now.

Even if the good code is easy to understand, you still need to read it and take it in, something you don't need to do because you got it implicitly by writing said code.

> to know that you're not going to remember it in the long term

From my personal experience, while I will not remember code character by character, a quick look is all it takes to refresh my memory and get the general gist of it and what the context was at the time, something I don't have if I'm reading someone else's (or an agent's) code.

But for their target market, corporate office drones writing crap that nobody will ever read more than once (if even that), this is actually perfect and makes AI usage numbers go up. "Make longer" is amazing for someone who just wants to pretend they put more effort than they actually did.

(of course, everyone else can do that too, and the length/literacy of prose is no longer a good proxy for effort. In nature, "honest signalling" only works if the signal is costly. Removing the cost from the signal makes the signal worthless)

Companies that have something worth protecting already don't use it and/or pay for the on-prem version.

The rest don't have anything worth stealing anyway.

I'm not talking about code quality (though indeed that could be a problem too), I'm talking about understanding the code - having written the code by hand means you don't need to rediscover it from scratch.

(with human-written code I can reach out to the person who wrote it and let them deal with it, and they will have the understanding of said code, even if it is bad by quality measures. With LLMs there is nobody who understands said code, regardless of its quality)

This is also missing step 6: when your solution breaks in production or needs to be extended.

Having done step 2 & 3 by hand is the difference between being able to fix/extend it quickly with no further damage or fumbling around like an idiot and sometimes breaking more stuff in the process.

Some people are just looking to be offended. You don’t have to read or agree with his drivel to use his software.

(Do you also check out the blogs/social media of every dev involved in every library you use?)

Wouldn’t that be the job of the software TCB to ensure only the appropriate user is given access (and prevent the user from accessing the TPM directly obviously)?

The TPM validates the state of the software TCB, and the software TCB validates the state of the lower layer, and so on.

Is there anything they're doing that can't be replicated by hypervisor/management software on commodity x86 servers? Seems like their "secret sauce" is a software stack that "just works" more than any actual special feature of the hardware.

I feel like Broadcom with its VMWare acquisition could easily take these guys out if they wanted to (or for that matter, any OEM that has a line of servers + network & storage hardware). They don't, most likely because there isn't actually enough profit to be made there (Oxide having to raise money multiple times might be a hint).

I wonder what's the selling point at that scale. If your ~monthly~ cloud spend ends in "M", you can easily justify hiring the talent needed to wrangle conventional bare-metal (in fact you can do so at much lower spends, but at these spends it becomes a rounding error).

Edit: my bad, read that as monthly instead of yearly. Still, a yearly spend of millions would still make sense to bring that in-house.

If you somehow manage to get on top of the elevator cab (indeed as the sibling comment points out, there is no escape hatch at the top), you will generally see a small control panel with a switch to put it in inspection mode. That turns off autonomous control and from there the cab will stay where it is unless you manually action the up/down switches (assuming the "safety chain" isn't broken - which if the elevator suddenly stops, it may be - so even those won't do anything then).

Dealing with SaaS doesn't just mean accounting for the subscription cost of the software. There's also the fact that said software can change its terms, pricing or functionality at any time (or disappear entirely) - often a time most inconvenient for your business.

In contrast, your own solution can be built and maintained at your own schedule and the only changes will be those you decide.

MySQL has a lot of broken "features" that sadly some existing legacy code might be relying upon and there just isn't engineering capacity required to move to a saner DB, so they have to make do.

I had a legacy project on MySQL that turned out to only "work" because string lookups were case-insensitive in that particular version or our configuration. Moving to Postgres and its correct behavior suddenly exposed a lot of bugs we needed to fix before we could complete the migration.

Considering a lot (all?) of AI is currently being sold at a loss, I wonder if all that outpouring of interest is exactly the reason why they're changing course, as it would've otherwise been too expensive to offer.

It could've also just not been ready for prime time and couldn't actually live up to its promises, so they decided that shelving it was less of a reputational impact than releasing a defective product.

He is probably referring to Beta 1.6.x. I remember running 1.7.3 in 2011-2012 on a potentially 1 or 2GB RAM machine and some Nvidia 7xxx series card (7600?). It worked fine on Linux.

I suspect most of the "corruption" RPi users experience is likely bad power (shitty undersized USB power bricks) glitching the CPU and causing the filesystem to corrupt. The SD card is likely doing exactly as it's being told by the host system - write (invalid) data to blocks, which it does.

Downvoted - this is false, sorry. The whole point of security keys (whether exposed via PKCS#11, or FIDO) is that the private key material never leaves the security key and instead the cryptographic operations are delegated to the key, just like a commercial HSM.

Technically, a private key that was imported (and is marked as exportable) to a PKCS#11 device can subsequently be re-exported (but even then, during normal operation the device itself handles the crypto), but a key generated on-device and marked as non-exportable guarantees the private key never leaves the physical device.

The idea with HSM-backed keys is that even in case of compromise, you can clean up without having to rotate the keys. It also makes auditing easier as you can ensure that if your machine was powered down or offline then you are guaranteed the keys weren't used during that timeframe.

> not pull a sidearm and shoot the corrupt commander

Wouldn't you just get "zeroed" by the upstream commander or court-martialed and sentenced to a gulag?

I don't mind the increase per-se, but the "improvements" they advertise to justify it are laughable. Not to mention that 1Password 8 has been a major downgrade across the board.

In my opinion, if something isn’t actually an error, you modify your logging to not log it as an error. Your error logging/alerting pipeline should always stay clean.

If something shows up in there, you should only have 2 options: 1) it’s an actual error and you fix it and make sure it never happens again, or 2) it’s not an error and then you fix it by adjusting the log level to make sure it isn’t one.

If someone suggests an “error budget” on my watch they get the door. You can have a warning budget (and the resources to adjust the log levels or remediation protocols to fix said “errors”) but actual errors should remain errors - otherwise they’re delivering broken software and that’s not what I’m paying them for.

Of course, companies who have the common sense to do this already do it and nobody in their right mind would suggest an “error budget”, but for those that don’t they have a serious problem that needs to be rectified.

The danger otherwise is that you’re making your observability pipeline useless if “errors” no longer actually mean errors. That’s really bad because now it opens the door to actual errors being ignored until it’s too late and then remediation is more costly.

Trial and error?

Just like it does when given an existing GPL’d source and dealing with its hallucinations, the agent could be operated on a black box (or a binary Windows driver and a disassembly)?

The GPL code helped here but as long as the agent can run in a loop and test its work against a piece of hardware, I don’t see why it couldn’t do the same without any code given enough time?

Your ISP will cut your account when you saturate the upstream pipe 24/7 for weeks on end... which will only happen if you host video.

And your home insurance will not know/care if you're operating a desktop-sized computer or even a single server (it is perfectly fine and expected a developer might bring an actual server home for troubleshooting). Home insurance only cares if you're running dozens of them.