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).
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.
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.
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.
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.