Rust-Written Replacement To GNU Coreutils Progressing, Some Binaries Now Faster

[wswartzendruber]

No, they ABSOLUTLEY can ship a GPL program as part of a proprietary suite, alongside other programs with which they don't share source. The language in the GPL talks about code linking during compilation or as dynamically loaded libraries. Outside of that it doesn't apply. The alternative would be insanity because putting unrelated programs together into a distro or anything else (even a zip file to a friend) would constitute a breach.

Just because you would LIKE for it to be otherwise (forcing microsoft to either go completely GPL or stay away entirely) doesn't change the legality of the situation.

Perhaps you would care to assess the Windows EULA? Section 2.c is full of interesting things that contradict GPL section...

...you know what....forget it.

[sdack]

Well, Rust does makes eliminating several classes of memory related issues/vulnerabilities more accessible. That´s its main selling point ...

You want to take a second look at this. Just because a C program can cause a segmentation fault or a bus error does not mean there is evil at play and so needs to be feared. You can catch these signals and handle them in your program. These signals are triggered by the OS, which is itself only executing its own code. These are not punishments like some want to believe, but these are help mechanisms. One can disable them and ignore them if wanted. Do you then think you could not do index-by-1 errors or just miscalculate indices in Rust?! Of course, you can. Chances are that with Rust you get no signs at all, your code runs seemingly without issues because it satisfied the more prohibitive demands by the compiler, but this does not make the code magically into correct code and you have no hint or clue as to where to start looking for the problem. Whereas with C/C++ will the operating system trigger a signal to inform you of the error and produce a core dump, which contains the entire program state at the time of the bug and is used with a debugger to analyse the bug.

Rust is like a wooden sword you give to a child. We use C/C++ not because it prohibits us to do the things we want, but because it allows us to do more and even things that are seemingly unsafe. Seemingly, because there really are many ways to make computer systems safe and it does not first require a new prohibitive and overbearing language. Even if there was more risk to it would we still continue to use C/C++. It is why we invented the steam and combustion engine, why we flew to the Moon, and why we run 240V lines through our homes, not because it is safe, but because it brings progress.

[coder]

Do you then think you could not do index-by-1 errors or just miscalculate indices in Rust?! Of course, you can.

Sure, you can write illogical code in any language.

Chances are that with Rust you get no signs at all, your code runs seemingly without issues

You're saying Rust will let you walk off the end of an array, while saying or doing nothing (as long as it's not detectable at compile-time)?

Or are you complaining that in-bounds accesses that are simply off by 1 won't be flagged (just as they're not flagged in C)?

Whereas with C/C++ will the operating system trigger a signal to inform you of the error and produce a core dump

C (on Posix) doesn't guarantee a segfault, when you overrun a buffer by just 1 entry. Core dumps only happen when you overrun a page-boundary of heap memory. That means it doesn't happen on many overruns, especially if your array is on the stack.

[mmstick]

Just because a C program can cause a segmentation fault or a bus error does not mean there is evil at play and so needs to be feared. You can catch these signals and handle them in your program. These signals are triggered by the OS, which is itself only executing its own code. These are not punishments like some want to believe, but these are help mechanisms. One can disable them and ignore them if wanted.

Ah yes, you don't have to adhere to the rules of the road. You can ignore all signals and signs that you see. I really hope you aren't writing software as a profession. Ignoring memory access violations is one of the worst possible things that you can do. Not only are you directly triggering undefined behavior and opening the door to security vulnerabilities, but you're also risking corrupting memory in the application resulting in strange and potentially dangerous behaviors. I hope that no one is using software written like this.

Rust triggers panics when accessing an array out of bounds. It also provides a mechanism for safely recovering from a panic, provided the panic isn't passing through a FFI boundary.

Do you then think you could not do index-by-1 errors or just miscalculate indices in Rust?!

Someone apparently has never heard of iterators. You don't iterate by indexes in Rust.

for value in iterable { }

for (index, value) in iterable.enumerate() { }

There are also so many convenience functions that calculate indexes for you.

if let Some(index) = iterable.position(|value| condition(value)) {}
if let Some(suffix) = string.strip_prefix("Key=") {}

And when most people refer to using indexes as keys to a map, they're referring to generational arenas like slotmap, where the indexes aren't manually written or calculated.

but this does not make the code magically into correct code and you have no hint or clue as to where to start looking for the problem

You seriously think that it's so much easier to debug memory access violations and logic errors in C applications? You have no idea how instrumental the `Debug` trait is in Rust, or the `dbg!()` macro that prints the contained expression and its `Debug`-implementing output, or even how comprehensive the logging functionality is with logging libraries like tracing being used to develop sophisticated logging tools like tokio-console.

let value = dbg!(generate_complex_structure());

Whereas with C/C++ will the operating system trigger a signal to inform you of the error and produce a core dump, which contains the entire program state at the time of the bug and is used with a debugger to analyse the bug.

You must be trolling. No one seriously believes that the OS recognizes your logic errors and sends signals to inform you of them. If your application is having memory access violations, it's already a lost cause and should be moved to /dev/null. If my application has a severe unrecoverable logic error which I can reliably check at runtime, I'm going force it to panic to get nicely-generated backtraces.

As I said, getting strong "Old Man Yells at Cloud" vibes in this thread.

[pabloski]

But Rust is not going anywhere. It is dead on arrival and will not even be a footnote compared to other languages. You will never be a good programmer when you fear C/C++. There are far too many good programmers on the market who can do your job without needing Rust.

If you are so knowledgeable show us some piece of Rust "disaster" code. Because what you are writing is utterly absurd. It is clear you don't understand Rust's programming model at all. And you understand the holes in the C/C++ programming model even less.

Do you know that Rust's inventor was/is a C++ guru?

[darkonix]

You want to take a second look at this. Just because a C program can cause a segmentation fault or a bus error does not mean there is evil at play and so needs to be feared. You can catch these signals and handle them in your program. These signals are triggered by the OS, which is itself only executing its own code. These are not punishments like some want to believe, but these are help mechanisms. One can disable them and ignore them if wanted. Do you then think you could not do index-by-1 errors or just miscalculate indices in Rust?! Of course, you can. Chances are that with Rust you get no signs at all, your code runs seemingly without issues because it satisfied the more prohibitive demands by the compiler, but this does not make the code magically into correct code and you have no hint or clue as to where to start looking for the problem. Whereas with C/C++ will the operating system trigger a signal to inform you of the error and produce a core dump, which contains the entire program state at the time of the bug and is used with a debugger to analyse the bug.

Rust is like a wooden sword you give to a child. We use C/C++ not because it prohibits us to do the things we want, but because it allows us to do more and even things that are seemingly unsafe. Seemingly, because there really are many ways to make computer systems safe and it does not first require a new prohibitive and overbearing language. Even if there was more risk to it would we still continue to use C/C++. It is why we invented the steam and combustion engine, why we flew to the Moon, and why we run 240V lines through our homes, not because it is safe, but because it brings progress.

I was not talking about logical errors. I agree you can write incorrect logic in any language. The checks and restrictions that Rust implements are to avoid specific kinds of errors, that are those associated with memory errors that can easily become security vulnerabilities and exploited. We are not talking about the situations when the program is going to crash, because if every program that had memory issues crashed vulnerabilities would not have so severe impacts. Currently memory is intentionally overwritten in specific ways per architecture to take control of the system. In this age developers can't just assume the problem is someone else responsibility. Even a crash may have a significant impact in mission critical systems.

This kind of attacks were not something foreseen when C was created around 50 years ago. Currently it is talking more and more effort to maintain the security of C codebases that many are looking for better alternatives. We will probably have a significant C codebase 50 years from now, but it doesn't mean new programs will still be developed in it.

[sdack]

I was not talking about logical errors. I agree you can write incorrect logic in any language. The checks and restrictions that Rust implements are to avoid specific kinds of errors, that are those associated with memory errors that can easily become security vulnerabilities and exploited. We are not talking about the situations when the program is going to crash, ...

No, we were talking about selling points and I do not want you to think C/C++ would not have anything to offer. These just have more to offer than people know. What happens 50 years from now is unknown, but I guarantee you Rust will neither have the answer for it nor will it matter. You are only imagining how you would need Rust now, when what you are really doing is to rationalize a fear. There is no need for it. Look at how virus-infested the Windows environment was and how little this mattered. On the contrary, businesses thrived on selling you anti-virus software. Attacks today are so diverse that nobody is going to change to a new language just because it addresses a tiny fraction of these attacks, especially when there are several ways to protect against these already. Wanting to sell Rust on the basis of fear is just going to hurt it more than you know.

[darkonix]

No, we were talking about selling points and I do not want you to think C/C++ would not have anything to offer. These just have more to offer than people know. What happens 50 years from now is unknown, but I guarantee you Rust will neither have the answer for it nor will it matter. You are only imagining how you would need Rust now, when what you are really doing is to rationalize a fear. There is no need for it. Look at how virus-infested the Windows environment was and how little this mattered. On the contrary, businesses thrived on selling you anti-virus software. Attacks today are so diverse that nobody is going to change to a new language just because it addresses a tiny fraction of these attacks, especially when there are several ways to protect against these already. Wanting to sell Rust on the basis of fear is just going to hurt it more than you know.

Microsoft says that 70% of the CVE security vulnerabilities in their products are related to memory safety issues and that they were not able to curt this trend until now. Google reported that despite all their efforts they have a similar percentage related to Android’s high severity security vulnerabilities. Both have been trying to improve the stability and security of their products with not too much success until now. It is not a tiny fraction at all. It is the big majority of security issues. Just the cost of the impact of the issues and fixing them can easily justify investing in something else. I recommend reading these and other articles. They are very interesting.

They are both mentioning that C/C++ is not going to be fully fixable ever, and looking into Rust as a possible solution. In addition others like Amazon are using it too. Even Linus Torvalds, the creator of Linux, who has trashed most every other language that was suggested for the Linux Kernel, is sponsoring the experimental infrastructure for Rust in the Linux Kernel.

Interestingly Google found that most of the issues reported are in new code with less than a year, while older code seems more stable. That supports the strategy of writing new code in a safer language than try to rewrite older software. That is the strategy most people are taking these days to get a feeling of using Rust in incremental steps.

[mmstick]

There's really no point trying to argue with people who are still in denial about memory safety 20 years after AT&T Labs proved it possible in their Region-based Memory Management paper. Which is the entire basis around which Rust's lifetime concepts and syntax originated. Rust has come at the right time when it's been needed most, and that's why it's been adopted by virtually every big company now.

[Developer12]

Perhaps you would care to assess the Windows EULA? Section 2.c is full of interesting things that contradict GPL section...

...you know what....forget it.

Yeah, and that EULA covers code that doesn't link with anything GPL. There's a damn good fucking reason the GPL *STOPS* at the linking barrier.

In the world you're describing, it would be illegal for microsoft to put mspaint.exe (covered under their EULA) and GNU make's binary (under the GPL) into a zip file together and ship it. This is stupid.

The first minor issue is people wouldn't be able to write GPL software for windows. Windows users get no software freedom at all because any GPL-licenced program running on windows has to make windows syscalls into the NT kernel.

But it gets worse.

You're suggesting that the GPL should have preview over THE ENTIRE OS from as little as one program. Do you really want to give proprietary EULAs that much reach? They operate on the same copyright mechanisms as the GPL. How would like it if the windows-intel alliance started putting terms in in the EULA of their boot code (which cannot be replaced as you can't boot the system without it) dictating what you're allowed to run in your Linux userland?