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

281–290 of 428 posts

Re: Debian 13 “Trixie”

#281

Post by spauldo »

esaym wrote: post #96
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…

Are you confusing "386" with 32bit? 686 is the normal 32bit arch. 386 is something from the 1980's right?

Linux ran fine on 386 chips - that was actually what it was originally developed on. But Intel added a bunch of functionality in the 486, Pentium, and Pentium Pro chips. At some point the powers that be didn't see any value in continuing to support pre-P6 chips anymore.

It was a bit of a strange decision since there were undoubtedly more 386, 486, and Pentium users than some of the platforms Linux continued to support, but that's the choice they made. But they weren't alone. Even NetBSD requires a 486DX or better.

Re: Debian 13 “Trixie”

#282

Post by spauldo »

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…

OpenBSD requires at least a Pentium these days.

Re: Debian 13 “Trixie”

#284

Post by npteljes »

dismalaf wrote: post #155
type0 wrote: post #133

Earlier quoted context omitted.

If you are making your own distro, creating your own flatpak store is trivial, that's all what matters. Linux Mint doesn't use snap exactly because Canonical forces everyone to use their snap store.

Canonical doesn't force anyone to use anything. Snap is open source, just modify it to use a different store if you want. Mint literally forked a zombie DE, but changing a few lines of code in snap is an issue...

Defaults matter a lot, snap is not open source (client is, backend isn't), you cannot "just modify it (Ubuntu)" to use a different store, because Ubuntu installs snaps even with apt. Mint is not part of the discussion.

Re: Debian 13 “Trixie”

#285

Post by creatonez »

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…

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 support both ways, by properly indicating what style of system it is for troubleshooting purposes.

Re: Debian 13 “Trixie”

#286

Post by npteljes »

sofixa wrote: post #150
npteljes wrote: post #65

Earlier quoted context omitted.

Defaults matter a lot, and snaps are the default in Ubuntu. The topic is not whether snaps are avoidable or not, but the Ubuntu is going downhill. And snaps are purported to be part of that downhill, which would be Ubuntu's NIH syndrome. As far as I know, Ubuntu's only successful development is Ubuntu itself - the other projects have all failed over the years, and snap, while ongoing, is not winning any popularity co…

> which would be Ubuntu's NIH syndrome Red Hat do the same. They reinvented the wheel on multiple occasions (systemd and it's whole ecosystem like systemd-resolved and timed and the whole kitchen sink; podman, buildah, dnf, etc etc.) They just have more success on getting their NIH babies accepted as the standard by everyone else. Canonical just fail at that (often for good reasons, Unity was downright crap for some…

>They just have more success on getting their NIH babies accepted as the standard by everyone else.

This depends on the phrasing. We could also say that Red Hat produces actually useful software, in contrast with Canonical, whose developments don't seem to provide value over existing solutions.

We could also say that Canonical tries really hard to do exactly what Red Hat does, but in a slightly different space, and not very successfully.

Re: Debian 13 “Trixie”

#287

Post by dotancohen »

throwaway81523 wrote: post #265
ACS_Solver wrote: post #25

Writing this from my Debian system, it's a great distro that has been excellent to me as a daily driver. I switched to Debian 6 after Ubuntu went way downhill and haven't had cause to regret it. I like Debian's measured pragmatism with ideology, how it's a distro of free software by default but it also makes it easy to install non-free software or firmware blobs. I like Debian's package guidelines, I like dpkg, I lik…

You weren't around for when they broke the OpenSSL random number generator for no good reason. That was back in 2008 and it created vulnerabilities that persist to this day. https://16years.secvuln.info/ I still use Debian but it's hard to forget stuff like that even after all these years.

Though I agree with you, if that's the bar you're setting then Debian comes out far ahead of any other OS that I've ever used - Linux based or not. I can recall dozens of worse Windows bugs, most of which did not even affect me because I was not using Windows at the time. Mac has its share too.

Re: Debian 13 “Trixie”

#288

Post by spauldo »

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…

There are options if you're willing to put in the work and run the risk of breaking things.

You can always not install QT or KDE packages and compile your desktop from source. It's a major pain in the ass but I did it for years. A side benefit is you can participate in testing and interact with KDE developers directly.

Another option is to go all FrankenUNIX and add neon sources to your apt cache. I've done similar but I don't recommend it.

Or you can just run unstable. Lots of people do. I did for a long time, and as long as you're willing to fix the package system occasionally it's not a bad experience. Certainly better than the two previous options.

Re: Debian 13 “Trixie”

#289

Post by guerby »

brirec wrote: post #122
madars wrote: post #93

Earlier quoted context omitted.

>I've never had a Debian system break without it being my fault in some way. Debian is great but I can't say this is a shared experience. In particular, I've been bitten by Debian's heavy patching of kernel in Debian stable (specifically, backport regressions in the fast-moving DRM subsystem leading to hard-to-debug crashes), despite Debian releases technically having the "same" kernel for a duration of a release. In…

These days all of my “Debian” bare metal systems are technically running Proxmox, which I think is a relatively happy medium as far as the base Debian system goes — the Proxmox kernel is basically the Ubuntu kernel, but otherwise it’s a pretty standard Debian system. I’ve thought about (ab)using a Proxmox repository on an otherwise stock Debian system before just for the kernel…

Same at $work all physical servers run proxmox VE (by policy), 90% of VMs are debian (cloudinit genericcloud), the rest misc linux and various windows.

Re: Debian 13 “Trixie”

#290

Post by spauldo »

bryanlarsen wrote: post #39
superkuh wrote: post #6

Biggest change for me is /tmp behavior. In Debian 13 /tmp become RAM-disk by default (instead of files on the file system) and uses up to 50% of available ram. But as expected of Debian the release notes included an easy fix to restore normal /tmp behavior for people and applications that place many small or large files there. https://www.debian.org/releases/trixie/release-notes/issues.... >"You can return to /tmp be…

Infinite scroll length on terminals can chew through /tmp, and systems misbehave strangely when they're out of /tmp.

What terminal emulators default to infinite backscrolling? Genuinely curious here. I've used xterm with a scroll buffer of 512 lines for three decades now and outside of large builds I can't imagine wanting more than that.
Post reply on HN