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

771–780 of 797 posts

Re: Hard Rust requirements from May onward

#771

Post by dataflow »

dralley wrote: post #769
dataflow wrote: post #767

Earlier quoted context omitted.

I don't think they mean stealing in a legal/ownership sense, but stealing in the "I can no longer say this is my project" (control/intellectual/credit) sense. > Why is the "free time" of the original developer more sacrosanct than the "free time" of the re-implementer? This has nothing to do with free time. It has to do with the fact that the former actually went through a ton of pain to get the project from its orig…

Sure, it's upsetting. IBM was upset about BIOS being cloned, Bell got upset about Unix being cloned, Oracle got upset about the JDK being cloned, etc. Many of them were upset enough to engage in decade-long lawsuits. But we'd ultimately be in a much worse place if "avoiding making original creators upset" was the primary factor in development, over things like compatibility, bugs, performance, security etc. I happen…

The difference is in the cases you mention these are massive companies with plenty of money simply trying to protect their revenue streams, whereas here we're talking about open source maintainers that are often doing this for the sake of their love for the project and the users, and getting very little other than recognition or ability to influence the project in return. It's not like you're talking about making a billionaire make a million less than he otherwise would.

Moreover, often these folks have rare expertise in those subjects, and/or rare willingness to work on them as open side projects. If you tell them this is just something they have to deal with, I wouldn't be surprised if you also remove some of the incentives folks have to keep contributing to OSS voluntarily in the first place. Very little money, and massive risk of losing control, recognition, etc. even if you "succeed"... how many people are still going to bother? And then you get shocked, shocked that OSS is losing to proprietary software and dying.

Re: Hard Rust requirements from May onward

#772

Post by dralley »

dataflow wrote: post #771
dralley wrote: post #769

Earlier quoted context omitted.

Sure, it's upsetting. IBM was upset about BIOS being cloned, Bell got upset about Unix being cloned, Oracle got upset about the JDK being cloned, etc. Many of them were upset enough to engage in decade-long lawsuits. But we'd ultimately be in a much worse place if "avoiding making original creators upset" was the primary factor in development, over things like compatibility, bugs, performance, security etc. I happen…

The difference is in the cases you mention these are massive companies with plenty of money simply trying to protect their revenue streams, whereas here we're talking about open source maintainers that are often doing this for the sake of their love for the project and the users, and getting very little other than recognition or ability to influence the project in return. It's not like you're talking about making a b…

The primary benefit of FOSS over proprietary software is, in fact, the ability and willingness to change things and open up changes to a wider pool of developers. Fiefdoms are actively hostile to open source principles. Obviously it's good to treat people with respect but you shouldn't let worse code win out just because of ego alone. Sometimes software gets forked or rewritten and sometimes the fork/rewrite wins out, that's evolution and competition and it keeps the ecosystem healthy.

Re: Hard Rust requirements from May onward

#773

Post by Antibabelic »

dvtkrlbs wrote: post #537
Antibabelic wrote: post #385

Earlier quoted context omitted.

What do you find unapproachable about Ada?

For starter it looks completely alien my real introduction to Ada was with this article comparing it to Rust on solving advent of code [1] but it gives me that feeling when I try to read Haskell code (not that extreme). I did not actually give it a real chance though but its user base even more niche than Rust so idk. It has really cool properties (being able to define n bit datatypes is nice) but it is also leans to…

I wouldn't call it alien. If you've ever written even a little bit of Pascal, you should feel right at home in Ada.

Re: Hard Rust requirements from May onward

#774

Post by lelanthran »

dralley wrote: post #769
dataflow wrote: post #767

Earlier quoted context omitted.

I don't think they mean stealing in a legal/ownership sense, but stealing in the "I can no longer say this is my project" (control/intellectual/credit) sense. > Why is the "free time" of the original developer more sacrosanct than the "free time" of the re-implementer? This has nothing to do with free time. It has to do with the fact that the former actually went through a ton of pain to get the project from its orig…

Sure, it's upsetting. IBM was upset about BIOS being cloned, Bell got upset about Unix being cloned, Oracle got upset about the JDK being cloned, etc. Many of them were upset enough to engage in decade-long lawsuits. But we'd ultimately be in a much worse place if "avoiding making original creators upset" was the primary factor in development, over things like compatibility, bugs, performance, security etc. I happen…

> Sure, it's upsetting. IBM was upset about BIOS being cloned, Bell got upset about Unix being cloned, Oracle got upset about the JDK being cloned, etc.

This is not like that though; moving from a pro-user license to a pro-business license is the reason for being upset, not just losing control over the product.

With the move, any future improvements run the very real risk of being extended then closed off by tech companies.

It's simply hubris for an entire community of developers to look at an existing working product that got popular due to the goal of being pro-user, then say to themselves "we can replace it with this new thing I created, but in order for my new thing to gain traction it must be immediately favourable to big business to close off".

If you view it in that light, then, yeah, you can understand why the upset people are upset, even if you don't agree with them.

> Many of them were upset enough to engage in decade-long lawsuits. But we'd ultimately be in a much worse place if "avoiding making original creators upset" was the primary factor in development, over things like compatibility, bugs, performance, security etc.

Original creators did frequently get upset, but the difference between "some individual forked the code or cloned the product" is very different to "an entire community celebrating a gradual but persistent and constant effort by the same community to move the ecosystem away from a pro-user license".

I hope this gives you some insight into why people are upset, even if you don't agree with them. Most of them aren't articulating it like I did.

[EDIT: I'm thinking of this like an Overton-Window equivalent, shifting from pro-user to pro-business. It seems like an accurate analogy: some people don't want this shift to happen while others are actively pushing for it. This is obviously going to result in conflict.]

Re: Hard Rust requirements from May onward

#775

Post by throwaway7356 »

richard_todd wrote: post #750
throwaway7356 wrote: post #677

Earlier quoted context omitted.

> my point is it would be more sensible to say "I'm going to introduce an oxidized fork of apt and a method to use it as your system apt if you prefer" and then over the next year or so he could say "look at all these great benefits!" (if there are any). At that point, the community could decide that the rust version should become the default because it is so much better/safer/"modern"/whatever. That's not how open s…

ipchains is a perfect representation of what I want to see. They introduced it as an option alongside ipfirewall in 2.1, made it the default but allowed fallback to ipfirewall in 2.2, and removed ipfirewall in 2.4. That is a sane way to introduce a large breaking change. Not to mention they provided compatibility scripts to try to smooth over the user-side differences. They certainly did NOT say "I'm replacing ipfire…

Ah, so the same that seems to be happening here? As https://lists.debian.org/debian-devel/2025/10/msg00288.html says Rust is already a requirement on all but four architectures:

> Rust is already a hard requirement on all Debian release architectures and ports except for alpha, hppa, m68k, and sh4 (which do not provide sqv).

And just like with the kernel the fallback gets removed eventually.

Re: Hard Rust requirements from May onward

#776

Post by zahlman »

zahlman wrote: post #623
teh64 wrote: post #403

Interesting how a person's opinion can change: https://news.ycombinator.com/item?id=27594688

I would much rather work with someone that other people find abrasive but who communicates much like myself and is clearly open-minded, than the opposite.

What do people find objectionable about the above comment? I'm genuinely at a loss.

Re: Hard Rust requirements from May onward

#777

Post by zahlman »

throwaway2037 wrote: post #760
zahlman wrote: post #745

Earlier quoted context omitted.

Ah, of course. I guess this wrapper is provided by Mint.

I am curious: What does the wrapper do? Can you share the source code here?

It appears to re-organize various apt-related commands and sub-commands (including ones provided by additional distro-specific scripts) so that they're all available as sub-commands of `apt`. I don't do much micro-management so I haven't really thought about what the "proper" underlying commands are, except when I've had to look up specific `dpkg` invocations. It's about 200 lines.

Re: Hard Rust requirements from May onward

#779

Post by dralley »

lelanthran wrote: post #774
dralley wrote: post #769

Earlier quoted context omitted.

Sure, it's upsetting. IBM was upset about BIOS being cloned, Bell got upset about Unix being cloned, Oracle got upset about the JDK being cloned, etc. Many of them were upset enough to engage in decade-long lawsuits. But we'd ultimately be in a much worse place if "avoiding making original creators upset" was the primary factor in development, over things like compatibility, bugs, performance, security etc. I happen…

> Sure, it's upsetting. IBM was upset about BIOS being cloned, Bell got upset about Unix being cloned, Oracle got upset about the JDK being cloned, etc. This is not like that though; moving from a pro-user license to a pro-business license is the reason for being upset, not just losing control over the product. With the move, any future improvements run the very real risk of being extended then closed off by tech com…

You're conflating two different things. The purpose of rewriting it is not to change the license. The purpose of rewriting it is to provide a modernized alternative with some benefits from the choice of language -- and the choice of license is incidental.

Kinda like how the purpose of creating LLVM was to create a more extensible compiler framework, not to create a permissively licensed compiler. As it happens the license of LLVM has not really led to the proprietary hellscape that some people suggested it would, and in any case the technical benefits vastly outweigh the drawbacks. Companies like Apple that do have proprietary compilers based on LLVM are difficult to describe as "freeloaders" in practice because they contribute so much back to the project.

Post reply on HN