Upgrade to trixie and enable backports. You'll maybe get the last kernel, MESA, libreoffice, browsers and whatnot without hurting the rest of the system.
What to expect from Debian/Trixie
51–60 of 211 posts
Re: What to expect from Debian/Trixie
#52Earlier quoted context omitted.
You know imaging your machine is still an option...
But you can't do that on a live system as you can with Windows or macOS. Not a problem for pre release upgrade perhaps. But I'm so missing this feature from macOS.
You can if you're using LVM. Take a snapshot of the logical volume your system is on, then run `dd' against the snapshot, as it's essentially a frozen point-in-time.
I've used this trick many times in a live, rw environment.
Re: What to expect from Debian/Trixie
#53Earlier quoted context omitted.
You know imaging your machine is still an option...
But you can't do that on a live system as you can with Windows or macOS. Not a problem for pre release upgrade perhaps. But I'm so missing this feature from macOS.
You can snapshot the filesystem if you're using BTRFS, ZFS, or another Copy-on-Write filesystem.
Re: What to expect from Debian/Trixie
#54Woah Python 3.13 in stable?! (I love Debian) It's going to take a bit for me to get used to having a current version of Python on the system by default.
Probably still good practice to use venv and a python executable version maintainer (uv could be used for both).
Re: What to expect from Debian/Trixie
#55Earlier quoted context omitted.
You know imaging your machine is still an option...
But you can't do that on a live system as you can with Windows or macOS. Not a problem for pre release upgrade perhaps. But I'm so missing this feature from macOS.
Depends on your filesystem. For example, I certainly can as I’m using btrfs. I’m also using Timeshift for easy management of snapshots. As others have mentioned, there are other choices too like Snapper that all work well.
Re: What to expect from Debian/Trixie
#56Debian upgrading Podman to a version above 4.3.1 hopefully also means we get Quadlet support on raspberry pis. Took them forever to add this.
Re: What to expect from Debian/Trixie
#57Earlier quoted context omitted.
It’s why I always say in the typical “systemd bad” threads that systemd the init system is great, it’s the systemd-* everything else’s that give it a bad name. I want systemd nowhere fucking near my NTP or DNS config.
Thank god you can enable and disable each of these components in complete isolation, so you don't suffer any kind of lock-in from systemd.
devuan saved just enough of my sanity for me to function
Re: What to expect from Debian/Trixie
#58Earlier quoted context omitted.
Wait... that means a misbehaving program can cause out of memory errors easily by filling up /tmp? That's a very bad default.
A misbehaving program can cause out of memory errors already by filling up memory. It wouldn't persist past that program's death but the effect is pretty catastrophic on other programs regardless.
That actually is a pretty big difference.
Assuming you're sane and have swap disabled (since there is no way to have a stable system with swap enabled), a program that tries to allocate all memory will quickly get OOM killed and the system will recover quickly.
If /tmp/ fills up your RAM, the system will not recover automatically, and might not even be recoverable by hand without rebooting. That said, systemd-managed daemons using a private /tmp/ in RAM will correctly clear it when killed.
Re: What to expect from Debian/Trixie
#59I've been running Trixie since I bought my Framework laptop last September, and it has been great. First Linux experience after 20 years of Mac, and everything has been incredibly stable. Now I need to figure out what happens when my testing suddenly is stable, and how to get on the next testing, I guess.
There is basically two different configurations. If your `sources.list` is explicitly on Trixie, it will stay there. If it is on testing, then you will get the next testing release in time.
Re: What to expect from Debian/Trixie
#60Can anyone experienced with debian package development, point me to some valid, recent and Best Practice™ guides or blog posts explaining how to package stuff for Debian?
The native Debian package tooling is very far from sane, even compared to other distros - and they actively refuse to make it saner (instead just adding layers of cruft without addressing the core problems). You're probably best off using `checkinstall` or similar, and adding dependencies by hand.