Live data from Hacker News

Ubuntu 26.10 completes transition to Rust-based coreutils

omgubuntu.co.uk

321–330 of 341 posts

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#321

Beware that rust coreutils on 26.04 currently has really bad performance with larger block sizes. Ganeti uses "dd bs=1M" as part of a disc image transfer pipeline, and with 26.04 performance dropped from ~350MB/sec to 30MB/sec, with the dd command CPU-bounded. The issue seems to be that it is operating on partial buffers and then having to copy remainder of that 1M buffer around as part is consumed. Coreutils 0.11 so…

Why are we still using dd? Seriously, it's a weird obtuse command. Weird syntax that doesn't match anything else, and the block size shouldn't be needed 99% of the time. A modern tool should figure out a good value on its own, either by interrogating the devices at both ends, or by benchmarking, or both.

The 'wierd syntax' has finally been getopt-ified. On the C GNU coreutils 'dd', and in a couple of the BSDs 'dd's.

* https://jdebp.uk/Softwares/dd-with-getopt.html

It only took 52 years. My prediction stands, by the way. (-:

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#322
post #126

Earlier quoted context omitted.

They need to kill snap ...

I think ubuntu wants to kill desktop linux. No other explaination of why they push firefox inside snap, which then proceeds to constantly crash, when firefox used normally works completely fine. I haven't tried chromium but I presume it's the same issue. At work I'm forced to use ubuntu and I placed snapd on hold and added mozilla's own apt repository to my configuration to get firefox. At least in the past few month…

Thanks to snap I've learned of Librewolf. Couldn't install non snap Firefox, so just got ff fork instead.

Also, after a system update all PPAs (including Librewolf) got turned off, so I went like a year without updating the browser. Fun stuff.

Also, snap is now partially fixed. It used to take all your drive space with old versions of snaps. You needed a special script to remove them automatically.

Now there's no more than 2(?) old versions of snaps anytime. Progress!

But not to complain too much, Ubuntu still kind of works. I moved my laptop to Fedora, and almost did it with the desktop, but learned of Librewolf. Should probably remove the fedora root and home at some point. Don't remember any issues that were not caused by me (other than snaps). Compared to Windows with it's auto updates when you need PC for sth critical, ads everywhere and this annoying way of installing software not from terminal and having to update it manually separate from system updates. Ubuntu did a lot for Linux, maybe more it's community than canonical, but it will always have a place in my heart.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#323
post #320

Earlier quoted context omitted.

How can a command which was explicitly designed to do nothing but read and write disk become CPU bound?

That's is famously not what 'dd' was designed to do. Its description in the original Unix 6th Edition manual was 'convert and copy a file'. It's infamous for people mis-remembering it as a disc copier when it was actually a file transcoding utility that understood EBCDIC and could re-block things.

I think we are saying the same thing. By disk, i meant disk I/O which is the main practical purpose of the tool. Of course, Linux being Unix, a raw disk is a file, so is /dev/null.

Of course a file can be everything, which is a kind of the point of Linux. But that doesn't change the fact that 'dd' is for disk (or file) I/O. Also please don't argue semantics, it leads nowhere.

But that's not the main point. The main point is the Rust coreutils version of dd is slow. I highly doubt it's impossible to write an implementation in Rust that's as fast as the C one. But the Rust community needs to invest time and energy into finding why that's the case and fixing it. Until that happens the broader Linux community is right to push back on adopting it.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#325
post #68

Earlier quoted context omitted.

OIC. Rust doesn't guarantee optimizing tail recursion. How unfortunate for a language that's getting widespread adoption.

I don't think that's related? The bug alluded to looks something like function rm(node) { for (const child of ls(node)) rm(child); unlink(node); } and no amount of tail call optimization will save you here, because this isn't tail recursion. Of course you could rewrite it using an explicit stack + tail recursion, but then you might as well be using a while loop.

So it's enumerating all the subdirectories first and unlinks the tree afterwards?

I get that this isn't transactional and inherently prone to race conditions, but if this is indeed the problem, it's rediculous. A single while loop could do the job correctly and use less RAM. It'd probably also be faster. But that wouldn't be a rusty thing to do?

I look at code from the heirloom project and, despite its warts, I think we've lost something in the past 45 years or so.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#326
post #153

Earlier quoted context omitted.

Canonical has been pushing its own agenda for ages, how many examples do you need? Microsoft making Rust tier 1 is great, it means probably one day we get a VS proper support instead of VSCode only. If you head off to Microsoft official blogs, you will find out that Microsoft already has tier 1 support for Java (ironically), Python and Go, besides the usual .NET languages and C++.

Why does 'Ubuntu defaultism' still exist in the Linux world? Them replacing packages with shitty unworkable broken snap substitutes that can break the system when updating, and have a habit of reinstalling themselves...

Because of The Year of Linux Desktop and being the favoured distro among OEMs for their hardware.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#327
post #239

Earlier quoted context omitted.

but it segfaulted in a memory safe way.

sarcasm detected here :D

I don't think this is a sarcasm, as a long standing Rust user myself, I don't think the community should preach out by "memory safety" -- rather the structural change in coding mindset and new ideas such as ADT and generic programming, while retaining mostly zero-cost like C++ without the bearing of C++ complexity (that includes a compiler that spits out 300 lines of compiler error just because I missed one Memory safety is just what Rust inherited from C++ smart pointers with a stronger linear/affine type system twist, especially regarding move semantics, cloning and borrowing rules. What makes it powerful is the various language features it also incorporated from Cilk/C#/OCaml/Haskell.

Right now Rust and Zig is my two favourite middle ground. It is sad that Zig went completely sod-off-to-LLM mode but the most devastating aspect of Zig is that it is way too Linux focused. A lot of the code in Zig I cannot compile on Windows, plus the major changes to IO interface and the colorless function fiasco is really making me question the stability of Zig.

This recent event led me to displace Zig and replaced it with Nim, which emits C code instead and having a really powerful algebraic language system, while getting some benefits of Rust such as scoped smart pointer (I think they call it ORC), or using simple mark and sweep arena collector or even full-blown Boehm GC.

Right now I'm trying to create a distribution of Nim in a single binary (with musl and mingw packed together) and using tcc as the backend, all in a single binary with Rust and an internal project to convert wasm 3.0 and wasi proposal 1 modules into Rust code, which the Nim compiler and TCC are both compiled to WASIp1 first, then term-rewritten/transpiled to Rust (think w2c2 or wasm2c, but targets Rust, I found some nice structuralism of Rust and wasm lately)

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#329

So what is the way forward for Linux to have sandboxi g as strong as Android? Appimage everything? I know it's possible now hacking together things, but I mean by default and integrated.

Do you mean flatpak ? (Or directly using bubblewrap, the actual sandbox ?).

Appimages are not sandboxed

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#330

So what is the way forward for Linux to have sandboxi g as strong as Android? Appimage everything? I know it's possible now hacking together things, but I mean by default and integrated.

Amutable. Building an immutable and image based system which even the installer can't modify, a-la macOS. One systemd patch at a time.

Immutable OSs are great, I'm running a custom image based on Bazzite for a couple of years now.

But that doesn't solve the user sandboxing problem, flatpaks and xdg portals does.

Still, a lot of portals are still missing or not fully implemented, but it's getting there !

Post reply on HN