Can we please also have the hard requirement that code should run without warnings under Valgrind?
Because that saves a lot of headaches down the line.
Hard Rust requirements from May onward
171–180 of 797 posts
Re: Hard Rust requirements from May onward
#172I think this is the wrong way to promote rust. For me rust is just a hype. I know nobody that programms or even thinks about rust. I’m from the embedded world an there c is still king. I understand that some will see rust as a good alternative, but as long as the real money is made in c it is not ready
> I think this is the wrong way to promote rust
This is entirely the wrong lens. This is someone who wants to use Rust for a particular purpose, not some sort of publicity stunt.
> I know nobody that programms or even thinks about rust. I’m from the embedded world a there c is still king.
Now’s a good time to look outside of your bubble instead of pretending that your bubble is the world.
> as long as the real money is made in c it is not ready
Arguably, the real money is made in JavaScript and Python for the last decade. Embedded roles generally have fewer postings with lower pay than webdev. Until C catches back up, is it also not ready?
Re: Hard Rust requirements from May onward
#173Earlier quoted context omitted.
I haven't either, until I read comments on Rust in Linux on social media outside HN. Apparently, Rust is part of the "woke agenda"
People are (understandably) sick of the fact that for whatever reason, the biggest proponents of Rust are insufferable. Personally, I'm simply bothered by the fact that (one of?) the most famous figure of Rust on Linux and Rust Forever consumes and advocates for pornography that's illegal in my country, without being held accountable by the community. From what I could piece together, the only group who ever cried wo…
> advocates for pornography that's illegal in my country, without being held accountable by the community
If some form of speech is illegal in your country it does automatically mean it should be illegal for the whole world or that it is wrong or that the world-wide community should adhere to standards specific to your country. Even if that country is USA.
In other words, nobody should give a flying f about open source developers porn preferences.
Re: Hard Rust requirements from May onward
#174Earlier quoted context omitted.
> I don't quite understand the pushback against memory safe languages As far as i read on HN, the only memory safe language discused on HN is rust and mostly with childish pro arguments.
Java and C# are memory safe languages, as are common interpreted languages like Python and Ruby. Even JavaScript is memory safe, barring the possibility of subtle JIT bugs that may practically impact such safety.
Even modern C++ is memory safe when used properly.
Re: Hard Rust requirements from May onward
#175Earlier quoted context omitted.
What a horrible mindset. I'll never understand this "security" argument. It is our responsibility to our users to provide them the most secure option possible as the default. Removing features is not the most secure option possible. Go all the way then and remove everything. Only when your computer cannot do anything it will be 100% secure.
> Removing features is not the most secure option possible. If I have a program that encrypts and decrypts passwords, then the surface area is way smaller than if it also has browser integrations and a bunch of other features. Every feature has the potential to make this list longer: https://keepass.info/help/kb/sec_issues.html which applies to any other piece of software. At the same time, people can make the argume…
A password program that integrates with your browsers reduces a lot of attack surfaces. If you can't directly talk to the bower that implies the clipboard which in turns means other programs on your system can see the password.
Re: Hard Rust requirements from May onward
#176Earlier quoted context omitted.
What a horrible mindset. I'll never understand this "security" argument. It is our responsibility to our users to provide them the most secure option possible as the default. Removing features is not the most secure option possible. Go all the way then and remove everything. Only when your computer cannot do anything it will be 100% secure.
Some people don't have actual understanding of the meaning of security. Security is there to keep the features usable without interruptions or risks. E.g. plugging the computer off the network is not about security if the service needs to be accessible.
That doesn't sound right to me; its legitimate topic that a package where the core use-case is X, that package has obscure feature Y, and the mere existence of Y can cause security issues for a user even when the user never intended to use it.
Very concrete example, the whole Log4j vulnerability issue was basically just a direct implication of a feature that allowed for arbitrary code execution. Nearly no user of Log4j intentionally used that feature, they were all vulnerable because Log4j had that feature.
The fix to the CVE was effectively to remove the feature. If someone had the foresight to try to reduce Log4j to only the features that ~everyone actually used, and publish a separate Log4j-maximal for the fringe users that intentionally use that feature, it would have prevented what was arguably the worst vulnerability that has ever happened.
In the case this thread is about, no one seems to be deny that there should be a 'minimal' and 'full' versions and that the 'minimal' version is going to be more secure. The entire flame war seems to be over whether its better to take a preexisting package name and have it be a minimal one or the full one.
That is simply a tradeoff between "make preexisting users who don't use ancillary features be as secure as possible by default going forward" or "make preexisting users who do use ancillary features not broken by upgrades".
Re: Hard Rust requirements from May onward
#177Earlier quoted context omitted.
> I think the spin that Rust is necessarily the way forward is what is wrong. Well, what's the alternative? The memory safety problem is real, I don't think there is any doubt about that. C/C++ is a dead end: the community has thoroughly rejected technical solutions like the Circle compiler, and "profiles" are nothing more than a mirage. They are yet again trying to make a magical compiler which rejects all the bad c…
Basically correct, but Zig is not a memory safe language. It may be an improvement wrt. syntax over C, and its standard library facilities may be genuinely better than Rust's wrt. writing unsafe code, but it's simply not interesting from a safety perspective. I'm sure that even the most rabid Zig advocates would readily acknowledge this point. > Garbage collection is a huge dealbreaker for the people still on C/C++.…
Rust technically isn’t a memory safe language the second you use “unsafe”. Rust advocates tend to pretend the can have their cake and eat it too when comparing it to other low level languages. No, just because you have the word unsafe next to the scary parts doesn’t make it okay.
I’ve written a good chunk of low level/bare metal rust—unsafe was everywhere and extremely unergonomic. The safety guarantees of Rust are also much weaker in such situations so that’s why I find Zig very interesting.
No oob access, no wacky type coercion, no nullptrs solves such a huge portion of my issues with C. All I have to do is prove my code doesn’t have UAF (or not if the program isn’t critical) and I’m basically on par with Rust with much less complexity.
Re: Hard Rust requirements from May onward
#178The language is incredibly frank, and I agree with it completely. The retro-computing hobby doesn't need the ability to run contemporary operating systems. It's insane that x86 Debian is still compiling all software targeting Pentium Pro (from 1995!). x64 Debian is a bit more modern, and you must splurge for a CPU from 2005 (Prescott) to get the plethora of features it requires
> targeting Pentium Pro (from 1995!).
BTW, today is Pentium Pro's 30 years anniversary.
Re: Hard Rust requirements from May onward
#179Re: Hard Rust requirements from May onward
#180I think polyglot causes more problems than it solves. It is gross how many different toolchains and package managers it now takes to build a distro. One person wants python, another wants node, another wants go, and now this. with node we traded buffer overflows for supply chain attacks. If they don’t want C, it would be better to start fresh. Robert Morris re-wrote enough of Linux in golang to be usable, and the ove…
There needs to be a limit for each project. Debian is a large project so it needs to have more options than smaller projects. Rust is getting popular enough it is reasonable for Debian to say it is an approved option.
Note that I'm not saying Debian should, I'm saying it is reasonable that they would. I am not a Debian maintainer and so I should not have an opinion on what tools they use, only that adding Rust isn't unreasonable. It may be reasonable to take away a different tool to get Rust in - again this is something I should not have an opinion on but Debian maintainers should.