aragilar

I think it's not clear from the article why they left (e.g. could be anything from retirement to going to work at another firm/contracting to being fired to switching careers), and likely it's going to be a mix, plus not all were previous Ford employees. Similarly the "AI" isn't clearly defined (but like you I would be surprised if it were LLMs). I suspect though why the article exists (and a possible source of your downvotes) is signalling against "AI", which if Ford wants more expert employees (given their issues), is something Ford wants to present.

The answer is fairly obvious, Typst (like ConTeXt) is not LaTeX. Typst is a perfectly fine solution if you're giving the typeset output (i.e. a PDF) to someone, it not a solution if you need to give the document source to someone (if the person expects LaTeX, or .doc(x), or some other format). Many of the issues people raise with LaTeX are due to needing to pass on the document source to someone (otherwise you could use whatever packages or engines you wanted), but that is fundamental to interoperability and why LaTeX (and Markdown) stick around.

I would say the complexity of IEEE-754 is warranted (given the history of the standard), but the issue is those writing languages are typically not aware of numerical computing (it's rarely a course at university), and so do not design their languages with it in mind (or predate IEEE-754). This leads to implementations and ecosystems which do not consider it, and we end up with systems where giving the required control to implement IEEE-754 conflict with other requirements (e.g. security, imagine if you could control rounding mode via the browser).

Specifically, 0/0 (or inf/inf), not any division by 0.

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.