Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ubuntu 26.10 completes transition to Rust-based coreutils

omgubuntu.co.uk

Post reply on HN
Print view View original

331–340 of 341 posts

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#331

Post by bayindirh »

LelouBil wrote: post #330
bayindirh wrote: post #138

Earlier quoted context omitted.

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 !

At the end of the day, a sandbox is a slice/cgroup. i.e.: Kernel's ability to create a complete bubble around a process or set of processes.

My beef is not with immutable OSes or sandboxes or else. They all have use cases and reasons.

My primary beef is being locked out of my own system without my consent. I want to own my personal (esp. Linux) systems, that's all. I'm also against erosion of Free Software ecosystem for something looking open, yet non-buildable or modifiable by the end user. This is why I don't like permissive licenses and essential software to be licensed-washed from Free to Open.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#332

Post by LtWorf »

jasomill wrote: post #280
WhyNotHugo wrote: post #278

Earlier quoted context omitted.

This isn't portable though, it's a GNU-specific "smart" things. Elsewhere, this overwrites the target device file.

Redirection doesn't overwrite device files, so cat foo.img > /dev/sda works and should be portable. No control over the buffer size, though.

And no printing of progress either.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#333

Post by tmtvl »

torginus wrote: post #307
pjmlp wrote: 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...

They were for a long time the only big distro which made it easy to install non-free drivers.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#334

Post by chris_st »

c0balt wrote: post #268
chris_st wrote: post #257

Earlier quoted context omitted.

Just curious, why the 'sudo tee {file} > /dev/null'?

it writes to the file with elevated priviledges and doesn't write it back to the terminal, effectively a 'sudo sh -c '{cmd} > {file}''. sudo tee is a common way to work around priviledge restrictions in shell pipes (you can't easily 'sudo' a pipe), if /secure was 0600 and owned by root: "sudo echo "test" > /secure" or "sudo printf '' > /secure", would not work because your user's shell process can't write to /secure.…

Cool, thanks!

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#335

Post by linsomniac »

torginus wrote: post #323
JdeBP wrote: post #320

Earlier quoted context omitted.

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 p…

>But the Rust community needs to invest time and energy into finding why that's the case and fixing it.

As I said in my post, the rust coreutils team HAS fixed this in 0.11. It's just that Ubuntu 26.04 is stuck on the older one.

Shipping a coreutils that is version 0.8 in an LTS release seems like an interesting choice.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#336

Post by chuckadams »

gpm wrote: post #85
IshKebab wrote: post #84

Earlier quoted context omitted.

Do any widely used languages guarantee tail call optimization? It's a pretty niche feature.

Scala, ocaml, racket, clojure, zig. For recursion only kotlin. (For most of these only with syntax specifying it)

JavaScript too, but only implemented in JavaScriptCore, so basically just Safari and Bun.

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#337

Post by [deleted] »

torginus wrote: post #309
stouset wrote: post #62

Earlier quoted context omitted.

I’m a huge proponent of Rust and generally lean a lot closer to the RIIR mentality than most, but this effort seems to be such a waste of effort and resources. There have been a dozen CVEs reported against all of coreutils in the past twenty years. The most recent audit of uutils-coreutils turned up forty-four CVEs. By all appearances they’re replacing battle-tested and fundamental tooling which hasn’t been a problem…

Yes, these proclamations of Rust devs that 'the future belongs to us', aren't getting any new fans for the language. Here's my rebuttal: YOU have proclaimed the language to be as fast as C while being safe. YOU need to prove it. Think of this as an OPPORTUNITY to PROVE that Rust can walk the walk, and you can make Rust coreutils as fast as the C one. Think hard about how you can model low level Linux constructs safel…

[deleted]

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#339

Post by torginus »

linsomniac wrote: post #335
torginus wrote: post #323

Earlier quoted context omitted.

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 p…

>But the Rust community needs to invest time and energy into finding why that's the case and fixing it. As I said in my post, the rust coreutils team HAS fixed this in 0.11. It's just that Ubuntu 26.04 is stuck on the older one. Shipping a coreutils that is version 0.8 in an LTS release seems like an interesting choice.

Sorry I didn't see your post.

But I guess that shows another weakness of Ubuntu's model of versioning. You can't fix a bug if they don't merge. They have their own bugtracker (and so does every distro?) so you, Mr Dev have to deal with angry users not only on your Github Issues page, but on every distro's own bugtracker as well, and will have to perpetually support whatever old version they decided to shit (times X distro).

Does that mean BTW that they'll keep shipping the same broken dd for the next 2(4) years?

Re: Ubuntu 26.10 completes transition to Rust-based coreutils

#340

Post by wannabe44 »

timcobb wrote: post #238
egorfine wrote: post #56

Earlier quoted context omitted.

The reason for existence of uutils is ideological, not technical. Thus code quality is of no use for the objective.

> The reason for existence of uutils is ideological, not technical. which ideology? Are people saying that there's an ideology of pushing rust for things without concern for quality? Sincere question, because I'm seeing that on this thread and I wasn't aware that that was a thing beyond the "re-write it in Rust" meme.

Beside the license thing mentioned, rust folks are obsessed with an idea of memory safety to an extent of discarding every other value in programming. To the extent of considering other choices "immoral". This manifests in their disproportionate initiatives of rewriting otherwise fine programs. Of course this doesn't include copious amounts of unsafe in popular libraries because can't leave any benchmarks defeated. But somehow Go is sinful because multiword data races are theoretically memory unsafe (a property which has led to zero (0) CVEs). This may also be the result of jealousy that something plebian like Go became more popular than their perfectly designed language.

Let's not mention other aspects of security, such as the recent supply chain issue, or the old story of the serde maintainer shipping a binary blob just because...

Post reply on HN