Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hard Rust requirements from May onward

lists.debian.org

Post reply on HN
Print view View original

361–370 of 797 posts

Re: Hard Rust requirements from May onward

#361

Post by dathinab »

noosphr wrote: post #14
justinclift wrote: post #9

Earlier quoted context omitted.

While that seems like it would be true, is that really relevant to Debian? :)

The person making the post is getting paid by Ubuntu.

sure but most frequent/core contributors for Linux (kernel) and most big Distros are payed by some company with commercial interest which mostly doesn't involve spending time on maintaining any of this old architectures

sure some are also payed by a foundation. Which is also payed by companies but with a degree of decoupling of influence.

and some pay them self, e.g. fully voluntary work, but most dev can't afford to do so on a long term, high time commitment manner. So a lot of major changes and contributions end up coming from people directly or indirectly "payed" by some company.

and that's pretty common across most "older, larger, sustainable and still developed OSS"

Re: Hard Rust requirements from May onward

#362

Post by Denvercoder9 »

parliament32 wrote: post #331

It makes me uncomfortable that this mandate is coming from a Canonical employee. After all, if this switch was a good idea on merit alone, it would happen organically without requiring this kind of combative communication. What's the long-term play for Canonical here?

Apt has just 3 listed maintainers, and judging by the git history this guy does 90% of the work. Him making the decision _is_ it happening organically.

Open source fundamentally is a do-ocracy (it's in literally all of the licenses). Those who do, decide; and more and more often those who do are just one or two people for a tool used by millions.

Re: Hard Rust requirements from May onward

#364

Post by noosphr »

tclancy wrote: post #129
noosphr wrote: post #31

Earlier quoted context omitted.

I find that languages with a high intellectual barrier to entry are much more pleasant places to be since people like the OP can't understand them and we never have people try to bully us into doing things _the right way_. This is someone who says things like >It's important for the project as whole to be able to move forward and rely on modern tools and technologies and not be held back by trying to shoehorn modern…

> since people like the OP can't understand them and we never have people try to bully us Yes well, glad to hear there’s no one bullying people there!

I'm glad you understand how self defense works.

Re: Hard Rust requirements from May onward

#365

Post by noosphr »

noir_lord wrote: post #212
bfkwlfkjf wrote: post #145

Earlier quoted context omitted.

[flagged]

I think that's unkind absent any proof otherwise which you haven't posted. In reality a lot of the heavily used parts of Linux (and open source generally) are going to have some commercial involvement or are we suggesting that no one should be paid by any of the companies backing Linux who use Linux because to me that sounds worse . Whether you like it or not, Linux/Open Source hasn't been entirely the preserve of un…

https://en.wikipedia.org/wiki/The_Scorpion_and_the_Frog

I don't understand how people keep giving the benefit of the doubt to corporations.

They aren't people. They feel no guilt and have no shame.

Re: Hard Rust requirements from May onward

#367

Post by Palomides »

nikanj wrote: post #15

The 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

>retro-computing hobby doesn't need the ability to run contemporary operating systems

why not? I still want to run modern software on older machines for security and feature reasons

Re: Hard Rust requirements from May onward

#368

Post by coderjames »

lambdaone wrote: post #161

It's about time. Critical infrastructure still written in C - particularly code that parses data from untrusted sources - is technical debt that is only going to get worse over time. It's not as if Rust is that much more difficult to write than C. Rust is explicitly designed to be what you'd get if you were to re-create C knowing what we know now about language design and code safety. If 32-bit x86 support can be dro…

> In particular, our code to parse .deb, .ar, .tar, and the HTTP signature verification code would strongly benefit from memory safe languages

> Critical infrastructure still written in C - particularly code that parses data from untrusted sources - is technical debt that is only going to get worse over time.

But hasn't all that foundational code been stable and wrung out already over the last 30+ years? The .tar and .ar file formats are both from the 70s; what new benefits will users or developers gain from that thoroughly battle-tested code being thrown out and rewritten in a new language with a whole new set of compatibility issues and bugs?

Re: Hard Rust requirements from May onward

#369

Post by noosphr »

dicytea wrote: post #134
noosphr wrote: post #34

Earlier quoted context omitted.

Yes, but we're not making a push to make everything a bilingual c/lisp code base. Rust people for some reason are.

One of the most iconic lisp saying is literally about how every other languages are supposedly inferior to lisp, so I don't think it's a particularly good example here.

Yes, the blind stumble down hill eventually. But we let them do it in their own time.

Re: Hard Rust requirements from May onward

#370

Post by ajkjk »

hnthrowaway0315 wrote: post #363

I don't care whether kernel developers want to use C or Rush or whatever. I judge the quality by using it in production. If it works well then I don't care how they are built.

How can you judge the security qualities of software by using it in production? You're surely not using it in the way someone looking for exploits would use it.

Or I guess if you interpret this as a societal scale: we've collectively used C in production a lot, and look at all the security problems. Judgment completed. Quality is low.

Post reply on HN