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

Debian 13 “Trixie”

debian.org

Post reply on HN
Print view View original

361–370 of 428 posts

Re: Debian 13 “Trixie”

#361

Post by MuffinFlavored »

morserer wrote: post #274

They only mentioned it briefly, and not by number, but this release includes 95%+ bit-for-bit reproducibility on AMD64, ARM64, and RISC-V across more than 30,000 packages (92% mean across all architectures). Congratulations to the team--phenomenal work! https://reproduce.debian.net/

Could you help me understand why the remaining 5% is not bit-for-bit reproducible? For example... if you download a tar of sources pinned to a version, and you run `./configure` and `make` in some kind of container and it doesn't embed some kind of timestamp... why are 95% reproducible and some aren't? Would like to learn/understand.

Re: Debian 13 “Trixie”

#362

Post by MuffinFlavored »

zahlman wrote: post #330
jjgreen wrote: post #307

I've been on Debian forever and love it to bits. But in an act which can only be described as batshit insanity, they have chosen to patch Python's pip3 in a manner which breaks the --prefix option. On Debian pip3 install --prefix=/usr/local will install into /usr/local/local, so one has to use the prefix /usr. The same command on, say, OpenSuSE will install into /usr and break your system. Barking mad. https://source…

> python3.7 Certainly a terrible UX, but the motivation is clear: they're trying to get PEP 668 protections for older versions. Virtual environments work a lot better anyway, honestly. (With a properly crafted `pyvenv.cfg`, it should be possible to convince Python that your /usr/local is a virtual environment, but I can't be sure offhand if there are any serious negative consequences of that.)

python3.7 is from June 27th, 2018

https://www.python.org/downloads/release/python-370/

Why is that the default?

Re: Debian 13 “Trixie”

#363

Post by JonChesterfield »

MuffinFlavored wrote: post #361
morserer wrote: post #274

They only mentioned it briefly, and not by number, but this release includes 95%+ bit-for-bit reproducibility on AMD64, ARM64, and RISC-V across more than 30,000 packages (92% mean across all architectures). Congratulations to the team--phenomenal work! https://reproduce.debian.net/

Could you help me understand why the remaining 5% is not bit-for-bit reproducible? For example... if you download a tar of sources pinned to a version, and you run `./configure` and `make` in some kind of container and it doesn't embed some kind of timestamp... why are 95% reproducible and some aren't? Would like to learn/understand.

Hashtables keyed off the address of objects would be an example.

On multiple runs, malloc gives out different addresses (thanks to threads or security concerns) which means things end up in different slots in the table. Then you iterate through it in memory order and you're seeing objects in non-deterministic order, which you do things with.

Embedding file paths / timestamps / git shas and similar was popular for a while too and unhelpful for reproducible builds.

Re: Debian 13 “Trixie”

#364

Post by zahlman »

MuffinFlavored wrote: post #362
zahlman wrote: post #330

Earlier quoted context omitted.

> python3.7 Certainly a terrible UX, but the motivation is clear: they're trying to get PEP 668 protections for older versions. Virtual environments work a lot better anyway, honestly. (With a properly crafted `pyvenv.cfg`, it should be possible to convince Python that your /usr/local is a virtual environment, but I can't be sure offhand if there are any serious negative consequences of that.)

python3.7 is from June 27th, 2018 https://www.python.org/downloads/release/python-370/ Why is that the default?

I don't think it is? Or at least, it only was on some particular older Debian release.

Re: Debian 13 “Trixie”

#365

Post by kachapopopow »

jpetso wrote: post #192
foresto wrote: post #160

Earlier quoted context omitted.

> you can expect Debian to lag several minor versions behind. Not necessarily forever, though. Bookworm got minor Plasma updates, so I wouldn't be surprised if Trixie does as well.

Bookworm stayed on Plasma 5.27.5 when Plasma shipped bugfix releases up to 5.27.12. Debian may have cherry-picked a handful of patches from there, but that's a lot of bugfixes missed on a release that was already super old. Even at this point, Plasma 6.4 has been out for almost two months and 6.3 will not get any more updates ever. While everyone else is upgrading, Debian is going to be stuck on an already unsupporte…

I am more than happy to say on Plasma 6.3 instead of hopping between versions where dragging files into a browser works and next update it doesn't.

Re: Debian 13 “Trixie”

#366

Post by creatonez »

kasabali wrote: post #345
creatonez wrote: post #285

Earlier quoted context omitted.

Why do you think this is an attempt at a persuasion tactic? Taint flags in this context just means something that might be relevant to debugging. Which this condition might be, if people in the future are unfamiliar with a potentially anachronistic split between /usr/bin and /usr/sbin. The debug message isn't there to judge the morality of your configuration. It's actively improving your ability to continue to suppor…

> Why do you think this is an attempt at a persuasion tactic Because they said so: > As part of that we sometimes adopt schemes that were previously used by only one of the distributions and push it to a level where it's the default of systemd, trying to gently push everybody towards the same set of basic configuration [1] 1. https://0pointer.de/blog/projects/the-biggest-myths.html

This was written 11 years before that debug log was added. Extremely loose connection. Things do actually change over the course of 11 years, believe it or not.

Re: Debian 13 “Trixie”

#367

Post by [deleted] »

jraph wrote: post #357
StopDisinfo910 wrote: post #344

Earlier quoted context omitted.

> As a result the Debian-ized version of ntfy doesn't contain a web app (which is a reaaal bummer), and has a few things "patched out" (which is fine). My advise to you is to deny all support from people using the Debian version of your software and automatically close all bug tickets from Debian saying you don’t support externally patched software. You would be far from the first to do so and it’s a completely ratio…

I agree that maintainers should not be expected to support patched versions of their software, but as a user I like the Debian policies you call insane. I would actually pick Debian exactly because they are cautious with the dependencies.

[deleted]

Re: Debian 13 “Trixie”

#368

Post by pabs3 »

zozbot234 wrote: post #294
pabs3 wrote: post #243

Earlier quoted context omitted.

In case anyone wants to do that, here is the doc for new ports: https://wiki.debian.org/PortsDocs/New

Much of that information has to do with creating a new hardware port from scratch. The i386 support just needs to be "demoted" to the Debian ports infrastructure once it's officially scheduled to get dropped from the main Debian repository (which could well happen starting either in Debian forky or duke), and this can probably be done with some special handling. (Answering the "to what end?" question, a lot of 32bit-…

Well, the existing i386 port is going to remain as-is for supporting old software (especially games) (but the CPU baseline will likely get increased), it isn't going to be removed, so you would need a new architecture for 32bit-only hardware.

Since i386 is not going to do the 2038 transition either (since that would break the ABI), also you would need to either make a new ABI for the new port, or do the 2038 transition for it too.

Over time more and more 32-bit bugs will get introduced, so there will be lots of maintenance work to do too.

Re: Debian 13 “Trixie”

#369

Post by solatic »

ndiddy wrote: post #157
yonatan8070 wrote: post #63

A total of seven architectures are officially supported for "trixie": "trixie" 64-bit PC (amd64), 64-bit ARM (arm64), ARM EABI (armel), ARMv7 (EABI hard-float ABI, armhf), 64-bit little-endian PowerPC (ppc64el), 64-bit little-endian RISC-V (riscv64), IBM System z (s390x) It's good to see RISC-V becoming a first-class citizen, despite the general lack of hardware using it at the moment. I do wonder, where are PowerPC…

Mainframes are still holding on in use cases where a single server having continuous uptime is vital. They're designed to have uptime measured in decades, so even components like the processors and main memory have hot spares available and can be hot-swapped without interrupting the OS or running services. They also have continually running system monitoring and diagnostics at the hardware level (not running as an OS…

Yeah, mainframes are all about cases where the uptime is critical. Most modern systems are good with offering 99.9% or 99.99% reliability, with the understanding that trying to offer more than that just gets more and more expensive. Well... spending huge amounts of money on mainframes is one of the strategies to get to reliability numbers like 99.9999999%.

Source: https://itic-corp.com/itic-2023-reliability-survey-ibm-z-res...

The legitimate usage is typically for workloads like relational databases (which are anyway single-machine architectures) that experience heavy load 24/7, part of fragile architectures that cannot tolerate downtime (remaining fragile as such because the original source code has been lost etc.), where "the system is down" causes tens of thousands if not hundreds of thousands of people to stop work.

Re: Debian 13 “Trixie”

#370

Post by pabs3 »

wltr wrote: post #313
pabs3 wrote: post #270

Earlier quoted context omitted.

They are linked from the "Other downloads" page linked from the front page.

Yeah, I think I remember that, but each time I’m puzzled and not sure. It feels like they hid that deliberately. While Arch is the opposite, it’s so easy to get the torrent file.

Yeah, it was deliberate, to make it easy for most people, who will only want the netinst download.
Post reply on HN