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

781–790 of 797 posts

Re: Hard Rust requirements from May onward

#781

Post by lelanthran »

dralley wrote: post #779
lelanthran wrote: post #774

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. 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 li…

> The purpose of rewriting it is not to change the license.

I didn't say it was.

> The purpose of rewriting it is to provide a modernized alternative with some benefits from the choice of language

I did not contend that either.

> and the choice of license is incidental.

This I disagree with - the license choice is not incidental; it is foundational to gain popularity in a hurry, to gain widespread adoption at corporates.

The rewriter's intentions is to gain popularity over the incumbent software; using a pro-user license does not gain popularity for all those pro-business use-cases.

The license switch from pro-user to pro-business is not incidental. It's deliberate, and it's too achieve the stated goal of replacing the existing software.

This is one place where I feel that the ends do not justify the means.

Re: Hard Rust requirements from May onward

#782

Post by mike_d »

zahlman wrote: post #732
kees99 wrote: post #704

Earlier quoted context omitted.

> Please show me a project where you believe you "effectively require containers" just to run the code I guess GP meant "containers" broadly, including things like pipx, venv, or uv. Those are, effectively, required since PEP 668: https://stackoverflow.com/questions/75608323/how-do-i-solve-...

> "containers" broadly, including things like pipx, venv, or uv. This statement makes no sense. First off, those are three separate tools , which do entirely different things . The sort of "container" you seem to have in mind is a virtual environment . The standard library `venv` module provides the base-line support to create them. But there is really hardly anything to them. The required components are literally a…

> This statement makes no sense. First off, those are three separate tools, which do entirely different things.

They are all various attempts at solving the same fundamental problem, which I broadly referred to as containerization (dependency isolation between applications). I avoided using the term "virtual environment" because I was not referring to venv exclusively.

Re: Hard Rust requirements from May onward

#784

Post by fweimer »

zahlman wrote: post #608
fweimer wrote: post #422

Earlier quoted context omitted.

The Debian base system is much, much smaller. I'm surprised that people consider Python to be part of it. However, APT depends on Perl and the C++ run-time library, so those two languages have been part of the base system for a very long time.

> I'm surprised that people consider Python to be part of it. However, APT depends on Perl Pardon? $ file `which apt` /usr/local/bin/apt: Python script, ASCII text executable

Sorry, I meant that something in the package management stack depends on Perl (not APT specifically).

It looks like in trixie, it's libpam-modules that pulls in debconf, which is written in Perl. And libpam-modules is required by util-linux, which is Essential: yes.

Re: Hard Rust requirements from May onward

#785

Post by dvtkrlbs »

Antibabelic wrote: post #773
dvtkrlbs wrote: post #537

Earlier quoted context omitted.

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.

I never wrote a line of Pascal :/

Re: Hard Rust requirements from May onward

#786

Post by richard_todd »

throwaway7356 wrote: post #775
richard_todd wrote: post #750

Earlier quoted context omitted.

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.

If you think a situation where everyone had access to ipchains for 3 years to figure out how to migrate is similar to a situation where some architectures will be killed in six months without ever having had access to the new product then I don't know how to help you. What can affected ports do? Implementing a toolchain backend is a tall order.

We didn't talk about your gcc-to-c++ example, but if you read up on it you will know they took the pulse of affected developers, started experimental branches, made presentations, and made sure no architectures were left behind. All of which this Debian developer is failing to do.

Look I don't even disagree with the ultimate result... I don't think Debian needs to indefinitely support every strange port it has built up over the years. The way it's being done, though, doesn't sit right. There are far more mature ways to steer a big ship. Your own examples are showing the way.

Re: Hard Rust requirements from May onward

#787

Post by nialv7 »

steveklabnik wrote: post #619
nialv7 wrote: post #548

Didn't they call Rust software "unpackageable" just a couple of months ago? IIRC they were talking about bcachefs-tools.

Debian has packaged rustc and Rust based programs for the better part of a decade now.

It was posted on Hacker News... https://news.ycombinator.com/item?id=41407768

Author quite literally said bcachefs-tools "is impossible to maintain in Debian stable", and the reason cited was Rust.

Re: Hard Rust requirements from May onward

#788

Post by dokyun »

jodrellblank wrote: post #728
dokyun wrote: post #695

Earlier quoted context omitted.

Oh wow a replacement for a tool I already have. It's slightly faster, even if I seldom ever worry about its speed. Who cares?

57000 people who have starred its repository on Github care. More evidence than you have provided for your claim "Rust isn't delivering value", what did you use to come to that conclusion?

It's a toy. Cool project, but it's a replacement for something that already exists and does its job well. All it demonstrates is "we micro-optimized our libraries more than GNU". It doesn't say anything about the advantages of Rust itself.

Re: Hard Rust requirements from May onward

#789

Post by steveklabnik »

nialv7 wrote: post #787
steveklabnik wrote: post #619

Earlier quoted context omitted.

Debian has packaged rustc and Rust based programs for the better part of a decade now.

It was posted on Hacker News... https://news.ycombinator.com/item?id=41407768 Author quite literally said bcachefs-tools "is impossible to maintain in Debian stable", and the reason cited was Rust.

One person said one program is hard to package, sure.

That doesn’t change that both rustc and programs that use rust have been packaged for a very, very long time.

Re: Hard Rust requirements from May onward

#790

Post by larusso »

burntsushi wrote: post #763
larusso wrote: post #747

Earlier quoted context omitted.

Yes but GNU to put them under GPL. Or that was my understanding.

So then your original comment should be amended to say, "and this is actually all fine when the authors use a license I personally like." So it's not actually the rewriting you don't like, but the licensing choices. Which you completely left out of your commentary. You also didn't respond to my other rebuttal, which points out a number of counter-examples to your claim. From my view, your argument seems very weak. Yo…

Sorry I didn’t response by intention. The thing with the license I actually didn’t bring up because I totally forgot about this part of the discussion. I saw comments a few weeks back going into the fact that it’s not just a rust rewrite but also a relicense with maybe shady intend. I don’t know. I don’t know much about this. To your comment. I don’t know when I actually did any claims? Nor did I claim that a rewrite is fine when it’s changing to a license I like. Just stated that the reason back then was not to rewrite in a more modern language with better security. I wasn’t around when this happened and have no real thought if at the time I would have like or dislike the move. As it’s stands the net positive was obviously great otherwise a Linux as we know it might have been longer in the making. Or never. And yes my argument is weak because I’m actually not an expert on core utility development. I voiced just my feelings about the fact that we seem to move slowly forward or stand still in development rather than progressing to something else. And it seems that others see it differently and or have a better perspective on that.
Post reply on HN