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

151–160 of 428 posts

Re: Debian 13 “Trixie”

#151

Post by lucb1e »

juujian wrote: post #45

I have been using Debian Trixie for a few months in testing now, I can attest that its a great, stable operating system. Definitely better than Ubuntu in terms of user experience.

The only complaint on a fresh install is that Cinnamon seems to use a ton of CPU when there's a little moving thingy anywhere on the screen (a browser tab that has a loading icon in the tab list is sufficient). This is most noticeable when you have a VM without graphics acceleration (don't ask why in the world my job requires that). Graphics without acceleration is always heavy, but this is an extra process doing whatever on top of the actual load

Then my private laptop has had a bunch of graphic issues after upgrading to 13 (it manifests differently in a lot of applications and it changes when you pick a different desktop theme, not even sure how to describe it). The new pipewire (pulseaudio replacement, idk why that needed replacing) does not work properly when the CPU is busy (so I currently play games without game sounds or music in the background). The latter then also sometimes (1 in 5 times maybe?) crashes when resuming from suspend, but instead of dying, spams systemd which diligently stores it all in a shitty binary file (that you can't selectively prune), runs completely out of disk space, and breaks various things on the rest of the system until you restart the pipewire process and purge any and all logs (remember, no selective pruning)... Tried various things I found in web searches and threw an LLM at it as well, but no dice. I assume these issues are from it not being a fresh install, so no blame/complaint here really, just annoying and I haven't had these issues when doing previous upgrades. Not yet sure how to resolve, perhaps I'll end up doing a completely new install and seeing what configs I can port until issues start showing up

Surely these things are not a Debian-specific issue, but I haven't noticed something like that with either 11 or 12

Edit: oh yeah, and the /tmp(fs) counter is at 1 so far. I wonder how many times I'll have run out of RAM by Debian 14, by forgetting I can't just dump temporary files into /tmp anymore without estimating the size correctly beforehand

Re: Debian 13 “Trixie”

#152

Post by rbanffy »

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…

The only thing I can say against Debian is that it tends to start new server software immediately after install, before I have a chance to configure it properly. Defaults are sane for most packages, but, still, it scares me a little. In that I like the Red Hat approach of installing and leaving it off until I decide to turn it on.

Re: Debian 13 “Trixie”

#153

Post by foresto »

b112 wrote: post #14

You can still use sysvinit, I've already tested servers and desktop builds. From my build box: chroot $MOUNTPOINT/ /bin/bash -c "http_proxy=$aptproxy apt-get -y --purge --allow remove-essential install sysvinit-core sysvinit-utils systemd-sysv- systemd-" There is a weird depends you cannot get around without simultaneously removing and installing in parallel. A Debian bug highlighted the above, with a "-" for systemd…

Thank you for sharing this. I'm inclined to adopt it in my lxc containers, at least.

Re: Debian 13 “Trixie”

#154

Post by RVuRnvbM2e »

b112 wrote: post #14

You can still use sysvinit, I've already tested servers and desktop builds. From my build box: chroot $MOUNTPOINT/ /bin/bash -c "http_proxy=$aptproxy apt-get -y --purge --allow remove-essential install sysvinit-core sysvinit-utils systemd-sysv- systemd-" There is a weird depends you cannot get around without simultaneously removing and installing in parallel. A Debian bug highlighted the above, with a "-" for systemd…

Why would you want to do this?

Re: Debian 13 “Trixie”

#155

Post by dismalaf »

type0 wrote: post #133
Santosh83 wrote: post #75

Earlier quoted context omitted.

Snaps per se are no better or worse than flatpak. Canonical's mistake, IMO, was to make their store the only place snaps can be hosted. That is the "proprietary" bit everyone keeps talking about. But in practice even for flatpak the only realistic place you can publish your flatpak if you want any traction at all would be flathub, so both formats have only one store right now. But flatpak allows a custom store while…

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

Re: Debian 13 “Trixie”

#156

Post by herewulf »

progval wrote: post #110
michaelt wrote: post #99

Earlier quoted context omitted.

My Linux machine is very modern, but I still need i386 architecture support installed, because Steam requires 32-bit support. And Steam requires 32-bit support so people can play 15-year-old games. (Admittedly, the 32-bit support Ubuntu ships is less than a full OS and you can't install Ubuntu on a 32-bit machine these days)

So you have an amd64 CPU and Debian's "i386" packages will keep working on it. As per the release notes: > The i386 architecture is now only intended to be used on a 64-bit (amd64) CPU.

Maybe it's one of those games that runs too fast if the CPU isn't clocked at 33 MHz. ;)

It would probably take a few days to start Steam on one of those considering its load times on current hardware.

Re: Debian 13 “Trixie”

#157

Post by ndiddy »

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 service) that will alert both the owner and IBM if they detect some sort of hardware fault. IBM has supported Linux as a first-class OS option for their mainframes since the early 2000s.

From a developer perspective, s390x is also the last active big-endian architecture (I guess there's SPARC as well, but that's on life support and Oracle doesn't care about anyone running anything but Solaris on it), so it's useful for picking up endianness bugs.

Another interesting thing is that the only two 32-bit architectures left supported are armel and armhf. Debian has already announced that this will be the last release that supports armel (https://www.debian.org/releases/trixie/release-notes/issues....), so I guess it'll be a matter of time before they drop 32-bit support altogether.

Re: Debian 13 “Trixie”

#158

Post by foresto »

b112 wrote: post #48

For those worrying about the NIC change with systemd, this comes from the release doc: https://www.debian.org/releases/trixie/release-notes/issues.... # example: udevadm test-builtin net_setup_link /sys/class/net/eno4 2>/dev/null ID_NET_LINK_FILE=/usr/lib/systemd/network/99-default.link ID_NET_LINK_FILE_DROPINS= ID_NET_NAME=eno4 Here's a one-liner, excluding a bond interface and lo. Gives a nice list of pre and post…

Do you happen to know if this change can affect people who have disabled systemd's Predictable* Network Interface Names before upgrading to Trixie?

*haha

Re: Debian 13 “Trixie”

#159

Post by dismalaf »

I've kind of been using Debian 13 for awhile now (I'm on Unstable) and for me what's impressive is how polished a default Debian installation is these days. With Gnome, you literally can run it as is, no config needed. It just works.

That being said, I like Flatpak, so I installed it (was super easy and Flathub provides instructions), and I added a few Gnome Shell extensions (a Dock so my wife can find apps when she occasionally uses my laptop).

Debian gives you a feeling of ownership of your computer in a way the corporate distros don't, but is still pretty user friendly (unlike Arch).

I'd definitely install Debian Stable on a grandparents' computer.

Re: Debian 13 “Trixie”

#160

Post by foresto »

ACS_Solver wrote: post #119
kachapopopow wrote: post #80

Plasma 6.3 - I can finally ditch kde neon.

Not if you want to remain on new Plasma, you can expect Debian to lag several minor versions behind. I've found it pretty easy though to use some KDE components built from source on top of the standard Debian packages. Build with kdesrc-build, then have those binaries linked to from your ~/bin and you're set. It might get difficult if you want to rebuild some key components like plasmashell itself but I've been using…

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

Post reply on HN