This thing gets everywhere.
APT Rust requirement raises questions
251–260 of 508 posts
Re: APT Rust requirement raises questions
#252I have a dual pentium pro 200 that runs gentoo and openbsd, but rust doesn't ship i586 binaries, only i686+. So I would need to compile on a separate computer to use any software that is using rust. There is already an initrd package tool I can't use since it is rust based, but I don't use initrd on that machine so it is not a problem so far. The computer runs modern linux just fine, I just wish the rust team would a…
This sounds like it's fun. However, I have to ask, why should the linux world cater to supporting 30 year old systems? Just because it scratches an itch?
You can grab a $150 NUC which will run circles around this dual pentium pro system while also using a faction of the power.
You obviously have to do a lot of extra work, including having a second system, just to keep this old system running. More work than it'd take to migrate to a new CPU.
[1] https://www.amazon.com/KAMRUI-AK1PLUS-Processor-Computer-Eth...
Re: APT Rust requirement raises questions
#253Earlier quoted context omitted.
Syntax tends to be deeply personal. I would say the most straightforward answer to your question is "many people disagree that it is unreadable." Rust did build on the learnings of the past 20 years. Essentially all of its syntax was taken from other languages, even lifetimes.
Are the many who disagree that it is unreadable more than the people who agree? I have been involved with the language for a while now, and while I appreciate what you and many others have done for it, the sense that the group is immune to feedback just becomes too palpable too often. That, and the really aggressive PR. Rust is trying to solve a really important problem, and so far it might well be one of the best so…
Rust is almost git hyoe 2.0. That hyoe set the world up with (a) a dominant VCS that is spectacularly bad at almost everything it does compared to its competitors and (b) the dominant Github social network owned by MS that got ripped to train Copilot.
Developers have a way of running with a hyoe that can be quite disturbing and detrimental in the long run. The one difference here is that rust has some solid ideas implemented underneath. But the community proselytizing and throwing non-believers under the bus is quite real.
Re: APT Rust requirement raises questions
#254Earlier quoted context omitted.
Agreed. I think that announcement was unprofessional. This was a unilateral decision affecting other's hard work, and the author didn't provide them the opportunity to provide feedback on the change. It disregards the importance of ports. Even if an architecture isn't widely used, supporting multiple architectures can help reveal bugs in the original implementation that wouldn't otherwise be obvious. This is breaking…
> This is breaking support for multiple ports to rewrite some feature for a tiny security benefit. And doing so on an unacceptably short timeline. Introducing breakage like this is unacceptable. I’m Normally I’d agree, but the ports in question are really quite old and obscure. I don’t think anything would have changed with an even longer timeline. I think the best move would have been to announce deprecation of thos…
Those ports were never official, and so aren't being deprecated. Nothing changes about Debian's support policies with this change.
EDIT: okay so I was slightly too strong: some of them were official as of 2011, but haven't been since then. The main point that this isn't deprecating any supported ports is still accurate.
Re: APT Rust requirement raises questions
#255Maybe there's a place for Future Debian distro that could be a place for phasing out old tech and introducing new features?
Isn't that literally what debian unstable is for?
Re: APT Rust requirement raises questions
#256Earlier quoted context omitted.
If you look at the article, it seems like the hard dependency on Rust is being added for parsing functionality that only Canonical uses: > David Kalnischkies, who is also a major contributor to APT, suggested that if the goal is to reduce bugs, it would be better to remove the code that is used to parse the .deb, .ar, and .tar formats that Klode mentioned from APT entirely. It is only needed for two tools, apt-ftparc…
Mmm, apt-ftparchive is pretty useful for cooking up repos for "in-house" distros (which we certainly thought was serious...) but those tools are already a separate binary package (apt-utils) so factoring them out at the source level wouldn't be particularly troublesome. (I was going to add that there are also nicer tools that have turned up in the last 10 years but the couple of examples I looked at depend on apt-uti…
apt-utils comes from the same top-level source package though:
https://packages.debian.org/source/sid/apt
I know you can make configure-time decisions based on the architecture and ship a leaner apt-utils on a legacy platform, but it's not as obvious as "oh yeah that thing is fully auxiliary and in a totally different codebase".
Re: APT Rust requirement raises questions
#257Earlier quoted context omitted.
I thought the Pentium Pro _was_ a 686? Wikipedia seems to correlate: https://en.wikipedia.org/wiki/Pentium_Pro , as do discussions on CMOV: https://stackoverflow.com/a/4429563
Yes, sorry I remembered incorrectly. The rust compiler claims to be i686 and the CPU is i686 too, but the rust compiler is using Pentium 4 only instructions so it doesn't actually work for i686.
Yeah, that sucks. I assume this is SSE2?
Re: APT Rust requirement raises questions
#258The most interesting criticism / idea in the article was that the parts that are intended for Rust-ification should actually be removed from core apt. > it would be better to remove the code that is used to parse the .deb, .ar, and .tar formats [...] from APT entirely. It is only needed for two tools, apt-ftparchive and apt-extracttemplates [...] Another interesting, although perhaps tangential, criticism was that th…
It seems silly to say that it has no tests. If I had to pick between unit and integration tests, I'd pick integration tests every time.
Re: APT Rust requirement raises questions
#259Earlier quoted context omitted.
> Rust is like a "cleaned-up" C++ Except they got the order of type and variable wrong. That alone is enough reason to never use Rust, Go, TypeScript or any other language that botches such a critical cornerstone of language syntax.
[flagged]
That was needlessly rude.
Re: APT Rust requirement raises questions
#260Earlier quoted context omitted.
I mean, the fact that you mention "probably equivalent" is part of the reality here: Nobody writes the majority of these forms in real code. They are equivalent, by the way. In real code, the only form I've ever seen out of these in the wild is your d form.
This is some True Scotsman style counter argument, and it's hard for me to make a polite reply to it. There are people who program with a "fake it till you make it" approach, cutting and pasting from Stack Overflow, and hoping the compiler errors are enough to fix their mess. Historically, these are the ones your pages/books cater to, and the ones who think the borrow checker is the hard part. It doesn't surprise me…
The issue though is that this isn't a solvable "problem". This is how programming languages' syntax work. It's like saying that C's if syntax is bad because these are equivalent:
if (x > y) {
if ((x > y)) {
if (((x) > (y))) {