csande17

Is this the new normal, or just, uh, normal?

Big embarrassing network-exploitable bugs in major open-source projects happen sometimes, and network-scanning attack botnets have been around forever. Small shady CAs mess things up sometimes. People upload malware to PyPI and NPM all the time, and "move fast and break things" software-deployment startups get breached all the time, to the point where it doesn't even really feel like news to me when those things happen again.

It's unfortunate that a few of those events all happened at around the same time. But, like, even if that's not a coincidence and these events are actually happening more frequently, you should have been preparing for them anyway!

Traditionally, the Gentoo package manager didn't actually compile the Linux kernel at all. Instead it just extracted the source code to a folder on your hard drive and you were supposed to go configure, build, and install it yourself. Gentoo Wiki pages would list out the options you had to go set in the `make menuconfig` menu to get specific software to work.

These days there is a package that builds the kernel for you, but it relies on the "savedconfig" system to just save/load the entire kernel config file instead of using USE flags. So you still have to root around in the config menu yourself to change things.

In my experience Linux is very good at correctly declaring dependencies between options, and still working with options disabled, so this isn't as much of a problem as it seems to be for Chromium.

The main reason to use libraries like this is because you can't put media queries or pseudoclasses like :hover inline in a style="" attribute.

(I mean, this particular library seems to be one of those AI-generated ghost town projects that has stuff like a big fancy GOVERNANCE.md but no actual user or contributor community, but that's the strongest reason I've heard to use things like Tailwind.)

Sure, but in Rust's case the social understanding is "there exists some type system that guarantees perfect memory safety, and has the general aesthetic features associated with rustc's type system, and 'Rust' is defined to be whatever that type system ends up being".

This is a nice ideal, but it doesn't actually exist in concrete terms as a design. It can never have flaws because the definition of it is just "rustc without all the flaws".

The true specification was inside our hearts all along!

I'm not an expert on the Java specification, but my understanding is that Java as a language is well-defined enough that we can say things like "Java's type system is unsound", independently from any specific implementation of Java.

You can't do that with Rust because "Rust's type system" is literally just the vague concept of "a type system that is safe". The implementation of this ideal in rustc can have flaws, but Rust itself cannot, because Rust itself has no flaws by definition.

Yes. When people describe Rust as "a memory-safe programming language" they are describing an aspirational vision, and not a programming language that has actually been designed with sufficient rigor to guarantee memory safety. Any failure of rustc to actually guarantee this is just a bug in rustc itself, a failure to properly implement the Rust spec, because the closest thing Rust has to a spec is literally just the vague ideal that the compiler should guarantee safety somehow.

Rust cannot fail, it can only be failed.

If that's the definition you're using, then C is also a safe programming language. In fact, C is even safer, because it actually does have a specification that lists all the invariants that the programmer has to uphold themselves because the compiler doesn't check them.

Simple: when data is added to S3, immediately bill the full cost of storing that data until the end of the month (or fail the upload request if there's not enough quota left). If the data is deleted before the end of the month, refund the remaining storage time.

To prevent cases where users can upload an excessive amount of data on March 31 that they then can't afford the April bill for, AWS should also maintain a "next month's balance" limit that gets handled in the same way.

It would take a bit more work to correctly handle things like ephemeral data and tiered storage classes, but it's not insurmountable.

You could apply the same kind of billing to most other long-lived resources, including VMs that run business-critical services.

In the old versions of Alexa and Google Assistant (before LLMs), you could memorize a couple of voice commands that they'd reliably recognize to do a really basic task. If you need an oven timer but you've got meat juice on your hands, you yell, "Alexa, set a 30-minute timer!" If you want to turn your bedroom lights on without fumbling in the dark, you yell, "Hey Google, turn on my lights!". That was, like, the main thing they were sold for.

But then Google changed the default voice assistant on Android to use Gemini. So instead of relying on hard-coded "if the user says this exact phrase, do the thing we said would happen" conditions, people now have to hope the model's smart enough to figure what "turn on my lights" means from first principles every single time.

I think GP was talking about backup apps that run on the iPhone/iPad itself.

It's still possible to back up an iPhone to a jailbroken computer, using roughly the same iTunes sync system that was available on iPods. For now.

He sees the value of using LLMs... only after performing NASA-level verification and fully comprehensive fuzzing using traditional tools. Since Zig has not done those things, LLM-generated bugs are still banned.