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

241–250 of 428 posts

Re: Debian 13 “Trixie”

#241

Post by pabs3 »

b112 wrote: post #177
raggi wrote: post #136

Earlier quoted context omitted.

LTS has had major breaking changes in various areas in recent times too, virtio was badly broken at one point this year, as was a commonly used netlink interface. Hat tip to the Arch kernel contributors who helped track this down and chase upstream, as we had mutually affected users. The debian and ubuntu bug trackers were a wasteland of silence and user contributions throughout the situation, and frustratingly conti…

Bear in mind, LTS and ELTS are not Debian maintained. The wiki has more info on this.

The folks behind Debian LTS and Freexian ELTS are all Debian members/contributors, and the Debian LTS changes end up in the Debian archive, while the Freexian ELTS ones are publicly available, just in an external archive.

https://wiki.debian.org/LTS https://wiki.debian.org/LTS/Team https://wiki.debian.org/LTS/Funding https://wiki.debian.org/LTS/Extended

Re: Debian 13 “Trixie”

#243

Post by pabs3 »

zozbot234 wrote: post #22
accrual wrote: post #17

> i386 is no longer supported as a regular architecture: there is no official kernel and no Debian installer for i386 systems. The i386 architecture is now only intended to be used on a 64-bit (amd64) CPU. Users running i386 systems should not upgrade to trixie. Instead, Debian recommends either reinstalling them as amd64, where possible, or retiring the hardware. Impressive that i386 support made it all the way to A…

Hopefully i386 (or perhaps a new i386-like port with added support for 64-bit time values) can move to the unofficial Debian Ports infrastructure for Debian 14 (forky) or Debian 15 (duke). Debian Ports has a m68k port, so supporting one for i386 shouldn't be a huge problem.

In case anyone wants to do that, here is the doc for new ports:

https://wiki.debian.org/PortsDocs/New

Re: Debian 13 “Trixie”

#244

Post by pabs3 »

b112 wrote: post #178
abhinavk wrote: post #47

Earlier quoted context omitted.

Buster is supported until June 2028.

Not by Debian it isn't. https://www.debian.org/releases/ Buster has not been supported by Debian for many years. Buster LTS was EOL last summer. Note that LTS is supported by volunteers via a non-profit, not Debian (though they do a good job). ELTS is paid support, again not by Debian. Do look at Debian's wiki for more info on support timeframes, and what LTS and ELTS means.

Freexian is for-profit, and all the LTS/ELTS contributors are Debian maintainers, and LTS is part of Debian, while ELTS is publicly available too, but in an external archive.

https://wiki.debian.org/LTS https://wiki.debian.org/LTS/Team https://wiki.debian.org/LTS/Extended https://wiki.debian.org/LTS/Funding

Re: Debian 13 “Trixie”

#245

Post by pabs3 »

Palomides wrote: post #143
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…

IBM puts a lot of work and money into making sure open source stuff runs properly on those two, even if they aren't that popular them being kept by major distros is therefore not as "natural" as other architectures

For Debian s390x (IBM Z), they only employ two people to work on the port, which isn't really enough. I think ppc64el has even less people.

Re: Debian 13 “Trixie”

#246

Post by anthk »

I used to like Debian when configuring ALSA/OSS, XFree86 and such was a source of nightmares. Thus, debconf as a middle layer mechanism to handle several distinct architectures, setups and hardware was a neccesity. Ditto with Yast2 on SuSE. By 2004-2005... not much.

Even a bare Slackware with KDE and KDEi (and even XFCE) can do tons of work by itself by just adding an user and accepting the default group belonging array by pressing 'up' at the prompt.

Heck, even OpenBSD, minus the volume automount, which can be handled in a breeze with toadd or tray-app in seconds; and if you are smart you can figure DBUS/FDo mount points and integrate then with XFCE/Plasma/Gnome without too much issues (hotplugd can handle device umounting if you set up doas.conf accordinly).

The rest? MESA and X.org will handle most of the graphics stuff. Video and audio drivers are autodetected on almost every GNU and *BSD. Printers are often wireless bound so any assistant with look it up fast and attach it to CUPS.

Still, I can't handle DPKG/APT's slowness, even if there are libre distros as Trisquel with it. If they rebased their distro as a simpler Parabola LTS release with either Mate or LXDE setups, the user experience would be almost the same, but installing packages would happen at a much faster pace.

Re: Debian 13 “Trixie”

#247

Post by jabl »

yjftsjthsd-h wrote: post #187
Narishma wrote: post #74

> Users running i386 systems should not upgrade to trixie. Instead, Debian recommends either reinstalling them as amd64, where possible, or retiring the hardware. What I did is switch to NetBSD.

In the abstract I'm a big fan of supporting me old machines forever, but I have to ask out of curiosity - what hardware is practical to run these days and only has a 32-bit processor?

I tried to repurpose an old laptop I had lying around as a "lie on the couch and surf the web or watch youtube" machine. It was one of the last 32-bit only cpus (pentium m), so I installed Debian bookworm (12) on it. Unfortunately it turned out it couldn't even play youtube videos at 144p without stuttering. So I E-wasted the machine.

I suppose as some kind of headless home server it could still have been useful. OTOH for something that runs 24/7 a RPi would use a fraction of the electricity and still be a lot more powerful.

So yes, beyond nostalgia and some embedded/industrial usecases, it's hard to see a use for a 32-bit only PC these days.

Re: Debian 13 “Trixie”

#248

Post by spookie »

int_19h wrote: post #213

I see that systemd is still doing this thing where they are trying to strong-arm all Linux distros into arbitrary stuff that someone decided is the only right way to do something: > 5.2.2. systemd message: System is tainted: unmerged-bin systemd upstream, since version 256, considers systems having separate /usr/bin and /usr/sbin directories noteworthy. At startup systemd emits a message to record this fact: System…

Lovely.

Re: Debian 13 “Trixie”

#249

Post by kasabali »

Arnavion wrote: post #234
int_19h wrote: post #213

I see that systemd is still doing this thing where they are trying to strong-arm all Linux distros into arbitrary stuff that someone decided is the only right way to do something: > 5.2.2. systemd message: System is tainted: unmerged-bin systemd upstream, since version 256, considers systems having separate /usr/bin and /usr/sbin directories noteworthy. At startup systemd emits a message to record this fact: System…

>No option to disable this either, per discussion in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085370 The discussion in that bug is that the Debian maintainer (and upstream dev) is open to an upstream patch to add such an option.

> Debian maintainer (and upstream dev) is open to an upstream patch to add such an option

Wild interpretation right here.

There are only 2 realistic choices: Leave it as is or patch out the warning message in the Debian package

Debian maintainer is clearly deflecting the responsibility here because everyone knows very well that upstream wouldn't accept such a patch.

As it's already explained in the bug report, since Debian has no plan to do that migration in the near future, aforementioned warning isn't only useless and annoying, it's also potentially harmful, thus the correct action would be to remove it downstream like they did it in xscreensaver (https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819703#84)

But then they'd face the wrath of Lennart, so the only choice left is ignoring the report.

Post reply on HN