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.
No, the team mislead people by claiming the rewrite was experimental only to merge 1M lines of unreviewed code merely days later. Responsible software developers don't operate on blind trust, and both the Bun code and the maintainers are highly unpredictable at this point. That's more than sufficient technical grounds to drop an optional and replaceable dependency, especially since there are no user-facing consequences beyond the bruised egos of a cult following that demands blind loyalty to its tech‑bro leaders.
Who did they mislead? A few days later it was no longer experimental and it became the main dev branch as they decided it would be the way forward for development (see the blog post on why). No stable release has been declared yet.
Here was the Bun team's message on merge:
> It passes Bun's pre-existing test suite on all platforms (and fixes several memory leaks and flaky tests), the binary size shrinks by 3 MB - 8 MB, the benchmarks are between neutral and faster - and most importantly, we now have compiler-assisted tools for catching & preventing memory bugs, which have costed the team an enormous amount of development & debugging time over the years.
>
> The codebase is otherwise largely the same. The same architecture, the same data structures. Bun still uses few 3rd party libraries. No async rust.
"Who did they mislead? They just changed their minds a few days later and words aren't what you think they mean. Here's the team's PR statement containing assertions about the 1M lines of code they never reviewed."
It's unfortunate that this is what some call "engineering" while labeling actual science and engineering as "politics."
yt-dlp is under no obligation to keep using a dependency from vendors that instantly flip flop and re-frame their own words and actions. That's what actual due diligence and responsible engineering looks like.
Feel free to point out where my logic is wrong. It sounds like you think they've made a stable release already? None of the new code is sent to users yet. It's a direct translation without relying on major AI decisions. I'm happy to call them cowboys if they make a release with lousy testing.
> It sounds like you think they've made a stable release already?
What's the point if you keep refusing to acknowledge the issue and tossing out theories about how I and others might be wrong, just to see what sticks?
> None of the new code is sent to users yet.
So? The decision to adopt was already made and the code was merged without planning, without considering downstream impacts, and without proper inspection. People who won't read their own code before merging won't read it after. But many of you don't even see this as an issue. So again, what's the point in trying to point all of this out?
Also you yourself said the experiment is over. You can't have it both ways.
> It's a direct translation without relying on major AI decisions.
Because the genie said so? That sounds lacking in scientific rigor, but
> I'm happy to call them cowboys if they make a release with lousy testing.
Oh right, that the test passes is proof that the new code is debuggable, maintainable, architecturally sound, semantically equivalent to the old code, and non-disruptive for downstream users. Apparently testing has leapt centuries ahead in the past two weeks or so.
Testing is a broader term covering multiple things, up to and including the decision of when you have enough confidence in the system to declare it stable. The test pass rate was an early bar for merging into dev, not release.
The translation did not change the architecture: it was a 1:1 translation with even the same internal data structures. Rust written in a zig-like way, with the original Zig still available as reference. AI can make an absolute mess when making architectural decisions, but translation like this plays to the strength of current AI, especially when moving to a stricter language.
The code being in the dev branch means that they now are open to community feedback and testing, and no date is set on it being declared stable. We'll see how the team handles it.
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.
Yeah its a bugbear of mine "oh its so accurate" theres like 2 accurate scenes, and most of it (from economics/agriculture to space physics) is completely bonkers.
Sadly its a lot of "Filmbros first serious scifi movie" and thats something you cant disentangle, its love its not rational.
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.
I have a car, actually I have briefly visited Mount Annan for lunch, but I should go back and spend some time there. Thanks for the other recommendations!
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.
To be specific, a linear solver can be (as in I have done) written in a week.
A serious non-linear solver that handles legacy Spice models is another beast entirely. And if you want to integrate modern advances in algebraic-differential systems you take that to a higher level.
These are not partial differential equations such as you find in Navier-Stokes. These are sparse non-linear differential equations that do not parallelize nearly as simply.
Another example of related problems that parallelize poorly even though they are linear are the FDTD formulations for Maxwell's equations. These are relatively simple systems, but the bottleneck is almost always the memory bandwidth because it is so hard to parallelize.
The type of people who need spice is dead serious about accuracy. 1ppm error sometimes is not tolerable. So, an optimization in a game engine is definitely not suitable for engineering simulation.
Dude these are incredibly oversimplified models of real components. How are you getting 1ppm when basic shit like tempco and self heating are missing from pretty much every vendor provided spice model?
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.
> Note that for Linux kernel vulnerabilities, unless the reporter chooses
> to bring it to the linux-distros ML, there is no heads-up to
> distributions.
so, no, `linux-distros` list don't solve the problem.
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.
As someone who prefers BSD I would make it my goal to become something reasonably popular on linux that isn't different just to force less reliance of the GNUisms in their core utils. Nothing wrong with the GNUisms on the command line, but there are are a lot of GNU assumptions in scripts that should be portable.
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.
doas and sudo-rs occupy different niches, specifically doas aims for extreme minimalism and deliberately sacrifices even more compatibility than sudo-rs, which represents a middle ground.
reply