> These utilities are at the heart of the distribution - and it’s the enhanced resilience and safety that is more easily achieved with Rust ports that are most attractive to me.
What safety issues were found in coreutils in recent memory? I'd be willing to bet that this transition will not solve more problems than it creates.
That said, I'd love for `fd` and `rg` and similar to be included in the standard list-of-things-available-anywhere. It's cool they're now in Debian-stable and don't have to be installed through whatever hacks!
Why? Because it hasn't been a consistent major vector for attack in the last couple of decades?
The Lindy Effect for software: the longer software appears to be bug-free, the more likely it is bug-free.
In 2020, iOS suffered a zero day exploit based on font library code from the 90s. A bug that sat dormant for 30 years.
As far as rewriting / rethinking core utilities, I'm glad that for example `doas` and `sudo-rs` exist to beef up root authentication.
https://googleprojectzero.github.io/0days-in-the-wild/0day-R...
This isn't within my realm of expertise.. but I find it a bit hard to believe that GNU Coreutils is a source of a lot of security and resilience issues with Ubuntu.. Is this true?
Does anyone in the know, know if Ubuntu has any answer to the Nix explosion?
I feel my Ubuntu problems are always weird package issue. The system doesn't make it very transparent to the user how to make your own packages, or how to edit and rebuild an existing package
By contrast I've never had `ls`, `cp`, or `mv` freak out on me..
(I don't personally use Nix b/c I love the stability of Ubuntu LTS. Everyone and their mom makes sure their software can run on the latest LTS)
NixOS or something very much like it is the future. I personally won't go back to the snarled mess of state that is traditional distros like Ubuntu.
Its not a snarled mess if you understand what you are doing, imo. Though, when I first started using operating systems other than Windows (~1998), I was very confused, and made many of the same mistakes new Linux users make. Actually, way worse, as there were no resolution to my mistakes (using linux, was a big one back in the day if you were on newer hardware).
I understand where the sentiment comes from. I just don't appreciate the conclusion or the leech-like entitlement of the community. We used to fix and push.
By snarled mess of state, I don't just mean the way it works on first install, I mean the bundle of mud that imperatively managing a system inevitably turns into, with bits of this and that config left behind.
Try playing around with a few different window managers to feel the pain. NixOS makes it easy to try out new config and revert to the old config without muss or fuss.
I am reasonably sure that you can, not that you need to, use nix with Ubuntu?
I use Ubuntu (and other distros) because I respect the effort behind it.
Why does one need to stop for the other to exist?
I actually don't really know how that interplays with the rest of the system. If I build say... Konsole in Nix.. It seems like there would be no way for it to cleanly integrate with the rest of my KDE Desktop
The normal Nix versions numbers aren't stable. They have a stable branch but I don't think it lasts too long. And the "pinned" versions aren't as widely supported as Ubuntu LTS versions
> parallel set of libraries/dependencies
snaps do the same thing? kind of the whole idea?
> If I build say... Konsole in Nix.. It seems like there would be no way for it to cleanly integrate with the rest of my KDE Desktop
See previous link
Would it be possible to toggle coreutils/uutils via that instead of reinventing it? They're both effectively symlinks-managers.
Also has at least one rewrite in rust:
https://www.debian.org/doc/debian-policy/ap-pkg-diversions.h...
> Do not attempt to divert a file which is vitally important for the system’s operation - when using dpkg-divert there is a time, after it has been diverted but before dpkg has installed the new version, when the file does not exist.
I doubt that diversions are safe for coreutils. Now personally I'd like to know if that could be fixed instead of making a new tool, but /shrug
One reason I never adopted tools like exa or bat is that the first deviates from ls flags, and the second changes cat’s buffering behavior. The yield from changing the behavior of these fundamental tools isn’t worth the cost.
Also, if memory safety and security—not just performance—are the reasons to rewrite them in Rust, we could just as well write them in Go and get better community engagement. These are mostly CLI tools, so Go’s performance would be more than sufficient. I don’t really buy the Rust evangelism here.
I still wish for a serious book in the style of K&R or Stroustrup with no pictures, no mentioning of the package manager at all (sometimes it is mentioned in the first chapter!) and interesting code examples.
I write Rust and I agree. Hype is the downside of attracting trendiness.
And yes, I’ve done this (start a new project in a plane with no internet). Many times. eg: the world’s only PalmOS 5 device emulator (uARM-palm) was started while I was in a plane.
And if you really dislike Cargo, nothing is stopping you from using rustc + make directly.
If the packages are already available locally, cargo works offline.
The package manager just offers a common interface for interop, you can still build without dependencies.
I don't think everything needs to be corporate Memphis in text form. Let's have some squirrelfish extreme in this.
Corporate mode comes eventually with quality. And Rust has passed the initial hurdle of adoption. It's pretty much what Python was in the year 2000: the exciting new tech that has adoption.
UNIX also has a playful name (from Multics)
Damn, never heard of someone passing on a language because of pictures. First time for everything I suppose.
C++ has too many footguns and too much crap that makes it terrible... I am looking exactly at template compiler output and also cmake.
So, get on board or don't but don't try to make it C++ again.
