[HN Gopher] Reimplementing the Coreutils in a modern language (R...
___________________________________________________________________
Reimplementing the Coreutils in a modern language (Rust)
Author : doener
Score : 68 points
Date : 2023-02-13 21:30 UTC (1 hours ago)
(HTM) web link (fosdem.org)
(TXT) w3m dump (fosdem.org)
| siraben wrote:
| Nixpkgs experimented with a build environment based on uutils-
| coreutils instead of GNU coreutils[0]. A lot of bugs or
| unimplemented features were uncovered which were fixed upstream
| and as a result software such as chromium, vim, emacs or even
| rustc itself builds properly now.[1] So it definitely could be a
| viable alternative in the future.
|
| [0] https://github.com/NixOS/nixpkgs/pull/116274
|
| [1]
| https://github.com/NixOS/nixpkgs/pull/116274#issuecomment-85...
| abathur wrote:
| I'm always cautious about who I _recommend_ Nix to, but I
| usually say that one of the best things waiting on the other
| side of the learning curve is what an incredible always-
| improving lever nix and nixpkgs can be for just about any task
| that involves or benefits from ~integrating a lot of software.
|
| But it's also hard to communicate what I mean by that without
| diving into a bunch of detail on some case where it proved
| useful to me.
|
| The ability to give uutils a shake at scale is a paragon.
|
| At some point I imagine it'll be able help ferret out a good
| fraction of remaining long-tail issues with oilshell's mostly-
| bash-compatible `osh` in short order.
| Ameo wrote:
| I recently came across a very interesting history of the early
| evolution of the Unix OS and some of these core utils during the
| 1970s and early 1980s:
|
| https://www.cs.dartmouth.edu/~doug/reader.pdf
|
| Lots of cool details about stuff like the gradual migration of
| the kernel from 100% assembly C and the origin stories of a lot
| of these ubiquitous utility programs like cp, ls, etc.
| enriquto wrote:
| Link to the actual implementation:
| https://github.com/uutils/coreutils
|
| I love these re-implementations of things. Technology advances by
| the continued reinvention of the wheel, and even if some efforts
| end up being of merely didactic interest, it is still important
| to make them. Coreutils is one of the pillars of our
| civilization, and thus it should be re-implemented several times
| on many programming languages.
|
| Looking at the source code, it is impressive that this re-
| implementation is essentially complete! Look at this:
| https://github.com/uutils/coreutils/tree/main/src/uu It's only
| missing some obscure and fringe things.
|
| An important feature of GNU coreutils is, somewhat sadly, not
| reproduced by this re-implementation: the copyleft license of the
| original implementation. This takes out some freedom of the
| users. For example, when I use GNU "ls", I know that I can always
| look at its source code and change it to my whim (or hire a
| programmer to change it for me). However, if I use uutils "ls",
| this is not necessarily the case, for it may be a re-distribution
| by some middle-men that has modified it slightly and does not
| provide the source code. I suppose that the removal of this
| freedom is accidental, because it was a nice thing.
| codetrotter wrote:
| > I suppose that the removal of this freedom is accidental,
| because it was a nice thing.
|
| Not necessarily. Some people prefer the MIT/BSD/ISC family of
| licenses over GPL.
| jordigh wrote:
| It should be forbidden to forbid. That's what I don't like.
|
| Most of us have employers who are afraid of copyleft. That
| has made us afraid of copyleft, because we feel like our job
| is threatened by copyleft. But the erosion of copyleft over
| the decades has produced phones that track us, websites that
| control our dating lives, our food, the entertainment we
| consume, social media that manipulates our emotions and our
| friendships, and countless other things without us having any
| recourse or control.
|
| For a while, copyleft was good. It gave us Linux on laptops,
| where we have the source code for nearly every part of the
| stack. Without copyleft, we have locked phones, tablets, game
| consoles, e-readers, refrigerators, cars, pacemakers, and
| many other devices that are difficult to really call our own
| because they have software that ultimately obeys the
| manufacturer, not the consumer.
| arp242 wrote:
| "Anyone who dislikes copyleft is a simple-minded fool
| brainwashed by their employer to hate GPL" is quite the
| take.
|
| I also don't really think most of the examples you cite are
| all that strongly related to "erosion of copyleft" (if such
| a thing has happened in the first place; I'm not so sure it
| has - I'd have to check license counts of packages but BSD
| licenses and MIT license have been popular for many
| decades).
| burntsushi wrote:
| Nice. Recasting "prefer MIT" to "afraid of copyleft."
|
| I'm pretty sure we've had this discussion before on
| lobste.rs, yet you continue to mischaracterize and lump all
| opposition of copyleft into some irrational position based
| on fear, or that we somehow can't think for ourselves
| because our employers don't like copyleft.
|
| My full position: https://github.com/BurntSushi/notes/blob/
| master/2020-10-29_l...
| graphe wrote:
| You can have it be open source and locked down. Most of
| those devices you mention run Linux, BSD, or RTOS.
| jordigh wrote:
| Open source, yes. Copyleft, no. GPLv3 forbids what many
| of these devices do. It is why GPLv3 is so feared by many
| companies, like Apple, why the GPL was gradually purged
| from macOS.
| roarcher wrote:
| Nobody is "afraid" of copyleft, that's hyperbolic. People
| make informed decisions that copyleft requirements don't
| work for them, and they have every right to do so.
|
| I won't buy a house in an HOA. I'm not afraid of HOAs, I
| just have better things to do with my time than keep up
| with their demands.
| medler wrote:
| I don't think it was accidental. There's a long thread in the
| uutils repo with a discussion (slash flame war) about the
| license choice:
| https://github.com/uutils/coreutils/issues/834
| arp242 wrote:
| Thank you; that was an entertaining thread. "GPL is
| inherently fascist" is a new one.
| cwp wrote:
| Yup. Whenever I release my code to the world, I use MIT. I'm
| not brainwashed, I know what I'm doing. If someone
| incorporates my code into a proprietary product, that's fine.
| I hope they're successful! I just want the bragging rights.
| [deleted]
| charcircuit wrote:
| >if I use uutils "ls", this is not necessarily the case, for it
| may be a re-distribution by some middle-men that has modified
| it slightly and does not provide the source code
|
| You are still free to go and work off of the upstream version
| of uutils.
| yjftsjthsd-h wrote:
| How does that help when I want to work on the thing actually
| running on my machine?
| charcircuit wrote:
| And how does GNU coreutils being GPL help you if the ls you
| have didn't come with source? Even if the ls you have is a
| fork of GNU coreutils's ls there is nothing you can do to
| get the source. The FSF can't either. But the FSF can stop
| it from being distributed and collect money from damages.
| yjftsjthsd-h wrote:
| > Looking at the source code, it is impressive that this re-
| implementation is essentially complete! Look at this:
| https://github.com/uutils/coreutils/tree/main/src/uu It's only
| missing some obscure and fringe things.
|
| It's not just a matter of having all the individual tools, it's
| a matter of having them be functionally complete and behaving
| either the same as GNU or POSIX - note the graph part way down
| the readme that talks about having only slightly better than
| half of the tests passing. And the tests probably aren't truly
| comprehensive, especially for things that people didn't realize
| were implementation specific or non-guaranteed behaviors. It's
| good to see them making progress, I just want to someone temper
| the idea that they're close to done.
| Arcuru wrote:
| The maintainers of that project have said that a lot of the code
| was written by new Rust programmers, so some of the code could
| probably use some help from experienced systems programmers.
|
| I did a little cleanup on their `dd` tool a while ago[1], and I
| would be pretty cautious about actually relying on it anytime
| soon.
|
| [1] https://jackson.dev/post/rust-coreutils-dd/
| danudey wrote:
| Did you post this to HN at the time? I've read this article
| before, but I'm not sure when. Either way, thanks for your
| contributions!
| slackfan wrote:
| This really really REALLY needs an ngate writeup.
| LinuxBender wrote:
| Unless the domain changed it looks like that site stopped
| updating in August of 2021?
| gjvc wrote:
| whomsoever that author was, they deserve a medal.
| bitwize wrote:
| REIMPLEMENTING THE COREUTILS IN A MODERN LANGUAGE (RUST)
|
| The Rust Evangelism Strike Force is coming for your children --
| and the foundation of the Linux userland.
|
| Speaker anagram: TUSSLED REVELRY
|
| Speaker affiliation: Mozilla (business model: Uber for not
| working on browsers)
| nmitchko wrote:
| If it ain't broke don't fix it.
| googlryas wrote:
| It might be broke.
| aliqot wrote:
| Nonsense, Rust never breaks.
|
| edit: still got it :)
| Smaug123 wrote:
| The slides are linked, at
| https://sylvestre.ledru.info/presentations/coreutils-fosdem-...
| (for example), if you don't want to watch a video which
| discusses why they're doing it.
| sophacles wrote:
| This was a good talk. The topic was discussed here the other day:
| https://news.ycombinator.com/item?id=34735455 (op article was
| about the talk, not a direct talk link)
___________________________________________________________________
(page generated 2023-02-13 23:00 UTC)