aragilar

Of what, IEEE-754? Given how poorly most languages implement it (and how many shortcuts are taken in the same of speed), I'm not sure IEEE-754 is the problem.

You don't need NaN (or Inf) to have unexpected behaviour with floats and naive loops in lua, using 1e52 is enough. Conflating floating point and integers (independent of encoding) is always a bit of a trap.

There's too much available power then (curtailment/negative prices are fairly common now on sunny days), and not enough during the evenings, so it's an incentive for those who don't have/can't get batteries (e.g. renters) to shift their habits. It also can be spun as a cost-of-living action.

ssh -X works fine depending on the toolkit you use (i.e. not Gtk, because of its rendering pipeline) and the distance/latency you travel. For distance/latency, at some point (i.e. at sufficient latency) you're going to need to think about you present this to users (this is true independent of the medium, there are hard physical limits that cannot be waved away), and so for any tool that promises remote graphical access will need to design with distance/latency in mind (e.g. vim works great over latencies as you basically queue up instructions).

In my experience, anywhere using an app/QR code is better served by me walking up to the counter and ordering.

Personally, I think AC vs. no AC isn't the issue, it's the lack of fans and air circulation that is the problem. I suspect there are building where installing AC is going to be required, but the majority of building really just need to install fans.

I hate writing, but I don't send LLM output, because I'm not the asshole who sends junk.

It's "we support 4 JS backends, we don't have the capacity to support 5 currently". They're not dropping bun entirely, instead bumping the minimum bun version and not supporting "bunv2" because they don't want to be beta testers.

But unless you're doing that for every service you use (and not just the ones that annoy you), that's still the same logic. Deciding to count something is just as "political" (as you put it) as choosing to not count something.

I would argue the current defaults for uv are the correct ones. Unless you have actually verified that said library follows semvar, and you know the library will break your code in the next major release, you should never use upper bounds. You should be using CI to manage updates of lock files (e.g. dependabot, renovate), and not blindly updating lock files. Similarly, you should care about your dependency tree, and not just direct dependencies. I feel the author thinks Python behaves the same way as the npm ecosystem, and thinks the same lessons apply.

And yet the rest of the movie runs on movie logic, enough so that every physicist I know rolls their eyes at it. It gives me the vibe of the "IFLS" crowd, not anyone who actually understands science.

I also live in Sydney, and the first question to ask is always "do you have a car?" (and then "how long you here for?")? A car makes it much easier to visit various spots (e.g. the national parks, Mount Annan (https://maps.app.goo.gl/WJRcJY8RHtRLV7Tm9) IMHO is a better botanic garden than Royal (the one in the city) because it focuses on native plants, Blue Mountains/Hawkesbury, the various zoos which are further out), whereas if you don't have a car the city has enough things close by to do. Powerhouse is great (the real one, not the one which is going to flood), Australia museum is great, if you can go on a ghost tour for the Rocks and the QStation. There's lots of other minor museums throughout the city, esp. the Rocks.

Which differential equations are you talking about? Linear ones have standard solutions and are definitely parallelisable (though you can basically just write the solution down by hand). Non-linear ones vary from can basically be approximated by a linear solution with corrections to needing to use relaxation methods (which are obviously not parallelisable).

Mechanics is generally linear, and for game physics engines fast is more valuable than correct (fast inverse square root being the obvious poster child). Add viscosity and you're in for a bad time.

Uh, there is a list, named "linux-distros", which is for this purpose (and I think it's for more than just Linux, e.g. I believe it was used for the xz vuln).

Given this was announced when backports weren't ready (and given the POC was at least opaque if not obfuscated), I'm getting the vibe fixing the vuln wasn't as high as a priority as making a media splash.

But if you seek to replace coreutils (as at least is the case with Canonical it seems), rather than just be another POSIX userland implementation (e.g. busybox), then I would suggest you do need to be bug-compatible? I can apt/dnf/apk install busybox and use that for my user rather than coreutils, but given a significant amount of Linux infrastructure (including likely many personal scripts) are tied to coreutils, the bar is much higher. Given the numerous issues with quality Canonical has had, not just with Ubuntu but their other "commercial" tooling, I'm not sure any rewrite/port, written in rust or otherwise, with Canonical developing, managing, or even being associated with the project can meet the requisite bar.

But are the current uutils developers the same as the 2013 developers? At least based on GitHub's graphs, that's not the case (it looks fairly bimodal to me), and so it wouldn't be unreasonable to treat the 2013-era project differently to the 2020-era project. So judging the 2020-era project for its current and ongoing failures does not seem unreasonable.

Similarly, sudo-rs dropping "legacy" features leaves a bad taste in my mind, there are multiple privilege escalation tools that exist (doas being the first that comes to mind), and doing something better and not claiming "sudo" (and rather providing a compat mode ala podman for docker) would to me seem a better long term path than causing more breakage (and as shown by uutils, breakage on "core" utils can very easily lead to security issue).

I personally find uutils lack of care to be concerning because I've been writing (as a very low priority side project) a network utility in rust, and while it not aiming to be a drop in rewrite for anything, I would much rather not attract the same drama.

According to https://stats.labs.apnic.net/dnssec DNSSEC is sitting about 1/3, so "very few" isn't accurate. I'm not suggesting browsers should change what they do, but if WebPKI can't be used, building a new CA ecosystem would seem to be to be at least as hard as getting DANE working.

If you look at the older article linked (https://www.potaroo.net/ispcol/2022-03/revocation.html), it's very similar and uses the same tick/cross, so I don't think it's AI generated.

In addition to what other commenters have said, it's a copy of a post on their personal blog: https://www.potaroo.net/ispcol/2026-04/revocation.html

On revocation, check out https://bugzilla.mozilla.org/buglist.cgi?product=CA%20Progra... I don't think any CA hasn't had an issue with revocation at some point (e.g. Let's Encrypt had a major one in 2021, and refused to revoke), which is why Let's Encrypt is moving to 7 day certs (so that revocation isn't required, basically https://www.imperialviolet.org/2011/03/18/revocation.html which is mentioned in the article). My impression is CRLs (and by implication current revocation methods) don't work, and browsers are effectively fudging around CAs with custom methods (e.g. allowing existing certs but no new certs from distrusted CAs).

I'm no security expert, but modern bind9 seems to just handle DNSSEC with no issues when I've used it, and given that the "WebPKI" seems is becoming more and more reliant on custom browser code, adopting DANE outside browsers might not be the worst idea.

My impression was that autoupdate was not the default because the devices it runs on only have so many resources, and there's a non-trivial chance of bricking the device (given how many devices are supported)? It's not like other vendors are doing any better in this space (and I've seen enough things in the "IoT/embedded" space brick themselves with updates to be a bit wary of autoupdates).

Have you used busybox? The BSDs? I'm not sure adding more features to coreutils is a major help, and given rust-coreutils/uutils has:

1) more CVEs between two latest Ubuntu releases than coreutils has had over the last 30+ year

2) managed to break security updates

3) is neither fully compatible with POSIX nor coreutils

I'm not sure why I'd ever use it? Sadly, projects like uutils have made me suspicious of rust projects, so unless I know that the project is well maintained (for which there are numerous examples, ripgrep being the obvious example, but newsboat, the various tools from proxmox, servo/firefox, and the pgrx ecosystem are ones I use regularly), it's a negative marker against that project.

I believe https://portier.github.io/ was the replacement for Personas/BrowserID, any reason not to use it?

Then why rewrite coreutils in rust? TOCTOU isn't exact some new concept. Neither are https://owasp.org/Top10/2025/ (most of which a good web framework will prevent or migrate), and switching to rust (which as far as I know) won't bring you a safer web framework like django or rails.

Seamonkey exists.

They're referencing https://en.wikipedia.org/wiki/Up_to_eleven (and you're one of today's lucky 10000: https://xkcd.com/1053/).

I would suggest the current system fails to efficiently choose (as you have to align multiple pathways, like updates, "manual" installs, adding new packages), and so effectively there's only the illusion of choice. Switching instead to a queue not only means that there's time for QA/security scans, but it's much easier to make the choice to speed up than slow down.

Because that's what they're seeing? If only a small fraction of submissions can use the tool correctly, that's on the tool.

But you know beforehand how much you need. We can measure and make predictions with accuracy.

I think based on what I think is the author's comments here "Flatpak on top of immutable distros are the future of Linux"? Given that context, I can see how the author produced the text.

As an aussie, I'd say instant is never good, it's the minimum acceptable coffee. If your coffee is worst than instant (yes, you LAX, how do you make coffee taste like literal dirt water!), then you should learn to make coffee properly!