What to expect from Debian/Trixie
michael-prokop.at
michael-prokop.at
It's been what I expect from Debian: boring and functional. I've never run into an issue where the system wouldn't boot after an update (I usually update once every 2-4 weeks when on testing), and for the most part everything has worked without the need to fix broken packages or utter magic apt incantations.
Debian has always been very impressive to me. They're certainly not perfect, but what they can do based on volunteers, donations, and sponsors, is amazing.
If I need newer software that isn't in their package repository, I understand that I have the ability to compile what I need, or at least make an active decision to modify my system to run what I want. Basically, the possibility of instability is a conscious choice for me, which I do sometimes take.
I just need boring stability to wildly experiment in isolation
I haven't run into a scenario where the desktop has caused me issues, only with Windows-only software that I sometimes require. What software has caused you issues that doesn't play nicely with Debian? What hacks are in place to mitigate upstream issues? I'm honestly curious, and if you don't use Debian, what distribution do you use regularly?
At work I usually have to spend 6 hours per day to fix random Ubuntu issues on code which works fine on Fedora. Usually Ubuntu 20 and 22.
That's some hyperbole. If I spent 6 hours a day fixing some distro's issues, that would be my whole job. I would begin questioning whether I'm "holding it wrong" or if it is the wrong tool for the job.
I also left Ubuntu because of their shenanigans, but if your code cannot run on Debian, your code is shit.
But it happens everyday
Why do you want to switch to Ubuntu?
I'm sorry I had to, I'll show myself out
[1] https://manpages.debian.org/testing/systemd/systemd.net-nami...
And sure, one can pin interfaces to custom names, but why should anybody have to bother with such things?!
I like systemd a lot, but this is one of the thing they fumbled big time and seemingly still aren't done.
Pinning interfaces by their MAC to a short and usable name, would e.g. have been much more stable as doing that by PCI slot, which firmware updates, new hardware, newer kernel exposing newer features, ... changes rather often. This works well for all but virtual functions, but those are sub-devices of their parent interface anyway and can just get named with a suffix added to the parent name.
but you also want to be able to change a card in a server without the device name changing. at least that used to be an issue in the past.
Note that the naming scheme is in control of systemd, not the kernel. Even if it is passed on the kernel commandline.
And note that cgroupv1 also still works in the kernel just fine, only the part that systemd controlled was removed from systemd. You can still boot with cgroupv1 support on, e.g., Alpine Linux and OpenRC as init 1. So not sure if that will lessen my concerns about no guarantees for older naming-scheme versions, maintaining triple digits of them sure has its cost too.
And don't understand me wrong, sunsetting cgroupv1 was reasonable, but it was a lot of churn, it at least was a one time thing. The network interface naming situation is periodic churn, guaranteed to bite you every now and then just by using the defaults.
Looking myself for options to keep a Debian bare metal server I admin from going deaf and mute the next time I upgrade it... It still uses an /etc/network/interfaces file that configures a bridge for VMs to use, and the bridge_ports parameter requires an interface name which, when I upgraded to Bookworm, changed.
At this rate maybe I'll write a script that runs on boot and fixes up that file with whatever interface it finds, then restarts the network.
It was deprecated for this nonsense in systemd.
Yes, there were edge cases in the Debian scheme. Yet it did work with VMs (as most VMs kept the same MAC in config files), and it was easy to maintain if you wanted 'fresh'. Just rm the pin file in the udev dir. Done.
Again it worked wonderful on every VM, every bare metal system I worked with.
One of the biggest problems with systemd, is it seems to be developed by people that have no real world, industrial scale admin experience. It's almost like a bunch of DEVs got together, couldn't understand why things were "so confusing", and just figured "Oh, it must be a mistake".
Nope.
It's called covering edge cases, ensuring things are stable for decades, because Linux and the init system are the bottom of the stack. The top of the stack changes like the wind in spring, but the bottom of the stack must be immensely stable, consensus driven, I repeat stable change.
Systemd just doesn't "get" that.
Some real world users asked for a fix. They did not mean they asked specifically for this fix.
There were other ways to handle this.
With Debian's system, you could wipe the state files, and for example eth0/etc would be reassigned per initialization order. Worked fine.
Even if you didn't like that, pre-Systemd udev allowed assigned by a variety of properties, including bus identifiers.
It was merely that Redhat, as usual, was so lacking in sophistication, unlike Debian.
Under RH-based systems the ifcfg-* files had a HWADDR variable, so if you swapped a card you could get the new MAC address and plug it in there and get the same interface name. There was also udevd rules where you map names to particular hardware, including particular MACs.
> Real world enterprise users wanted this, it wasn't an arbitrary design choice.
As a real world sysadmin, working now a few of decades in this field (starting with non-EL-RH, then BSD, then Solaris, then RHEL, Debian, and now Ubuntu), I have never wanted this.
Unlike most desktops, basically all servers got out-of-band management (e.g. IPMI) and a NIC swap is something that needs a tech physically near the server, so even a simple serial console is easily plugged in. Or how will that new NIC work with the whole network, like any basic networking setup or firewall won't allow traffic from arbitrary MACs, so normally this needs to be coordinated already anyway in an enterprise setting, e.g. through a change management process.
And why would one optimize the whole design for network naming for the edge case and not the much more common one like simple software updates.
And the design is not even being able to guarantee it for the edge case. Plugin that NIC in a different PCI slot, or let the firmware to a blip and report it differently–all things that happened!–and you still got no network with net naming scheme. Worse, you reboot after a systemd update, and you can have no network either. Or the kernel learns that your NIC supports virtual functions, guess what, no network because the (seemingly just-in-time) predictable naming scheme now sees that information changing its previous prediction.
I never will be able to understand how one can argue for breaking the common use case, nobody argues that there isn't a real problem or that there is the One True Way™ to solve it (at least I do not intend so), but arguing for using a certainly not ideal default that optimized for an edge case feels a bit like some sunk cost fallacy to me.
Sorry for my wall of text, I would really like to care less, but at $work I am exposed to this mess directly, not only for our infra but for all users of our projects, can all be done and managed, sure, but the churn and hours I have to put in thanks to this feels unnecessary and could be used for much more useful things.
IPMI/iDRAC/iLO/XCC/etc.
Welcome back, eth0. :)
systemd also changes behavior in what naming policies are the default and what it considered as input, it did that since ever but started to version that since v238 [0]. Due to that the HW can stay exactly the same but names still change. I see this in VMs that stay exactly the same, no software update, not change in how the QEMU cli gets generated, really nothing changed from the outside virtual HW POV, interface name still changes.
The underlying problem was a real one, the solution seems like a bit of a sunken cost fallacy, and it added more problem dimensions than there previously exist.
Besides, even if the HW would change, shouldn't a _predicatble_ naming scheme be robust to not care about that as long as the same NIC is still plugged in somewhere?
Disclaimer, as stated elsewhere: I really like systemd, I'm not one that speaks out against it lightly, but the IF naming is not something they got right, but rather made worse for the default case. Being able to easily pin interface names through .link files is great, but requiring users to do that or have no network after an upgrade, especially for simple one-NIC use cases in a completely controlled environment like a VM is just bonkers.
[0]: https://www.freedesktop.org/software/systemd/man/latest/syst...
Regarding your rhetorical question about "the same NIC", I think the problem is in determining whether the NIC is the same, and it is not an easy one to solve. I remember that older Suse Linux versions used to pin the interface name to the NIC's MAC address in an udev rule file that got autogenerated when a NIC with a given MAC first appeared on the system, but they stopped doing that.
And for the other case you can still fallback to the other policies, it still will be much more stable by default.
Please note that I don't say that MAC is perfect, but using something that is actually tied to a NIC itself would fare much better by default compared to the NICs position as determined by a bunch of volatile information, and what normally does not matter to me at all, as e.g., I will always use a 100G NIC as ceph private network while the 25G ones as public one, no matter where they are plugged in. That someone configures something by location is the excpection, not the norm.
I do change ifupdown to systemd-networkd on every server I care about. Matching on MACAddress is a great imprvement. It doesn't help that Debian still insists on keeping ifupdown.
I use Debian Stable on almost all the systems I use (one is stuck on 10/Buster due to MoinMoin). I installed Trixie in a container last week, using an LXC container downloaded from linuxcontainers.org [1].
Three things I noted on the basic install :
1) Ping didn't work due to changed security settings (iputils-ping) [2]
2) OpenSSH server was installed as systemd socket activated and so ignored /etc/ssh/sshd_config*. Maybe this is something specific to the container downloaded.
3) Systemd-resolved uses LLMNR as an name lookup alternative to DNS and pinging a firewalled host failed because the lookup seemed to be LLMNR accessing TCP port 5355. I disabled LLMNR.
Generally, Debian version updates have been succesful with me for a few years now, but I always have a backup, and always read the release notes.
[1] https://linuxcontainers.org
[2] https://www.debian.org/releases/trixie/release-notes/issues....
sshd still reads /etc/ssh/sshd_config at startup. As far as I know, this is hard-coded in the executable.
What Debian has changed happens before the daemon is launched: the service is socket activated. So, _if you change the default port of sshd_ in its config, then you have to change the activation:
- either enable the sshd@service without socket activation,
- or modify the sshd.socket file (`systemctl edit sshd.socket`) which has the port 22 by default.
Since Debian already have a environment file (/etc/default/ssh), which is loaded by this service, the port could be set in a variable there and loaded by the socket activation. But then it would conflict with OpenSSH's own files. This is why I've always disliked /etc/default/ as a second level of configuration in Debian.
The SSH server being a socket unit with systemd doing all of the socket parallelism-limiting and accepting was one of the earliest examples of socket activation ever given in systemd. It was in one of Lennart Poettering's earliest writings on the subject back in 2011.
* https://0pointer.de/blog/projects/inetd.html
And even that wasn't the earliest discussion of this way of running SSH by a long shot, as this was old news even before systemd was invented. One can go back years earlier than even Barrett's, Silverman's, and Byrnes's SSH: The Secure Shell: The Definitive Guide published in 2005, which is one of many places explaining that lots of options in sshd_config get ignored when SSH is started by something else that does all of the socket stuff.
Like inetd.
This has been the case ever since it has been possible to put an SSH server together with inetd in "nowait" mode. Some enterprising computer historian might one day find out when the earliest mention of this was. It might even be in the original 1990s INSTALL file for SSH.
The server is not started using inetd, because it needs to generate
the RSA key before serving the connection, and this can take about a
minute on slower machines. On a fast machine, and small (breakable)
key size (< 512 bits) it may be feasible to start the server from
inetd on every connection. The server must be given "-i" flag if
started from inetd.
I want systemd nowhere fucking near my NTP or DNS config.
(used it before, mostly to learn. went to debian for new laptop. gave up after fighting systemd. I'm aware of devuan and artix, but gentoo just worked (after all the time spent))
https://forum.qubes-os.org/uploads/db3820/original/2X/c/c774...
Once install is done, login and save this file:
/etc/apt/preferences.d/systemd
# this is the only systemd package that is required, so we up its priority first...
Package: libsystemd0
Pin: release bookworm
Pin-Priority: 700
/etc/apt/preferences.d/systemd
# exclude the rest
Package: systemd
Pin: release *
Pin-Priority: -1
Package: *systemd*
Pin: release *
Pin-Priority: -1
Package: systemd:i386
Pin: release *
Pin-Priority: -1
Package: systemd:amd64
Pin: release *
Pin-Priority: -1
apt-get install sysvinit sysvinit-core sysvinit-utils
apt-get purge systemd
Yes, I also run thousands of systems with systemd too.
Moreover, there are the odd one or two unrelated packages that just happen to have the string "systemd" in their names. (-:
$ ps agxf|grep 'systemd'
607 ? S 0:00 /lib/systemd/systemd-udevd
2201 ? S 0:00 /sbin/cgmanager --daemon -m name=systemd
2726 ? S 0:00 /lib/systemd/systemd-logind
Don't get me wrong, systemd is cool. But my god people really abuse of it. Especially distros. Some really make it hard to understand what service is in actual control. Why wrap daemons in daemons in daemons? With the worst possible names and descriptions to boot.
If you have specific issues, please file them over at systemds GitHub issue tracker.
chattr +i /etc/resolv.conf
What else is lurking that you and I aren’t aware of?
All of systemd... and network manager/modem manager/...
I grew up with static configuration files, init scripts, inetd, etc... then grew into Solaris smf, dtrace, zones ... and then Linux implemented systemd. I really miss smf and related tools but systemd is still just meh to me. The implementation feels like a somewhat half-in-each-world brainchild.
Any change can introduce regressions or break habits. The move toward socket activation for sshd is part of a larger change in Debian. I don't think the Debian maintainers changed that just for the fun of it. I can think of two benefits:
+ A service can restart without interruption, since the socket will buffer the requests during the restart.
+ Dependencies are simpler and faster (waiting for a service to start and accept requests is costly).
My experience is that these points largely outweigh the downsides (the only one I can think of is that the socket could be written in two places).
Yeah, but requiring a service's response is why its a dependency in the first place, no?
Total guess, mind you.
I think it doesn't outweight the downside. Let's not forget this:
"OpenSSH normally does not load liblzma, but a common third-party patch used by several Linux distributions causes it to load libsystemd, which in turn loads lzma."
The "XZ utils backdoor" nearly backdoored every single distro running systemd.
People (including those who tried to plant this backdoor) are going to say: "systemd has nothing to do with the backdoor" but I respectfully disagree.
systemd is one heck of a Rube-Goldberg piece of machinery: the attack surface is gigantic seen that systemd's tentacles reaches everywhere.
With a tinfoil hat on one could think the goal of systemd was, precisely, to make sure the most complicated backdoors could be inserted here and there: "Let's have openssh use a lib it doesn't need at all because somehow we'll call libsystemd from openssh".
Genius idea if you ask me.
What could possibly go wrong with systemd "now just opening a port for openssh" uh? Nothing I'm sure.
Now that said I'm very happy that we've now got stuff like the Talos Linux distribution (ultra minimal, immutable, distro meant to run Kubernetes with as few executables as possible and of course no systemd) and then containers using Alpine Linux or, even if Debian based, minimal system with (supposedly) only one process running (and, once again, no systemd).
Containerization is one way out of systemd.
I can't wait for a good systemd-less hypervisor: then I can kiss Microsoft goodbye (systemd is a Microsoft technology, based on Microsoftism, by a now Microsoft employee).
Thanks but no thanks.
Talos distro, systemd-less containers: I want more of this kind of mindset.
The future looks very nice.
systemd lovers should just throw the towel in and switch to Windows: that's what they actually really want and it's probably no better than they deserve.
Doesn't the .socket unit point to a .service unit? Why would using a socket be connected to which config sshd reads?
I am not a fan of that as a default. I'd rather default to cheaper disk space than more limited and expensive memory.
>The new filesystem defaults can also be overridden in /etc/fstab, so systems that already define a separate /tmp partition will be unaffected.
Seems like an easy change to revert from the release notes.
As far as the reasoning behind it, it is a performance optimization since most temporary files are small and short lived. That makes them an ideal candidate for being stored in memory and then paged out to disk when they are no longer being actively utilized to free up memory for other purposes.
Making such claims on HN attracts edge cases like nobody's business but let's see
Maybe the developer runs a standard desktop version, but also uses it personally as a server for some kind of personal itch or software, on actual desktop hardware? Maybe I'm overthinking it, or the developer that wrote this code has the ability to fix more important issues, but went with this instead. I've tackled optimization before where it wasn't needed at the time, but it happened to be something I was looking into, and I felt my time investment could pay off in cases where resources were being pushed to their limits. I work with a lot of small to mid-sized businesses that can actually gain from seemingly small improvements like this.
Until about a year ago, whenever I would try to download moderately large files (>4GB) my whole system would grind to a halt and stop responding.
It took me MONTHS to figure out what's the problem.
Turns out that a lot of applications use /tmp for storing files while they're downloading. And a lot of these applications don't cleanup on fail, some don't even move files after success, but extract and copy extracted files to destination, leaving even more stuff in temp.
Yeah, this is not a problem if you have 4X more ram than the size of files you download. Surely, this is a case for most people. Right?
If it's easily reproducible, I guess checking `top` while downloading a large file might have given a clue, since you could have seen that you're running out of memory?
1) tmpfs is mounted to /tmp
2) available size on /tmp is very low
3) my free ram indicator in status bar is red
That's a very bad default.
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.
Perhaps disabling overcommit as well as swap could be safer from this point of view. Unfortunately, you get other problems if you do so - as very little Linux software handles errors returned by malloc, since it's so uncommon to not have overcommit on a Linux system.
I'd also note that swap isn't even that slow for SSDs, as long as you don't use it for code.
Read-only pages are never written to swap, because they can be retrieved as-is from the filesystem already. Binaries and libraries are accounted as buffer cache, not used memory, and under memory pressure those pages are simply dropped, not swapped out. Whether you have swap enabled or disabled doesn't change that.
Still, I hope that Debian does the sane thing and sets proper size limits. I recall having to troubleshoot memory issues on a system (Ubuntu IIRC) a decade ago where they also extensively used tmpfs: /dev, /dev/shm, /run, /tmp, /var/lock -- except that all those were mounted with the default size, which is 50% of total RAM. And the size limit is per mountpoint...
This is just semantics. The pages are evicted from memory, knowing that they are backed by the disk, and can be swapped back in from disk when needed - behavior that I called "swapping out" since it's pretty similar to what happens with other memory pages in the presence of swap.
Regardless of the naming, the important part is what happens when the page is needed again. If your code page was evicted, when your thread gets scheduled again, it will ask for the page to be read back into memory, requiring a disk read; this will cause some other code page to be evicted; then a new thread will be scheduled - worse case, one that uses the exact code page that just got evicted, repeating the process. And since the scheduler will generally try to execute the thread that has been waiting the most, while the VMM will prefer to evict the oldest read pages, there is actually a decent chance that this exact worse case will happen a lot. This whole thing will completely freeze the system to a degree that is extremely unlikely for a system with a decent amount of swap space.
If I see RAM close to 30 GB I restart my browser and go back to 20 GB or less. Not every month.
Since you state you're running a browser, I assume you mean for personal use. Unfortunately, when you run a service open to the public, you can find all kinds of odd traffic even for normal low-memory services. Sometimes you'll get hit with an aggressive bot looking for an exploit, and a lot of those bots don't care if they get blocked, because they are built to absolutely crush a system with exploits or login attempts where they are only blocked by the system crashing.
I'd say that most bots are this aggressive, because the old school "script kiddies", or now it's just AI-enabled aggressors, just run code without understanding things. It's easier than ever to run an attack against a range of IP addresses looking for vulnerabilities, that can be chained into a LLM to generate code that can be run easily.
Anyway, I'd also enable swap on public facing servers.
It's only when you're consistently at the limit of how much RAM you have available that the differences start to matter. If you want to run a ~30GB +- 10% workload on a system with 32GB of RAM, then you'll get to find out how stable it is with VS without swap.
With swap enabled, it is very, very, VERY common for the system to become completely unresponsive - no magic-sysrq, no ctrl-alt-f2 to login as root, no ssh'ing in ...
You also have some misunderstandings a bout overcommit. If you aren't checking `malloc` failure you have UB, but hopefully you will just crash (killing processes is a good thing when the system fundamentally can't fulfill everything you're asking of it!), and there's a pretty good chance the process that gets killed is blameworthy. The real problems are large processes that call `fork` instead of `vfork` (which is admittedly hard to use) or `posix_spawn` (which is admittedly limited and full of bugs), and processes that try to be "clever" and cache things in RAM (for which there's admittedly no good kernel interface).
===
"Swap isn't even that slow for SSDs" is part of the problem. All developers should be required to use an HDD with full-disk encryption, so that they stop papering over their performance bugs.
> With swap enabled, it is very, very, VERY common for the system to become completely unresponsive - no magic-sysrq, no ctrl-alt-f2 to login as root, no ssh'ing in ...
It's usually enough to have couple of times when you need to get into distant DC / wait for some IPMI connected for couple of hours, to learn "let it fail fast and gimme ssh back" on practice vs theory on "you should have swap on"
Conversely, with a few GB of old data paged out to disk, even to a slow HDD, there is going to be much, much less thrashing going on. Chances are, the system will work pretty normally, since it's most likely that memory that isn't being used at all is what will get swapped out, so it's unlikely to need to be swapped in any time soon. The spike that caused you to go over your normal memory usage will die down, memory will get freed naturally, and worse you'll see is that some process will have a temporary spike in latency soem time later when it actually needs those swapped out pages.
Now, if the spike is too large to fit even in RAM + swap, the OOMKiller will still run and the system will recover that way.
The only situation where you'll get in the state you are describing is if veitually all of your memory pages are constantly getting read and written to, so that the VMM can't evict any "stale" pages to swap. This should be a relatively rare occurrence, but I'm sure there are workloads where this happens, and I agree that in those cases, disabling swap is a good idea.
> If you aren't checking `malloc` failure you have UB, but hopefully you will just crash (killing processes is a good thing when the system fundamentally can't fulfill everything you're asking of it!), and there's a pretty good chance the process that gets killed is blameworthy.
This is a very optimistic assumption. Crashing is about as likely as some kind of data corruption for these cases. Not to mention, crashing (or getting OOMKilled, for that matter) are very likely to cause data loss - a potentially huge issue. If you can avoid the situation altogether, that's much better. Which means overprovisioning and enabling some amount of swap if your workload is of a nature that doesn't constantly churn the entire working memory.
> "Swap isn't even that slow for SSDs" is part of the problem. All developers should be required to use an HDD with full-disk encryption, so that they stop papering over their performance bugs.
You're supposed to design software for the systems you actually yarget, not some lowest common denominator. If you're targeting use cases where the software will be deployed on 5400 RPM HDDs with full disk encryption at rest running on an Intel Celeron CPU with 512 MB of RAM, then yes, design your system for those constraints. Disable swap, overcommit too, probably avoid any kind of VM technology, etc.
But don't go telling people who are designing for servers running on SSDs to disable swap because it'll make the system unusably slow - it just won't.
tmpfs by default only uses up to half your available RAM unless specified otherwise. So this isn't really a consideration unless you configure it to be a consideration you need to take into account.
(Systemd also really recently (v258) added quotas to tmpfs and IIRC its set by default to 80% of the tmpfs, so it is even less of a problem)
$ grep tmpfs /proc/mounts
udev /dev devtmpfs [..]
tmpfs /run tmpfs [..]
tmpfs /run/lock tmpfs [..]
tmpfs /run/shm tmpfs [..]
tmpfs /tmp tmpfs [..]
cgroup_root /sys/fs/cgroup tmpfs [..]
All those arguments would be useful if we somehow could avoid the fact that the system will use it as "emergency memory" and become unresponsive. The kernel's OOM killer is broken for this, and userland OOM daemons are unreliable. `vm.swappiness` is completely useless in the worst case, which is the only case that matters.
With swap off, all the kernel needs to do is reserve a certain threshold for disk cache to avoid the thrashing problem. I don't know what the kernel actually does here (or what its tunables are), because systems with swap off have never caused problems for me the way systems with swap on inevitably do. The OOM killer works fine with swap off, because a system must always be resilient to unexpected process failure.
And worst of all - the kernel requires swap (and its bugs) to be enabled for hibernation to work.
It really wouldn't be hard to design a working swap system (just calculate how much to keep of different purposes of swap, and launch the OOM killer earlier), but apparently nobody in kernel-land understands the real-world problems enough to bother.
this one gets me irritated every time i think about it. i don't want to use swap, but i do want hibernation. why is there no way to disable swap without that?
hmm, i suppose one could write a script that enables an inactive swap partition just before shutdown, and disables it again after boot.
You can use suspend+hibernate to accomplish that and it works well. Unless the gods of kernel lockdown decide you cannot for your own good (and it doesn't matter if your disk is fully encrypted, you're not worthy anyway) of course. It's their kernel running on your laptop after all.
What the heck are you talking about? Swap is enabled on every Linux system I manage (servers, desktop etc) and it's perfectly stable.
In this new stable release, an update to Dovecot will break your configuration: https://willem.com/blog/2025-06-04_breaking-changes/
I use it for years to achieve HA for personal mail servers and will now have to look for alternatives -- until then will stick with Debian Bookworm and its Dovecot 2.3.
[1] https://doc.dovecot.org/2.4.0/installation/upgrade/2.3-to-2....
Yeah, Dovecot seem to be going hardline commercial. Basically the open-source version will be maintained as a single server solution. Looks like if you want supported HA etc. you'll have to pay the big bucks.
There is a video up on YouTube[1] where their Sales Director is speaking at a conference and he said (rough transcript):
"there will be an open source version, but that open source version will be maintained for single server use only. we are actually taking out anything any actually kinda' involves multiple servers, dsync replication and err some other stuff. so dovecot will be a fully-featured single node server"
Have you looked at Stalwart[2] as an alternative ?
[1] https://youtu.be/s-JYrjCKshA?t=912 [2] https://stalw.art/
(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.
What this means is when you find out stuff breaks, like drivers and application software, and decide the upgrade was a bad idea, you are fucked.
More notably, some of the upgrade is irreversible - like MySQL/MariaDB. The database binary format is upgraded during the upgrade. So if you discover something else broke, and you want to go back, it's going to take some work.
Ask me how I know.
Back up your data
Performing a release upgrade is never without risk. The upgrade may fail, leaving the system in a non-functioning state. USERS SHOULD BACKUP ALL DATA before attempting a release upgrade. DebianStability contains more information on these steps.
Of course anyone can restore from backups. It's a pain and it's time consuming.
My post serves more as a warning to those who may develop buyer's remorse.
Windows is using Volume Shadow Copies, which for the purposes of this discussion, you can think of as roughly equivalent.
I've used this trick many times in a live, rw environment.
Too many bits of 'advice' on Stack Overflow, etc. claiming it's possible as top Google results.
I'm here to say unequivocally: it does not work, will not work, and will leave the system in an irreversibly broken state. Do not attempt.
But this isn't something that would be 'out of the box'... but that's why we make backups, but I can't remember an dist-upgrade ever significantly bricking my systems.
What problems did you have that made you want to roll back the update?
This was complicated by the fact that the machine also hosted a MySQL database which could not be easily rolled back because the database was versioned up during the upgrade.
This sounds like a business setting, so this sounds like a good opportunity to advocate for testing hardware, a testing budget, a rollout plan, and a sound backup strategy.
Only thing that was broken was the desktop background, everything else worked great w/o any issue and even solved some trouble I had to fix by hand for Bookworm (WiFi sleep mode), so I upgraded all my physical and virtual machines.
Had no issues at all, only thing annoying compared to running stable was the amount of updated packages, which again run trough w/o any hitch and I have to take full responsibility. ;-)
Highly recommended if you want a Linux distribution for a server or a desktop which simply works and keeps working.
This is because Testing has done a soft freeze, then a hard freeze, then is prepped to become the new Stable. During that process, nothing new can be added to Testing.
Then, one day, Stable is released and the floodgates on Testing re-open. The people who specified "Trixie" are fine: they are now running Stable. The people who specified "testing" in their apt sources, or are installing Testing based on the wonderful reports of just a month ago, are in for a terrible experience. And... anyone who installed Stable as "stable" instead of "bookworm" is now getting upgraded shortly after release day, instead of at their convenience.
This happens every cycle.
Never recommend that anyone new to Debian should install Testing, even if it's about to become Stable. Unless you are working on throwaway systems, always specify a codename for release, not "stable" or "testing" or "unstable".
I'm on stable like 3/4 of the time, until there's some newer package version I want and that happens to be in testing, at which point I switch (using the codename as you suggest instead of Testing). If I don't have a specific need, I tend to switch during the soft or hard freeze, out of curiosity, because I never had problems doing that.
Now I need to figure out what happens when my testing suddenly is stable, and how to get on the next testing, I guess.
The policy manual serves as both ruleset but also explains lots of things w.r.t. packaging, as that's part of the ruleset: https://www.debian.org/doc/debian-policy/index.html#
For actually uploading new packages to the archive you need to be "DD" (Debian Developer), which is a bit more involved process to go through. "DM"s (Debian Maintainer) is easier and can do already lots of things. It's also possible to start out by finding an existing DD that sponsors your upload, i.e. checks your final packaging work and if it looks alright will upload it in your name to the repositories.
You might also check out the wiki of Debian, it's sometimes a bit dated and got lots of info packed in, but can still be valuable if you're willing to work through the outdated bits. E.g.: https://wiki.debian.org/DebianMentorsFaq
But yes, RPM itself is better than Deb if only because there's a single .spec file rather than a sea of embedded nonsense. It's still not as nice as many "port" packaging systems (e.g. the BSDs, but also Gentoo), but most of those cheat by not having to deal with arbitrary binary packages. Still, binary packages are hardly an excuse for the ludicrous contortions the standard deb-building tools choose to require.
Sounds like OpenSUSE to me. I tend to favor the fast-updating versions, but I'm pretty sure openSUSE Leap is exactly what you're asking for.
I don't think there are many alternatives. OpenSUSE isn't supported for very long, and there really isn't anything else if you want btrfs, no Debian or its derivatives, and fire & forget kind of distribution.
Edit: Also look at Alpine Linux, if supports btrfs and has one of the best package formats that is an absolute joy to write (way easier than rpm or deb).
It's pretty different in some areas (no systemd and musl being two examples), check if that's fine for you.
"RHEL" is supported for 10, and if Oracle screws us over (I can believe in that possibility), ELevate lets you migrate sideways to any supported alternative.
It really depends on the use case.
For example, 15.6 was still stuck on GCC 7. Guess when 15.0 was released. Also, stuck on Python 3.6, which was released around the same time.
alpine feels a bit to opinionated for my taste. i just found this though: https://mrgecko.org/blog/2024/add-btrfs-support-to-rocky-and... centos has a SIG that provides kernels with btrfs which can be used with alma and rocky. that sounds promising.
Best Packaging Practices https://www.debian.org/doc/manuals/developers-reference/best...
There's two tutorials/walkthroughs linked from there:
- how to build an existing Debian package: https://wiki.debian.org/BuildingTutorial
- how to package new software for Debian: https://www.debian.org/doc/manuals/debmake-doc/ch05.en.html
For half a year now, I've run trixie on RISC-V (VisionFive 2 board), with ZFS root, without issue.
Do we really need a new major version of gtk/qt or a different firewall program, when all those things have existed for many years?
Gnome runs better than ever, the problem is in my experience usually the web browser when it comes to RAM usage. Install ZRAM and the machine should be perfectly usable, if your usage patterns are similar to mine.
(Only thing which annoys me is that I cannot find an excuse to buy a better computer, because everything simply works on the machine...)
sway and/or libinput now supports mouse-pad gestures so you can configure tjree-finger swiping between workspaces.
Very much appreciated.
The usual: light, stable and functional. I run older version as my DNS servers and homelad stuff, opensource 3D printer, etc. Debian just works with no dramas. I run it in text mode only so boot takes what ~3-5 seconds.
When you su to root, the whole path or a different path is loaded. One has to type su and then su - in order to reach all the regular bin and abin directories. It is flagged, but Debian team won't fix. As a user it is not great.
Secondly, Debian now ships with Raspberrypifirmware package, even on intel installs. When you enable backports to install a newer kernel, this fails due to this package bring there . It ks a major hassle to fix, and without Chatgpt/competitors it is very easy to get lost troubleshooting this.
But what I really wish is they would some have more automation options suitable for the modern cloud world, e.g. something similar to Butane/Ignition as used on CoreOS.
I know there's cloud-init but that's hacky, verbose and opinionated compared to something like Butane/Ignition.
I also know there's ansible etc. in Debian distro but that's kind of yesterday's solution.
It's got the latest Angband (4.2.5). Homestyle SDL ui.
I’ve been on sid for the last 10 months for my laptop (old T450s) and my secondary desktop, and it is really fun.
There are annoyances but they are not related to Debian itself.
FIRST
I decided it is time to switch to Wayland. Now my favorite run-or-raise app (Kupfer) cannot do run-or-raise. But there is a really nice extension to do run-or-raise on GNOME without the aggressive disruption of the Activities overview: Switcher. The other thing that is difficult on Wayland is text expansion. I have not found a solution for that part.
SECOND
The annoying to infuriating things that GNOME likes doing sometimes. But that is a constant. Nothing new.
Congrats and thanks to all the Debian people!
The reply writes itself, doesn’t it? :-D
I like GNOME more though, in general. I just want GNOME without some of the unfathomable stuff, and with the progress KDE has made with Wayland.
Yes, every data center in the world still runs on Intel Xeon because AMD can't get a big enough allocation at TSMC to meet demand.
The reports of Intel's death are greatly exaggerated.