Live data from Hacker News

Cross-platform Rust rewrite of the GNU coreutils

github.com

141–150 of 498 posts

Re: Cross-platform Rust rewrite of the GNU coreutils

#141
post #41

Earlier quoted context omitted.

It looks like there are 134 instances of 'unsafe', in 23,000 lines of Rust. And it looks like a lot of that unsafe is to FFI into libc. Rust works with GDB, so you end up debugging like anything else. IDE integration is being actively worked on, and sorta-kinda works in my understanding.

What is the roadmap on getting rid of the need for libc? Given how terrible libc is, I personally would make that a high priority, though I guess in Linux you can't even start up a process without libc (maybe that is a misunderstanding?), which makes the situation less clean, but at least you could get to a point where you never call back into it after entry into main.

You dont need a libc to start a process on Linux.

Re: Cross-platform Rust rewrite of the GNU coreutils

#142
post #109
post #84

Earlier quoted context omitted.

I could see preferring svn to git because of the simpler model, but cvs ? No thanks, a vcs without atomic commits is not much better than snapshot archives, maybe worse actually.

For my use case, it's way more preferrable: a) SVN seems daunting and complex, tho I didn't ever dive into it. CVS is so simple and easy, a half-arsed programmer like me can actually understand it. Things like git and mercurial are way more complex. b) RCS is real handy for single files, e.g. a free-standing text file or shell script. But when the thing grows up, it is very easy to integrate the fileset into a CVS re…

SVN is way simpler at the interface than CVS, you should really look into it. SVN is a spiritual successor to CVS, and is trivially easy for a CVS user to pick up. We switched from CVS to SVN at work several years ago and everyone was happy with the change.

Re: Cross-platform Rust rewrite of the GNU coreutils

#143
post #67

> Many GNU, Linux and other utils are pretty awesome, and obviously some effort has been spent in the past to port them to Windows. However, those projects are either old , abandoned, hosted on CVS , written in platform-specific C, etc. I have seen such a paragraph in another projects README, IIRC a Go rewrite of standard utilities. I do not understand why a project would be obsolete because it's on CVS or is old. CV…

Open source is useless if the majority of people in the open community -- for whatever reason -- can't build it. If a person can't build the thing, they effectively have no power to contribute to changing it. If they have no power to contribute to changing it, it's... spiritually, missing the most essential parts of open source. This is the fundamental issue driving comments like the quote above. You can tell me that…

This project does not really improve upon the situation, as it uses what it is to replace for building, and a very complex Makefile where there's no need for one.

I've said nothing about dependency management as in fetching code that the project depends on. I'm talking about compilation dependencies, i.e. file a.o depends on a.c, a.h, b.c and b.h. Make is for this:

  a.o: a.c a.h b.c b.h
          cc -o ${.TARGET} ${.ALLSRC}
But nowhere in the projects Makefile the rules are in this fashion. They are like shell aliases. What I wanted to say is that the Makefile could be replaced with a bunch of shell scripts that would be easier to use and maintain.

For the rest, it seems that we mostly agree, tho I do not think that CVS is not sane, it's perfectly usable.

Re: Cross-platform Rust rewrite of the GNU coreutils

#145

Earlier quoted context omitted.

This is very very weak grounds for any sort of lawsuit. But if having glanced at GPL source code prevents implementing similar functionalities in an entirely different language, that's a pretty darn strong argument for me to never look at GPL code again.

>that's a pretty darn strong argument for me to never look at GPL code again This is only an issue if your derivative work is under a different license.

Can you guarantee that you will never write a piece of software under a non-GPL license for the rest of your life? I certainly can't and I suspect that few programmers other than RMS can.

Re: Cross-platform Rust rewrite of the GNU coreutils

#147
post #113

Earlier quoted context omitted.

Not sure why you're being downvoted. I don't see why we shouldn't be moving to languages like Rust given the chance, as C makes it far more difficult to write safe and correct code.

> I don't see why we shouldn't be moving to languages like Rust given the chance, as C makes it far more difficult to write safe and correct code I agree in principal, however the timing is wrong. Rust is a very new language (less than 6 years old), and is undeniably totally unproven. It is the latest "buzz" language, and may not be around long term... nobody knows. What-more, a full-fledged re-write of CoreUtils in…

Alupis wrote: "Average users who just consume distro's are not going to switch to a new unproven CoreUtils (even if they knew how), and distro maintainers are not going to switch until it's proven either. It will take a huge company with a huge install-base switching and testing it in production for many years before others start to feel comfortable... however this is also an enormous burden on said mega-corporation, for little-to-zero perceived benefits."

Seems like this is a good opportunity for Mozilla to demonstrate the resilience of Rust and its ecosystem by adopting Rust as the language of choice, where possible, and deploying in-house a custom Linux system in which Rust-written components are plugged-in, as and when they are written and ready, with perhaps a full-fledged switch to Redox sometime in the future. If Rust and software written in it are pushed to their limits within Mozilla, then its not an unreasonable recommendation for it to be deployed on an even wider scale.

Re: Cross-platform Rust rewrite of the GNU coreutils

#148
post #76

Earlier quoted context omitted.

Prof. Regehr did not find problems with SQLite. He found constructs in the SQLite source code which under a strict reading of the C standards have “undefined behaviour”, which means that the compiler can generate whatever machine code it wants without it being called a compiler bug. That’s an important finding. But as it happens, no modern compilers that we know of actually interpret any of the SQLite source code in…

Really, if your project intends to be portable C code, you need to compile it with undefined behaviour generating an error.

Undefined behavior is not always identifiable through static analysis. Obviously it can be checked against at runtime, but that's actually quite expensive. It would, for example, include bounds checks for everything, and overflow checks on all signed arithmetic.

Re: Cross-platform Rust rewrite of the GNU coreutils

#149
post #113

Earlier quoted context omitted.

Not sure why you're being downvoted. I don't see why we shouldn't be moving to languages like Rust given the chance, as C makes it far more difficult to write safe and correct code.

> I don't see why we shouldn't be moving to languages like Rust given the chance, as C makes it far more difficult to write safe and correct code I agree in principal, however the timing is wrong. Rust is a very new language (less than 6 years old), and is undeniably totally unproven. It is the latest "buzz" language, and may not be around long term... nobody knows. What-more, a full-fledged re-write of CoreUtils in…

I think you're missing the point; this project looks to me more like a learning exercise, which is just fine.

Re: Cross-platform Rust rewrite of the GNU coreutils

#150
post #83

What are the licensing implications for this kind of work? I assume the authors used GNU coreutils as more than just inspiration. They probably read all the original code and reused some of the solutions (obviously ported to Rust). Shouldn't the derivative work still be covered by the GPL?

I've contributed to this project, and yeah, this was a major concern for me while I was doing it. If it shared a license with GNU coreutils, then code sharing would be free and the project would be built much faster because I could just use coreutils's algorithms. As it is, I haven't done any real, hard work for it because frankly, I won't want to re-invent that wheel. The project isn't terribly far along. I wonder i…

I've submitted an issue asking to shift to a GPL license.

My general perspective on code I write that isn't for work - it has to be GPL. I refuse to have my code be yoinked by random corporations for their profit without having the code shared downstream.

Post reply on HN