[HN Gopher] Debian 13 "Trixie"
___________________________________________________________________
Debian 13 "Trixie"
Author : ducktective
Score : 869 points
Date : 2025-08-09 18:18 UTC (1 days ago)
(HTM) web link (www.debian.org)
(TXT) w3m dump (www.debian.org)
| gorgoiler wrote:
| Congratulations!
|
| Debian has been the stable footing of my Free computing life for
| three decades. Everything about their approach -- from showing me
| Condorcet, organising stable chaos, moving forward by measured
| consensus, and basing everything on hard wrought principles --
| has had an effect on me in some way, from technical to social and
| back again.
|
| I love this project and the immeasurable impact it has had on the
| world through their releases and culture.
|
| With all my love, g'o xx
| Paianni wrote:
| The Devuan version may end up being the last that GNOME will run
| on...
| UncleSlacky wrote:
| You say that like it's a bad thing.
| Paianni wrote:
| I don't like GNOME's engineering or license, but as far as
| the UI and design are concerned I don't think anyone has
| topped it (minus the hot corner I guess).
| kasabali wrote:
| Meh, it looks pretty in screenshots but it's a huge waste
| of screen space in the end.
| Paianni wrote:
| I suppose 'power-users' can put up with 'small-button'
| GUIs but I do think a general purpose GUI needs to be
| easy to use for people who aren't used to controlling
| mice and keyboards all the time.
| superkuh wrote:
| 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 being a regular directory by running
| systemctl mask tmp.mount as root and rebooting."
|
| I kind of wish the distros had decided on a new /tmpfs (or
| /tmp/tmpfs, etc) directory for applications to opt-in to using
| ram-disk rather than replacing /tmp and having to opt-out.
| bbarnett wrote:
| Also watch out for surprise file deletes in /tmp and /var/tmp
| at 10 and 30 days.
|
| This too can be turned off.
| KORraN wrote:
| Isn't this the feature of /tmp? I set my default download
| location in Firefox to /tmp exactly for this reason, so that
| all the junk gets automatically removed after some time.
| Also, whenever I need a temporary Python script or test a
| package, I create a venv under /tmp.
| superkuh wrote:
| On boot has been the standard for a long time and is still
| the most common. I am personally surprised to hear that now
| Debian and some distros do it via various automated ways at
| time intervals.
| saint_yossarian wrote:
| It's a systemd thing, see `man systemd-tmpfiles`.
| kasabali wrote:
| It was available as an option before that: https://manpag
| es.ubuntu.com/manpages/xenial/man5/rcS.5.html
| sgarland wrote:
| I can't fathom why anyone would be surprised that a directory
| named "tmp" is ephemeral.
| CogitoCogito wrote:
| Then I think you just don't have much imagination. I have
| recovered files in /tmp after turning off a machine by
| booting it back up in single-user mode and accessing the
| data before it would be cleared in during bootup. Given
| that "turning off a machine" can also mean "the machine
| lost power", I can definitely see why people would be
| surprised by this change.
| bryanlarsen wrote:
| Infinite scroll length on terminals can chew through /tmp, and
| systems misbehave strangely when they're out of /tmp.
| spauldo wrote:
| 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.
| bayindirh wrote:
| This was discussed a ton in debian-devel. First, the tmpfs
| doesn't take much space already, and /tmp became a folder where
| persistence should not be expected over the years.
|
| The problem with /tmp was many people and apps used it as an
| inter-user communication medium and expected persistency there,
| so it created both security problems and wasted disk space over
| time.
|
| Since not many packaged apps used the /tmp like that and used
| the folder the way it should be used, the change was made.
|
| I'm running Debian testing on one of my systems, and the change
| created no ill effects whatsoever. Not eating SSD write cycles
| can be considered a plus, even.
|
| However, as I also noted in the relevant thread, the approach
| might have a couple of downsides in some scenarios.
|
| If you have the time and the desire, discussion starts at
| https://lists.debian.org/debian-devel/2024/05/msg00014.html
| 3eb7988a1663 wrote:
| Maybe title should note that it has now been released? There has
| been many updates about Trixie in the past few months in
| preparation for today.
| cocoto wrote:
| I think the title has been trimmed from the word "realeased".
| Might be another case of HN auto title edit botching the
| original title.
| hiprob wrote:
| I can't believe we've come to such a high number, and a
| particularly lucky one at that
|
| Alas it's still not suitable as a daily driver for the average
| home user and probably never will be. It is unfortunate that
| Ubuntu has to reign supreme in that regard.
| cocoto wrote:
| The installation is slightly easier (but still hard because of
| USB install) and the website has a more appealing design.
| Except from that what is better in Ubuntu for the average
| casual user? Proprietary blobs are now included in the default
| installer since version 12.
| amtamt wrote:
| Two kids in 4 to 16 range, and two adults in 30 to 46 age
| ranges have been using Debian on daily basis for almost a
| decade now. At least three of them are pretty "average home
| user". There has been forced use of windows (since school and
| employers wanted), but for home use Debian has always been
| better due to less maintenance needs and no distractions.
| accrual wrote:
| > Alas it's still not suitable as a daily driver for the
| average home user
|
| I think that's fine for Debian. Maybe even a good thing.
|
| Debian supplies a rock solid base for many general purpose
| tasks. Ubuntu and other distros are free to package that up in
| a user friendly way, but as a technical user I want to be able
| to go upstream and get a basic Linux system without extra
| stuff.
| josteink wrote:
| Don't feed the troll, etc... But I just had to bite on this
| bit:
|
| > Alas it's still not suitable as a daily driver for the
| average home user and probably never will be. It is unfortunate
| that Ubuntu has to reign supreme in that regard.
|
| It's true that Ubuntu used to be the OOB ready version of
| Debian, which "just worked", while base Debian took look of
| fiddling to even have wifi working.
|
| These day though I find the opposite to be true: Ubuntu does
| lots of weird things I don't want, and I have to "fiddle" to
| disable all that. A base Debian install however (ISO with
| firmware bundled), just works.
|
| For me, Ubuntu is officially off my list of distros I bother
| spending my time on.
| prmoustache wrote:
| You can install debian and ubuntu with same DE and you'd be
| hard pressed to find a difference apart from the theme unless
| you are a power user who knows what snap is.
|
| In fact, Ubuntu has never been an especially user friendly
| distro. At the beginning it was just a debian that was
| installed with debian's experimental installer before they
| decided to use it in stable. Nothing more, nothing less.
|
| If you wanted to find a distro that was making efforts towards
| beginners looking for Gui config tools, you had to look at Suse
| and Mandrake (now Mandriva).
|
| The only specific thing Ubuntu did for beginners is sending CDs
| for free at a time when not everybody had fast internet
| connections and would look for paper magazine to come with
| CD/DVD. And they have stopped doing that a loooooong time ago.
| simion314 wrote:
| >The only specific thing Ubuntu did for beginners is sending
| CDs for free
|
| Assuming you are not malicious I will kindly help with your
| bad memory, Ubuntu had always very good proprietary driver
| support, this made laptops actually work and helped
| beginners. I also remember they had a graphical installer
| compared to Debian and for sure this was beginners friendly.
| Maybe some other distro offered easy way to install and come
| with proprietary drivers setup but I can't remember a deb
| based distro doing that.
|
| Anyway you were wrong, the CDs were not the only thing made
| Ubuntu appeal for beginners, there were Linux magazines with
| CDs each month and they were not super expensive , my first
| linux was a Kubuntu 6.10 from a magazine and I am still
| running Kubuntu today though i ran Debian, Sidux, Arch,
| Mandriva, SUSE in the past when I had time to try different
| distros, compile custom kernels etc.
| prmoustache wrote:
| the graphical installer was debian's new experimental
| installer. They just decided to release a stable distro
| before debian with it.
|
| Proprietary driver installation was the sole reason of
| existence of Linux Mint which was a fork of ubuntu, so your
| memory is incorrect.
| simion314 wrote:
| >Proprietary driver installation was the sole reason of
| existence of Linux Mint which was a fork of ubuntu, so
| your memory is incorrect.
|
| I think your memory is incorrect, you might be thinking
| of video codecs and maybe Flash not proprietary drivers,
| since Ubuntu already had support for easy install of
| drivers before Mint.
| foresto wrote:
| > Alas it's still not suitable as a daily driver for the
| average home user and probably never will be.
|
| Why not?
|
| My family members need little more than a web browser, media
| player, and office suite. Debian Stable is very suitable here;
| arguably more so than other distros, which tend to require
| maintenance more often.
| josteink wrote:
| I've upgraded all my servers and laptops to Debian 13.
|
| Lucky 13 and all... And not a single issue so far. Very happy!
|
| Thanks to the Debian team for putting out yet another high
| quality, reliable release :)
| bbarnett wrote:
| 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-sysv- systemd- as a
| fix, along with allow remove essential.
|
| After this fix, sysvinit builds with debootstrap were almost
| identical as to bookworm. This includes for desktops.
|
| As per with bookworm through buster, you'll still need something
| like this too: $ cat
| /etc/apt/preferences.d/systemd # this is the only
| systemd package that is required, so we up its priority first...
| Package: libsystemd0 Pin: release trixie Pin-
| Priority: 700 # 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
| egorfine wrote:
| Wait, sysvinit on debian 13 truly practically works?? as in,
| one can remove systemd and have a working server OS with sysv
| init??
| bbarnett wrote:
| Yes.
|
| I run a full desktop too, without it. Multiple variants.
|
| I don't use gnome's Desktop Environment though (although I do
| run gtk/gnome software), so cannot comment on that.
| UncleSlacky wrote:
| Yes, MX Linux will be doing this (as a separate ISO, until
| now they're been able to provide a single ISO that lets you
| choose between systemd and sysvinit at every boot):
|
| https://mxlinux.org/blog/changes-coming-with-mx-25/
| foresto wrote:
| Thank you for sharing this. I'm inclined to adopt it in my lxc
| containers, at least.
| RVuRnvbM2e wrote:
| Why would you want to do this?
| dijit wrote:
| choice.
| zahlman wrote:
| To avoid systemd, presumably. Although one could also just
| switch to Devuan at that point.
| dur-randir wrote:
| I've been living with sysvinit up until Debian 11. Then it
| became unusable with lxc containers :(, so I had to bite the
| bullet. But for the basic system it indeed works.
| accrual wrote:
| > 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 August 2025.
| I have Debian 10 Buster running on a Pentium 3 which only EOL'd
| last year in June 2024. It's still useful on that hardware and
| I'm grateful support continued as long as it did!
|
| OpenBSD still supports i386 for those looking for a modern OS on
| old 32-bit hardware.
| zozbot234 wrote:
| 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.
| 3eb7988a1663 wrote:
| To what end? Outside of sheer nostalgia if you are running
| ancient hardware, you probably have a bespoke application
| which requires that environment. Either you cannot change for
| hard technical, compliance, or just fear of the unknown.
| Firewall it from the internet and continue to run whatever
| release last worked.
|
| I am not happy about unnecessary ewaste, but an i386 almost
| certainly has and order of magnitude less horsepower than a
| raspberry pi or N100.
| michaelt wrote:
| 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)
| progval wrote:
| 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.
| herewulf wrote:
| 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.
| boomboomsubban wrote:
| I don't think this is the case anymore, see https://gitla
| b.winehq.org/wine/wine/-/releases/wine-9.0#wow6... though
| it's not the default everywhere.
| duskwuff wrote:
| Debian is doing basically the same thing Ubuntu is with
| regards to i386. Packages are still being built for the
| architecture, but i386 systems aren't supported, and
| there's no 32-bit kernel package.
|
| e.g. notice that i386 is still listed at the bottom of
| https://packages.debian.org/trixie/bash
| KennyBlanken wrote:
| According to Passmark the Pentinum 4 1.3Ghz is 55 times
| slower than a Raspberry Pi 5, so I'd guess it's at least
| two orders of magnitude. The original Pi is 16 times faster
| than a P4 1.3Ghz...
|
| You can recycle e-waste (and yes, I know SOME e-waste ends
| up in China/India/etc. Not all does.)
|
| The e-waste is of substantially less concern than the
| _massive_ difference in carbon footprint from power
| consumption.
| bobmcnamara wrote:
| > The original Pi is 16 times faster than a P4 1.3Ghz...
|
| It isn't. Had both.
|
| ~700MHz mostly in-order ARM 11 without SIMD. Worked with
| these a lot.
|
| ..vs..
|
| 1.3GHz out-of-order with SIMD
| shasheene wrote:
| Debian's tagline is the "universal operating system". It's
| a distribution with active ports on a very large number of
| architectures [1], even incredibly obscure ones.
|
| The goal of universal compatibility that separates the
| Debian project from commercial software and even other
| open-source projects.
|
| The legacy x86 architecture is still far more popular than
| some that platforms that Debian advertises as having
| official support for and there has been x86 based
| processors manufactured for niche applications until
| recently, eg, AMD Geode and others.
|
| I find it really unfortunate Debian Project is removing
| official support for new x86 installations. The silver
| lining is it seems like they'll be an unofficial port and
| it's likely niche distributions like MX Linux and AntiX
| will maintain their own builds.
|
| It would be ideal if open-source can develop stronger
| mechanims to keep support for the large numbers of these
| relatively niche architectures (eg, through increased usage
| of emulation over real hardware).
|
| [1] https://wiki.debian.org/SupportedArchitectures
| munchlax wrote:
| It still exists but without any official iso or installer.
|
| If that's all there's to it, you can still use debootstrap,
| compile a kernel, and point the root parameter to your shiny
| new install.
|
| If the official i386 arch was built with instructions that
| your hardware doesn't support, tough cookies.
| tremon wrote:
| _If the official i386 arch was built with instructions that
| your hardware doesn 't support, tough cookies_
|
| While theoretically possible, that would only happen on
| processors older than 30 years. Debian's i386 architecture
| still uses -march=i686 as its baseline compiler target,
| which is the venerable Pentium Pro:
| https://en.wikipedia.org/wiki/P6_(microarchitecture)
| avhon1 wrote:
| I have AMD Geode hardware circa 2007 (18 years old) that
| only has partial support for i686. Requires a true
| 3/4/586 kernel.
| tremon wrote:
| Not sure why you are downvoted, I guess people don't
| believe this is true. To confirm: The AMD Geode LX was a
| <5W 32-bit x86 processor which did not support SSE
| instructions, and is therefore not fully i686 compatible.
| According to Wikipedia, it was produced until 2019:
| https://en.wikipedia.org/wiki/Amd_geode#AMD_Geode
|
| It was used in the OLPC XO-1. The Cisco ASA line of
| firewalls also used Geode processors at least at some
| point in its lifetime.
| tremon wrote:
| The i386 architecture hasn't been dropped, it is still
| available in the archives to support 32-bit applications. The
| major change is that there no longer is a 32-bit kernel in
| the archive (the package linux-image-686 is no more). But
| most packages are still available in their i386 versions:
| $ curl -s
| http://deb.debian.org/debian/dists/trixie/main/binary-
| amd64/Packages.gz | zgrep ^Package: | wc -l 68737
| $ curl -s http://deb.debian.org/debian/dists/trixie/main/bina
| ry-i386/Packages.gz | zgrep ^Package: | wc -l 66958
| pabs3 wrote:
| In case anyone wants to do that, here is the doc for new
| ports:
|
| https://wiki.debian.org/PortsDocs/New
| zozbot234 wrote:
| Much of that information has to do with creating a new
| hardware port from scratch. The i386 support just needs to
| be "demoted" to the Debian ports infrastructure once it's
| officially scheduled to get dropped from the main Debian
| repository (which could well happen starting either in
| Debian forky or duke), and this can probably be done with
| some special handling.
|
| (Answering the "to what end?" question, a lot of 32bit-only
| hardware is still available and dirt cheap in the second-
| hand market (e.g. early "netbooks"), much of it quite well-
| built and enjoyable to use. While such hardware can no
| longer realistically browse the "modern" web, it can still
| find a lot of use for more lightweight tasks, including
| acting as a "thin client" for more powerful machines.)
| NewJazz wrote:
| Well, isn't there an additional year or so of support for old
| stable? So beyond 2025.
| abhinavk wrote:
| Buster is supported until June 2028.
| NewJazz wrote:
| Thanks, I assume some of that is sort of extended,
| asterisked support though?
| pabs3 wrote:
| Games are unsupported, and a bunch of other packages:
|
| https://wiki.debian.org/LTS/Bullseye https://wiki.debian.
| org/LTS/Using#Check_for_unsupported_pack...
| bbarnett wrote:
| 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.
| pabs3 wrote:
| 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
| bbarnett wrote:
| Ah, they advertised non-profit at one point, but I see
| that's changed. That may have been "we seek no profit"
| not "non-profit entity". Thanks for the info on this
| point.
|
| Back to LTS:
|
| _Debian LTS is not handled by the Debian Security and
| Release teams, but by a separate group of volunteers and
| companies interested in making it a success._
|
| To the point, Freexian is 100% not Debian, not "part" of
| Debian, it merely uses Debian's infra gratis for LTS.
| This does not detract from the good work they do, but we
| must also not confuse a private company, and its goals,
| with Debian and its goals.
|
| LTS tries its best, but only supports what it can. Not
| its fault. Thus they do give preference to packages which
| are more widely used, and which they have received
| donations for.
|
| So wildly popular things such as apache2, mariadb, and so
| on are very much going to be handled. Some rare package
| which has 400 users worldwide? Not so much.
|
| LTS will very much take patches and any help, but that
| still ties in to the number of users. If a packages has
| 400 users worldwide, and most have moved on to the next
| release? Well, I hope you see my point.
|
| (I've moved customers off of LTS for using rare packages,
| whilst reassuring them that LAMP servers are very much
| supported due to this. Popularity counts here, due to
| efforts of volunteers and externals.)
|
| --
|
| ELTS only supports a further subset of packages. It's not
| "full" support. I think one would be exceptionally unwise
| to use it, for say a desktop. That is, unless they were
| paying for support and had obtained a list of all
| packages supported.
|
| --
|
| https://www.freexian.com/lts/extended/docs/debian-10-supp
| ort...
|
| "Note that when you request a quote, we send you back a
| list of packages that are not supported or that have
| limitations in their support so that you can take an
| informed decision."
|
| Yes, I know that page has a git repo and so on for some
| support information.
|
| But my points are; not the full distro is supported, you
| have to track this yourself, you need to be diligent, and
| even so you need to be sure you're not running rarer
| packages.
|
| Once again, I do want to reiterate, these are both
| excellent programs. They do a good job, they're
| dedicated, but we _must_ be aware of the limitations
| here.
|
| An example being the differences between security support
| for main, non-free, contrib in stable Debian:
|
| https://www.debian.org/security/faq#contrib
|
| As you can see, there is no actual guaranteed security
| support for contrib and non-free. The reasons are
| logical, however, users need to be aware of the nuance
| here.
|
| Just as they need to be aware of the nuance of LTS and
| ELTS.
|
| For example, all of my server installs have non-free,
| non-free-firmware and contrib blocked via pinning in
| preferences.d, with only specific absolutely required
| packages then allowed back in.
|
| (For example I may allow command line apps, but not
| anything network connected, and only with a once over of
| functionality and SUID bits and other such things)
|
| --
|
| Really, I see LTS as a crutch that normal users should
| never use. I suggest we collectively not encourage
| Desktop users (for example) to use LTS.
| pabs3 wrote:
| The LTS/Freexian people are all Debian
| members/contributors, so I would not say "Freexian is
| 100% not Debian" is correct. Basically, some Debian folks
| got together and started a company to get funding to do
| an LTS, and also offer other paid services.
|
| At least for bullseye, the LTS team supposedly support
| all packages, except for games and a few other packages.
| Its trivial to find out which packages aren't supported
| too, just run a command, no need to email anyone.
|
| https://wiki.debian.org/LTS/Bullseye https://wiki.debian.
| org/LTS/Using#Check_for_unsupported_pack...
| https://salsa.debian.org/debian/debian-security-
| support/-/bl...
|
| Agreed on the rest, although do note LTS contributors are
| paid, the security team probably aren't (although some
| are).
|
| I think in practice, when contrib/non-free stuff has
| security updates from upstreams, Debian does get updates
| in stable/LTS. For example the Intel microcode, or WiFi
| firmware.
|
| I too feel like Debian having LTS is a waste of time,
| people should be able to upgrade to the next stable
| within the one year of regular security support for
| oldstable.
|
| BTW, Ubuntu security support has a similar issue; main is
| supported, universe is not.
| abhinavk wrote:
| I was meaning to write Bookworm. Bookworm is the last to
| support i386 kernel and is supported until June 2028.
| badsectoracula wrote:
| AFAICT this refers to Debian support, the Linux kernel does
| support 32bit CPUs though only since the original Pentium
| (excluding some clones).
| esaym wrote:
| Are you confusing "386" with 32bit? 686 is the normal 32bit
| arch. 386 is something from the 1980's right?
| NewJazz wrote:
| AIUI Debian kept the i386 name for the arch even as their 32
| bit requirements evolved.
| bowsamic wrote:
| i386 is the most common term used for 32 bit x86
| https://en.m.wikipedia.org/wiki/IA-32
| accrual wrote:
| When distros mention i386 support they often actually refer
| to i586 or i686, yes.
|
| True i386 support would mean compatible with the original
| Intel 386 processor from 1985. The 486 added a few additional
| instructions in 1989 but things really changed with the
| Pentium in 1993 - that gave us i586 which is the bare minimum
| for most modern software today. Much software can still run
| on regular Pentiums today if compiled for it, but SSE2
| optimizations requires at least a Pentium 4 or Core CPUs
| instead.
|
| I play with retro PCs often and found OpenBSD's i386 target
| stopped supporting real 386 CPUs after the 4.1 release, and
| dropped support for i486 somewhat recently in 6.8. It now
| requires at least a Pentium class CPU, i586, though the arch
| is still referred to as i386 likely because it's a common
| proxy for "32-bit".
| chungy wrote:
| Debian 3.0 was the last version that ran on the 80386
| processor proper, but even as the CPU requirements for the
| "i386" architecture moved up to the 486, then Pentium, then
| Pentium II, the name stuck around. Partly from inertia,
| partly to not break the entire existing mirror
| infrastructure.
| zozbot234 wrote:
| The Linux kernel also requires at least i486 now. AIUI that
| decision had to do with smoothing out multicore/SMP support
| - which is a bit silly because no real 80386 systems in
| common use are even SMP, let alone multicore. But anyway.
| astrobe_ wrote:
| Yes, 386 and 486 stayed relevant throughout the 90s because
| the price tag for new shiny processors is always higher,
| and it was not uncommon for customers to favor more or
| faster RAM/Disk space/graphic card/sound card (that was a
| thing back then) over better-looking CPU benchmarks.
| spauldo wrote:
| 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.
| winrid wrote:
| Man, I thought I was behind using a P3 in like 2007 lol. You
| can get something 100x faster for $1 :D
| avhon1 wrote:
| Debian (and many other distributors of compiled binaries)
| uses "i386" to refer to all 32-bit x86 processors, including
| the Pentium 3.
| accrual wrote:
| Hahah yeah, it's just a for fun/hobby PC. It's pretty beefy
| for what it is - 1.3GHz, 512MB RAM, 512GB SSD on a SATA card,
| fast AGP card. I can run a Debian desktop at 1080p on here.
| spauldo wrote:
| OpenBSD requires at least a Pentium these days.
| accrual wrote:
| Yep! I did some testing and found 6.8 was the final version
| to support 486 CPUs. The reason is the OpenBSD project
| switched to clang for the compiler in 6.9, and in the process
| became dependent on Pentium instructions.
|
| However, that doesn't stop one from installing a Pentium
| Overdrive in an old Socket 3 board and running the latest
| release. ;)
| potato-peeler wrote:
| > The overall disk usage for trixie is 403,854,660 kB (403 GB)
|
| What does this mean? If all 69k+ packages are installed, it will
| take up this much space?
| toenail wrote:
| As this also lists lines of code, it sounds more like sources
| plus packages. Think space that a full mirror (src + generic +
| arch specific packages) would need.
| tremon wrote:
| Indeed, this is the amount of space that a Debian mirror
| would need to host all Trixie packages. So it's the
| compressed packages total size, not the space it would take
| to have all packages installed simultaneously (which also
| happens to be impossible, because of package
| conflicts/alternatives and Debian supporting 7+ different
| architectures).
| ethan_smith wrote:
| The 403GB figure represents the total size of all source
| packages in the Debian archive, not the disk space required for
| a typical installation which is usually under 10GB for a
| desktop system.
| ACS_Solver wrote:
| 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 like the Debian documentation
| even if Arch remains the best on that front. I like the
| stable/testing package streams, which make it easy to choose old
| but rock-stable vs just a bit old and almost as stable.
|
| And one of the best parts is, I've never had a Debian system
| break without it being my fault in some way. Every case I've had
| of Debian being outright unbootable or having other serious
| problems, it's been due to me trying to add things from third-
| party repositories, or messing up the configuration or something
| else, but not a fault of the Debian system itself.
| zvmaz wrote:
| > after Ubuntu went way downhill and haven't had cause to
| regret it.
|
| In what way Ubuntu went downhill?
| happymellon wrote:
| Snaps? Proprietary package managers are never great.
| mmcnl wrote:
| I don't really understand why this is such a big problem.
| You don't have to use snaps.
| yjftsjthsd-h wrote:
| You really have to work to avoid them; ex. `apt install
| firefox` will install the snap
| bayindirh wrote:
| You're right. You don't have to use snaps. Ubuntu
| migrates packages slowly in behalf of you.
|
| Using apt to install some packages installs snap plumbing
| and downloads the package as a snap automatically. You
| don't have to install it manually.
|
| There's no malicious intent though, it's made to "impose
| a positive pressure on the snap team to produce better
| work and keep their quality high" (paraphrased, but this
| was the official answer).
| hsbauauvhabzb wrote:
| And one of these migrations broke my workflow
| substantially enough that a dist-upgrade turned into a
| complete system reformat to Debian and cost hours that I
| couldn't afford.
|
| Debian has been a safe haven since.
| ants_everywhere wrote:
| Installing the inferior snap packages when you apt get is
| one of the worst cases of a Linux distro refusing to
| respect the user's intent that I've experienced.
| LeoPanthera wrote:
| You sort of do. It's really hard to avoid them, because
| they've modified "apt" to install snaps by default
| without asking.
| npteljes wrote:
| 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 contests either.
| Santosh83 wrote:
| 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 for
| some strange reason Canonical decided not to allow snap
| that freedom.
| bayindirh wrote:
| Another problem is, Canonical promised to release server
| components and enable alternative stores, and just
| _forgot_ that they made that pledge.
|
| Also, rugpulling users and migrating things to snaps
| without asking their users in order to "create a positive
| pressure on snap team to keep their quality high" didn't
| sit well with the users.
|
| > 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
|
| But, for any size of fleet from homelab to an enterprise
| client farm, I can host my local flathub and install my
| personal special-purpose flatpaks without paying anyone
| and thinking whether my packages will be there next
| morning.
|
| Freedom matters, esp. it that's the norm in that
| ecosystem.
|
| I was neutral-ish about Ubuntu, but I flat out avoid them
| now, and migrate any remaining Ubuntu server to Debian in
| shortest way possible.
|
| I'm using Debian for the last 20 years or so, BTW.
| npteljes wrote:
| Yes, same. I started with Ubuntu back in the day, because
| the server I inherited ran Ubuntu, and it was just
| natural after that for me to run it on the desktop as
| well. I grew to dislike their NIH over the years, tried
| distro hopping, and settled on Debian.
| npteljes wrote:
| Yes, I agree. Snaps or Flatpak, not much of a practical,
| technological difference. What sets them apart is the way
| the distribution is handled, including the open source
| availability of the backend, which enabled for example
| Red Hat and Elementary to run their own stores.
| type0 wrote:
| 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.
| dismalaf wrote:
| 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...
| fsflover wrote:
| https://news.ycombinator.com/item?id=44849691
| npteljes wrote:
| 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.
| dismalaf wrote:
| > Mint is not part of the discussion.
|
| Read the parent comment I responded to
| sofixa wrote:
| > 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 time) and abandon stuff, which doesn't help
| their future causes.
| jeltz wrote:
| Canonical did their own NIH init daemon called Upstart
| which failed due to the fundamental design and the
| implementation being plain bad. Redhat builds better
| software which is why their NIH gets more adoption.
| curt15 wrote:
| ChromeOS still uses upstart.
| teddyh wrote:
| Upstart came before systemd; much of the reason for
| systemd's creation was fixing what was considered
| fundamental design mistakes in Upstart: <http://0pointer.
| net/blog/projects/systemd#:~:text=On%20Upsta...> (under
| the heading "On Upstart").
| homebrewer wrote:
| > systemd
|
| https://bbs.archlinux.org/viewtopic.php?pid=1149530#p1149
| 530
|
| > like systemd-resolved and timed
|
| They're not forced on anybody, they're not required by
| systemd, and many distributions use more feature-rich
| alternatives (including, afaik, RHEL -- last time I
| looked at it, they used dnsmasq and chrony). They're also
| often shipped as separate optional packages:
| $ apt search 'systemd-timesyncd|systemd-resolved'
| systemd-resolved/testing,now 257.7-1 amd64 systemd-
| timesyncd/testing 257.7-1 amd64
|
| > podman, buildah
|
| Still not anywhere near as popular as Docker. Although
| technically they're far better than Docker, and if anyone
| is using them, it's for that reason.
|
| > dnf
|
| Only used by RHEL and its upstream Fedora?
|
| ---
|
| All of this makes very little sense.
| yjftsjthsd-h wrote:
| >> podman, buildah
|
| > Still not anywhere near as popular as Docker. Although
| technically they're far better than Docker, and if anyone
| is using them, it's for that reason.
|
| NIH packages are generally expected to be less popular,
| yes. They have some technical merit, though in my opinion
| that's mostly trade-offs rather than one being strictly
| better than the other. I would be surprised if everybody
| using them is using them because of technical merit as
| opposed to it being pushed by the distro.
| ACS_Solver wrote:
| Red Hat builds really good stuff. NIH is sometimes right
| because nobody invented the stuff at all. Standard Unix
| tools are great but they don't solve everything, so we've
| ended up with most distros having "the Debian way" or
| "the Red Hat way", the main difference of course being
| deb/apt/dpkg vs rpm/yum/dnf. When building an embedded
| system with Yocto, the basic choices are also Debian or
| Red Hat style, though you can of course do anything.
|
| Special mention goes to NetworkManager, which has become
| the de facto standard way to configure networking because
| it's good. And with nmcli I can even remember how to
| connect to wifi from single user mode.
| npteljes wrote:
| >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.
| the_why_of_y wrote:
| A major difference is that Canonical projects have
| copyright assignment policies, while Red Hat projects
| don't - this probably explains a lot of the difference in
| adoption dynamics.
| tasuki wrote:
| I'm with my neighbor comments. How do you use Ubuntu
| without snaps? The base Ubuntu install already comes with
| several snaps. Installing random things through apt leads
| to snaps. I personally do not know how to avoid snaps on
| Ubuntu.
| justinclift wrote:
| I made this snap "alternative" to solve this exact
| problem: https://github.com/justinclift
|
| Packaged as: https://github.com/justinclift/snapd-
| empty/releases/download...
|
| It's just an empty package that _tells_ the system snap
| is installed, to stop the broken dependency chains you
| otherwise get from force uninstalling snap.
|
| It's been working fine on a handful of Ubuntu 24.04
| systems I've been handed and can't change the OS of, for
| about half a year now.
| mkesper wrote:
| You migrate to Debian. Everything else is a bandaid that
| can be rug pulled any time Canonical feels like doing so.
| L3viathan wrote:
| You uninstall all snaps, uninstall snapd, and block it
| from being installed via APT.
|
| Then you add e.g. the mozilla PPA such that its firefox
| package gets installed instead.
| superb_dev wrote:
| If you use Ubuntu, yes you do. It's why I ditched Ubuntu
| wkat4242 wrote:
| Yes you do. Some packages aren't available anymore in apt
| Santosh83 wrote:
| As I understand it, snap the package format is _not_
| proprietary. Its as open source as say flatpak. What is
| proprietary is Canonical official snap store, and they
| patch their version of snap to _only_ use that store. It 'd
| be the same as flatpak being tied to only flathub.
|
| Of course that goes against the spirit of FOSS, but there's
| a bit more nuance there than simply saying "snaps are
| proprietary".
| bayindirh wrote:
| Did they release the server components for hosting your
| own snap repositories, yet?
|
| I can't seem to find it. Any pointers would be helpful,
| so at least I can know the latest state of this thing.
| curt15 wrote:
| Snapd still hardcodes Canonical's snap store signing key
| and provides no mechanism to add your own keys. Any other
| snap repos will be treated as second class citizens.
| dismalaf wrote:
| No, but it's trivial to implement since Snap is open
| source so you know exactly what sort of payload it wants.
| tannhaeuser wrote:
| Snaps don't just suck from an ideological but also
| practical perspective, as described for Thunderbird.
| Firefox on Ubuntu has also serious permission issues with
| webcam support OOTB even experts are struggling with
| (involving AppArmor, pipewire, snap, and FF device
| config). and has become unusable for things like browser-
| only MS Teams on mainstream notebooks.
|
| Containers, popular as they may be on servers, can only
| add breakage and overhead to desktops, especially for an
| established and already much better organized system like
| Debian's apt. There just haven't been any new desktop
| apps for way over a decade that would warrant yet another
| level of indirection.
| bombela wrote:
| In addition, applications under snap are much slower to
| start. That's just not acceptable.
| BearOso wrote:
| I've tried making snap packages, but I discovered they're
| very tightly tied to Ubuntu's base packages. They're not
| portable at all. In essence they're effectively just a
| secondary Ubuntu-specific package format for user-level
| applications.
|
| For example, with flatpak you select a base runtime for
| your package that contains mostly system-agnostic
| libraries. With snap, you specify an Ubuntu version as a
| base runtime and additional dependencies that are Ubuntu
| packages.
| bloomca wrote:
| My understanding is that the base layer (similar to what
| FlatPak provides) is shared and downloaded by the snap
| manager so it is portable as long as you want to download
| it.
|
| The end result should be similar to FlatPak where you
| have practically no dependencies as it should package
| almost everything.
| happymellon wrote:
| > If I try to manipulate what you are talking about, I
| can attempt to frame something as open source which
| isn't.
|
| I didn't say "the snap format".
|
| The server isn't, and the client is hostile to using an
| alternative server. Snaps are a solution, and picking out
| one piece is deceptive.
| yjftsjthsd-h wrote:
| Snaps, and ads in the motd
| bayindirh wrote:
| Plus reduced support duration to increase adoption of
| Ubuntu Pro. Changing some packages ever slightly so they
| behave a little differently.
|
| Switch to sudo-rs, uu-coreutils (rust based stuff), etc.,
| etc.
|
| It's not a Debian derivative anymore. It's something else.
|
| Was not my cup of tea before, it's even more not my cup of
| tea now.
| john01dav wrote:
| Switching to rust-based system software is very different
| from the clearly profit seeking (or control seeking which
| is just long term profit seeking) changes like ads and
| snap (with massive friction to not using snap).
| bayindirh wrote:
| Yes, but I prefer glibc + GNU Coreutils based systems in
| my installations. They're additional nails on top of the
| (fatal) ones like snap, Ubuntu Pro and MOTD ads.
| Eduard wrote:
| all the weird proprietary Canonical stuff they try to put
| into vanilla Debian and have it replace common stuff.
|
| snap, lxd (not lxc!), mir, upstart, ufw.
|
| It's neverending, and it's always failing.
| rahen wrote:
| LXD was forked as Incus, and it's an absolute delight.
|
| Seamless LXC and virtual machine management with
| clustering, a clean API, YAML templates and a built-in load
| balancer, it's like Kubernetes for stateful workloads.
| JFingleton wrote:
| Incus is fantastic. I think Proxmox is where everyone is
| migrating to after the VMWare/Broadcom fiasco, but people
| should seriously consider Incus as well.
| nextos wrote:
| IMHO, it also became too complex, with too many things
| installed by default and too much upstream patching.
|
| This made it more fragile. It was really nice in the late
| 2000s, but gradually became worse.
| kev009 wrote:
| The alternative question to ask is: in what way has it gone
| uphill versus just using Debian?
|
| In the early days it had a differing and usually better
| aligned release schedule for the critical graphics stack.
|
| As a function of time, you are increasingly likely to get rug
| pulled once Shuttleworth decides to collect his next ransom.
| homebrewer wrote:
| > in what way has it gone uphill versus just using Debian?
|
| Their lawyers' willingness to risk shipping pre-built zfs
| kernel modules (that are always in sync with the kernel).
| Pretty important if you're into that sort of thing, it's
| easier to remove cruft once post-install than to keep an
| eye on DKMS for years (making sure that it hasn't
| disassembled itself and continues working).
| doublepg23 wrote:
| I forget the exact context but I recall an Ubuntu dev stating
| they have more users of the Firefox snap alone than trendy
| distros have entire users.
|
| I think it's worth keeping that in mind with all the hate
| Ubuntu gets. Most users are just silently getting their work
| done on an LTS they update every two years.
| bayindirh wrote:
| Well, I don't know which trendy distro the dev is
| referring, but Debian is complete opposite of Trendy. It's
| a bedrock distro silently running almost everywhere in some
| form or shape.
|
| Most of the Linux-based (enterprise and/or embedded)
| appliances are built upon Debian, for example.
|
| P.S.: The total number of Debian installations and their
| derivatives are unknown BTW. Debian installations and infra
| _do not collect_ such information. You can install
| "popularity-contest", but the question defaults to "no"
| during installation, so most people do not send in package
| selection lists, unlike Canonical's tracking of snap
| installations.
| Arrowmaster wrote:
| They have also had more malware on the snap store than all
| other distros have had in their official repos combined.
| ACS_Solver wrote:
| For me, it was a combination of Ubuntu breaking upstream and
| introducing its own unnecessary systems.
|
| I had a few issues caused by Ubuntu that weren't upstream.
| One was Tracker somehow eating up lots of CPU power and
| slowing the system down. Another was with input methods, I
| need to type in a pretty rare language and that was just
| broken on Ubuntu one day. Not upstream.
|
| The bigger problem was Ubuntu adding stuff before it was
| ready. The Unity desktop, which is now fine, was initially
| missing lots of basic features and wasn't a good experience.
| Then there was the short-lived but pretty disastrous attempt
| to replace Xorg with Mir.
|
| My non-tech parents are still on Ubuntu, have been for some
| twenty years, and it's mostly fine there. I wouldn't
| recommend it if you know your way around a Linux system but
| for non-tech, Ubuntu works well. Still, just a few months ago
| I was astonished by another Ubuntu change. My mom's most
| important program is Thunderbird, with her long-running email
| archive. The Thunderbird profile has effortlessly moved
| across several PCs as it's just a copy of the folder.
| Suddenly, Ubuntu migrated to the snap version of Thunderbird,
| so after a software update she found herself with a new
| version and an empty profile. Because of course the new
| profile is somewhere under ~/snap and the update didn't in
| any way try to link to the old profile.
|
| Then there were stupid things like Amazon search results in
| the Unity dash search when looking for your files or
| programs. Nah. Ubuntu isn't terrible by any means but for a
| number of years now, I'd recommend Linux Mint as the friendly
| Debian derivative.
| 28304283409234 wrote:
| Oh....snap.
| ocdtrekkie wrote:
| _Minutes_ to start Firefox on one of my machines.
| spauldo wrote:
| I'm an old-school user so I'm not exactly Ubuntu's target
| audience, but for Ubuntu was bad about a lot of the older,
| lesser-used bits of Linux.
|
| The two things I can remember were problems with NFS out of
| the box (outside having to install nfs-common, which I'm fine
| with) and apt-cache not displaying descriptions of packages.
| There were lots of other, minor annoyances that affected
| people like me but wouldn't affect someone who got into Linux
| desktops after, say, 2010. My memory sucks though so those
| are the two I remember. Yes, there were bug reports filed and
| yes, they sat in the tracker for years with no attention from
| Ubuntu.
|
| I wound up back on Debian once I got old enough that I didn't
| care about being behind the times a couple years.
| tmtvl wrote:
| Amazon ads in the Unity application menu (what was it called,
| 'lenses' or something?).
| ThatMedicIsASpy wrote:
| I've been always a Fedora person, still am. But my PC moved to
| Proxmox (debian) in 2023. Now a Fedora Atomic sits in a VM
| running flatpaks and podman containers :D
| madars wrote:
| >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 contrast, Ubuntu just
| uses newer kernels and -hwe avoids a lot of patch friction. So
| I still use Debian VMs but Ubuntu on bare metal. I haven't
| tried kernel from debian-backports repos though.
| bayindirh wrote:
| Which GPU, display server and compositor stack are you using?
| madars wrote:
| Integrated Intel GPU and no graphical system, just KMS VT
| (text console). That's what made it so frustrating - only
| displaying a console should not result in kernel panics
| under CPU load! Admittedly, the experience was anecdotal
| and years ago and I heard Debian is doing less of a RHEL-
| style "frankenkernel" now.
| bayindirh wrote:
| Intel's integrated GPU driver team, actually all driver
| teams, had a period of frequent screw-ups a while back
| (five years ago? Time flies). They also borked e1000e
| driver in the same period.
|
| On the other hand, I had and still have many Debian
| installations, some with Intel integrated graphics. None
| of them created any problems for a very, very long time.
| To be honest, I don't remember even any of my Intel iGPU
| systems crashed.
|
| ...and I use Debian for almost two decades, and I have
| seen tons of GPU problems. I used to write my Xorg.conf
| files without using man, heh. :)
|
| Maybe you can give Debian another chance.
| ACS_Solver wrote:
| drm/i915 was a pretty miserable experience for me on one
| machine. The Intel drivers for that chipset around the
| 5.3 kernel era weren't good, I recall lots of bug reports
| at the time. Below is one of the several issues that I
| was affected by
|
| https://gitlab.freedesktop.org/drm/i915/kernel/-/issues/6
| 73
| brirec wrote:
| 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...
| guerby wrote:
| 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.
| kasabali wrote:
| > Debian's heavy patching of kernel in Debian stable
|
| Needs citation.
|
| Debian stable uses upstream LTS kernels and I'm not aware of
| any heavy patching they do on top of that.
|
| Upstream -stable trees are very relaxed in patches they
| accept and unfortunately they don't get serious testing
| before being released either (you can see there's a new
| release in every -stable tree like every week), so that's
| probably what you've been bit by.
| raggi wrote:
| 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 continued to be so as AWS, GCP and others
| copied their kernel patch trees and blindly shipped the
| same problems to users and refused to respond to bugs and
| emails.
|
| You're right stability comes from testing, not enough
| testing happens around Linux period, regardless of which
| branch is being discussed.
|
| It's not easy testing kernels, but the bar is pretty low.
| bbarnett wrote:
| Bear in mind, LTS and ELTS are not Debian maintained.
|
| The wiki has more info on this.
| aragilar wrote:
| I think they mean the LTS kernels, not Debian's LTS.
| bbarnett wrote:
| Yes, seems so, thanks.
| kasabali wrote:
| Yep, I mean _longterm_ trees from
| https://www.kernel.org/, to be clear.
| pabs3 wrote:
| 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
| bbarnett wrote:
| https://news.ycombinator.com/item?id=44853371
| WD-42 wrote:
| One of the unsung praises of Arch is that it's turned
| thousands of users into testers. Before someone says
| "that shouldn't be the user's responsibility" I'm going
| to say I'm not so sure. We're all in this together. I'd
| rather deal with a bug or two on my desktop at home if it
| means it gets fixed before appearing in a distro that
| gets used for servers at work and causes issues there
| where the consequences are much higher.
| porridgeraisin wrote:
| I have a similar experience. My not-so-tech-savvy brother
| also has the same laptop setup I do (arch+XFCE). He knows
| to yay -Syyu and it's usually never a problem. The recent
| upgrade there was the vlc package split problem so I told
| him to hold on upgrading and that I'd come and do it.
| While I needed to sit and filter and install the optional
| dependencies myself for my upgrade, a week later it was
| already figured out (based on user feedback I assume) and
| the usual yay -Syyu installed just the right optional
| dependencies.
| specproc wrote:
| I don't consider myself particularly adept with linux.
| I've only been running it daily on the desktop for the
| last few years and, aside from mucking around with TWMs,
| I've not done much poking about with the internals.
|
| Despite the reputations, I've had far fewer issues on
| Arch-based desktop distros than back when I was rolling
| Ubuntu and Debian.
|
| That said, Debian on a server every time.
| porridgeraisin wrote:
| Yeah same. I think the release cycle actually doesn't
| matter at all. The reason for it is that the majority of
| breakage are caused by components/extensions of gnome and
| kde and non-DE-yet-complex software in distros with a lot
| of those present out of the box, like manjaro, breaking
| backwards compatibility every other week.
|
| When people switch to arch they typically set things up
| from scratch, end up choosing simple tools and avoid most
| of the unstable stuff distros push onto you.
| zozbot234 wrote:
| > One of the unsung praises of Arch is that it's turned
| thousands of users into testers.
|
| You can do that well enough with Debian's "testing" and
| "unstable" release channels. Aside from the few months
| leading up to a new "stable" release, which usually isn't
| a big deal (and fixing regressions in "stable" should
| then be a higher priority anyway). Just don't install it
| on systems that you actually depend on to keep working.
| But running it on your desktop at home that you only use
| to play and experiment with is just fine.
| yjftsjthsd-h wrote:
| AFAICT, the patches are here:
| https://salsa.debian.org/kernel-
| team/linux/-/tree/debian/lat...
|
| Whether that qualifies as "heavy" or not is of course a
| matter of opinion, but it's not nothing.
| kasabali wrote:
| IMO, considering the size and scale of the kernel
| (millions of lines of code, variety of architectures
| supported, # of subsystems and ridiculous amount of
| device drivers ), these patches might as well be counted
| as nothing. I'd say they're basically shipping a pristine
| kernel :D
| jama211 wrote:
| Classic Linux user response. Jeez...
| seba_dos1 wrote:
| The upstream kernel already backports enough regressions on
| its own to its stable releases, Debian's kernel team does not
| help them too much with that.
| djfobbz wrote:
| Yeah, I ditched Ubuntu Server after too many upgrade headaches.
| I manage 75+ VPS instances for app hosting, and it's nerve-
| wracking doing maintenance updates knowing there's a chance one
| won't boot after. That's easily an extra 1-2 hours per VPS just
| to get it back. Switched to Debian back in the 8.x days in 2015
| and it's been smooth sailing. Never had it break unless I was
| the one who messed it up.
| 9cb14c1ec0 wrote:
| Me too. All the server software (postgres, caddy, bun, etc)
| I'm using runs just fine on Debian, and I never have had
| updates break something on my Debian servers.
| foresto wrote:
| > I like dpkg, I like the Debian documentation even if Arch
| remains the best on that front.
|
| That's curious, because when I was learning to make Debian
| packages, I found the official documentation to be far better
| than I had seen from any other distro. The Policy Manual in
| particular is very detailed, continually improving, and even
| documents incremental changes from each version to the next.
| (That last bit makes it easy for package maintainers to keep up
| with current best practices.)
|
| Does Arch have something better in this department?
|
| Are you perhaps comparing the Arch wiki to Debian's wiki? On
| that front I would agree with you.
| rbanffy wrote:
| 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.
| JackeJR wrote:
| Just have sane firewall rules and you are good. E.g. if I
| install openssh-server and it auto starts, it doesn't make it
| out of my machine because my nftables does not allow inbound
| on port 22. It's just knowing the default behaviour and
| adjusting your practices for it.
| teo_zero wrote:
| Aren't firewall rules part of the "configuration" the OP
| talked about?
| mjochim wrote:
| No, because you can install and configure the firewall
| before you install package X. (without knowing anything
| about X, your firewall defaults can just prevent X from
| doing anything)
|
| But you can't (easily) configure package X itself before
| you install it; and after you install it, it runs
| immediately so you only get to configure it after the
| first run.
| johnisgood wrote:
| That is a workaround for a ridiculous issue.
| rbanffy wrote:
| A sane firewall won't protect you from privilege escalation
| from a local attacker. While unlikely, this is one more
| breach that could be exploited.
| bayindirh wrote:
| Debian bundles AppArmor profiles for most services. This
| will prevent an attacker from accessing outside the
| perimeter drawn by the AppArmor profile.
| Linux-Fan wrote:
| It is a well-known issue with probably less well-known
| solutions, cf.
| <https://unix.stackexchange.com/questions/723675/debian-
| ubunt...> echo exit 101 > /usr/sbin/policy-
| rc.d chmod +x /usr/sbin/policy-rc.d
|
| I think this is the recommended way to avoid autostarting
| services on Debian.
| rbanffy wrote:
| Good pointer. I remember learning it, and then forgetting
| it. Probably more than once.
|
| Still should be the default behavior.
| heresie-dabord wrote:
| Debian is my foundation. I keep servers on Old Stable and test
| new release features on an ephemeral system.
|
| I learned nftables with Bookworm and labwc with Trixie.
|
| labwc supports Wayland with Openbox configuration.
| jraph wrote:
| Why do you remain on old stable instead of stable?
| umvi wrote:
| Do you usually update in place or do a fresh install whenever a
| new major version comes out?
| madphilosopher wrote:
| I always update in place. And I follow all the upgrade
| procedure advice in the release notes.
| vwwvwvwv wrote:
| https://www.dropbox.com/scl/fi/ntqc4lod82qxnajuubvu3/ww.jpg?...
| jlarocco wrote:
| > And one of the best parts is, I've never had a Debian system
| break without it being my fault in some way. Every case I've
| had of Debian being outright unbootable or having other serious
| problems, it's been due to me trying to add things from third-
| party repositories, or messing up the configuration or
| something else, but not a fault of the Debian system itself.
|
| You're not trying hard enough ;-)
|
| I have Debian on an old MacBook Pro and had it on an even older
| iMac, and I've had a few problems over the years. Always with
| proprietary drivers - WiFi, graphics, webcams, etc. - Apple
| really don't want people using free software on their hardware.
| There's always been a fix, but there have been a few stressful
| moments and hoops to jump through.
|
| But it's definitely my favorite distro, and I run it everywhere
| I can. Pretty much always "just works" anywhere but Apple.
| MrDarcy wrote:
| I'm not trying hard enough. Feel the same as you and GP for
| two decades and counting.
| Galanwe wrote:
| You don't mention say what you like specifically about Debian,
| most of what you wrote could be said for a lot of
| distributions.
|
| So here is what I _don't_ like about Debian :-)
|
| - I don't like Debian package tooling (dpkg, debootstrap, de
| build...). Actually I hate everything about the experience of
| Debian packaging. Every time I package for Debian, I end up
| with a messed up setup of chroots and have to make triple sure
| nothing leaked from my environment.
|
| - Debian has a habit of repackaging everything at their own
| sauce, disregarding upstream philosophy. Debian packages will
| have their own microcosm of configuration directories,
| defaults, paths, etc. orthogonal to what a pristine
| installation look like.
|
| - Debian has the annoying habit of default starting installed
| services. So you always have to dance around your configuration
| management to disable services, install them, configure them,
| then restart them.
| exe34 wrote:
| I think this is all true, but the "being my fault" part has
| gotten better for me with nixos. Broke it? just reboot into the
| previous version and get configuration.nix back from git. I had
| to reinstall exactly once in 2016 shortly after the first
| install, but I don't know what I did wrong. the third time I
| installed nixos was last week when I bought a new computer that
| came with Windows.
| throwaway81523 wrote:
| 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.
| dotancohen wrote:
| 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.
| jraph wrote:
| What do you expect Debian to do today about this 17 years old
| incident?
| StopDisinfo910 wrote:
| > I like Debian's measured pragmatism with ideology
|
| There is plenty that could be said of Debian but as far as I'm
| concerned that's not part of it.
|
| Debian patches software for purely ideological reasons because
| they think they are not free enough. That's not pragmatism.
| That's the reverse of pragmatism. It certainly is a real drag
| on the teams developing the software they try to ship.
| KronisLV wrote:
| > And one of the best parts is, I've never had a Debian system
| break without it being my fault in some way.
|
| https://blog.kronis.dev/blog/debian-updates-are-broken
|
| https://blog.kronis.dev/blog/debian-and-grub-are-broken
|
| Then again, I've had most software occasionally break, I'm
| thankful that Debian exists.
| gradschool wrote:
| > I've never had a Debian system break without it being my
| fault in some way.
|
| My experience has been contrary to that. I'm a Linux user of
| 25+ years with various distros but about half of that time with
| Debian as my main desktop. I broke up with Debian about ten
| years ago thinking we could still be friends, but every time
| I've tried to put it on a new box it since then something weird
| has happened, most recently about a month ago on a completely
| new Intel N150, when it gave me some stick about video modes.
| Today my laptop got hosed by an attempted upgrade from bookworm
| to trixie, as in tons of error messages and then no more docker
| and no more virtualbox. No harm done because Debian taught me
| long ago to store a copy of the whole root filesystem on
| external media before an upgrade, but now the clock is ticking
| until I have to migrate off it or get stuck with something too
| old to be compatible with anything.
| master_crab wrote:
| _Debian 13 trixie includes numerous updated software packages
| (over 63% of all packages from the previous release)_
|
| I'm not familiar with the metric definition they use, but I'd be
| worried if close to 100% of the packages they included in
| bookworm hadn't been updated in the roughly 2 years between
| releases.
|
| I use Debian for most of my servers, so I'm sure there is a valid
| explanation of that phrase.
| baobun wrote:
| > I'd be worried if close to 100% of the packages they included
| in bookworm hadn't been updated in the roughly 2 years between
| releases.
|
| Code doesn't "go bad" and not everything is affected by
| ecosystem churn and CVEs.
|
| An established package not having updates for 2y is not in and
| of itself problematic.
| bbarnett wrote:
| I don't know why you think it would be different. Are you
| concerned about security updates? That's not part of the
| metric, as far as I can see.
|
| And even if it was?
|
| If you look at the number of packages in Debian, only a small
| portion have CVEs. There are nearly 30k package sources, and an
| output of 60k binary packages.
|
| Yet we only get a few security updates weekly.
|
| Another example? Both trixie and bookworm use the same firefox
| ESR (extended release) version. Both will get updated when
| firefox forces everyone to the next ESR.
|
| Beyond that, some packages are docs. Some are 'glue' packages,
| eg scripts to manage Debian. These may not change between
| releases.
|
| Lastly, Debian actually maintains an enormous number of
| upstream orphaned packages. In those cases, the version number
| is the same (sometimes), but with security updates slapped on
| if required.
|
| From my perspective, outside of timely and quick security
| updates, I have zero desire for a lot of churn. Why would I?
| Churn means work. Churn means changed stability.
|
| We get plenty of fun and churn from kernel, and driver related
| changes (X, Wayland, audio/nic, etc), and desktop apps. And of
| course from anything running forward, with scissors, like
| network connected joy.
| duskwuff wrote:
| It's not uncommon for small software packages to go years
| between updates - either because they're a simple utility
| that's feature-complete and rarely needs bug fixes, or because
| they're data files (e.g. packages of icons or fonts) which
| might not need to change at all.
| AstroBen wrote:
| Debian stable is just that - unchanging between major Debian
| versions. They do however push security updates when necessary,
| so you're not missing out on those
| hsbauauvhabzb wrote:
| Any chance you know how they manage that? Surely not every
| package in the repos is supported for the entire 2 year
| cycle, so if a vuln comes out after a major refactor, it's
| surely not easy to backport the patch.
| AstroBen wrote:
| Theres some information here they've put out:
| https://www.debian.org/security/faq
|
| And yeah it must be an incredible amount of work to stay on
| top of all this
| pabs3 wrote:
| They auto-import CVE feeds into the security tracker, file
| bugs for Debian maintainers to fix the issues, curate the
| tracking data, coordinate with upstreams and other distros
| to get fixes and so on. Some more on the team web page.
|
| https://security-tracker.debian.org/ https://security-
| team.debian.org/
| aragilar wrote:
| If upstream makes no releases in that time, then there'll be no
| upgrades.
| binwiederhier wrote:
| Thank you to all the Debian volunteers that make Debian and all
| its derivatives possible. It's remarkable how many people and
| businesses have been enabled by your work. Thank you!
|
| On a personal note, Trixie is very exciting for me because my
| side project, ntfy [1], was packaged [2] and is now included in
| Trixie. I only learned about the fact that it was included very
| late in cycle when the package maintainer asked for license
| clarifications. As a result the Debian-ized version of ntfy
| doesn't contain a web app (which is a reaaal bummer), and has a
| few things "patched out" (which is fine). I approached the
| maintainer and just recently added build tags [3] to make it
| easier to remove Stripe, Firebase and WebPush, so that the next
| Debian-ized version will not have to contain (so many) awkward
| patches.
|
| As an "upstream maintainer", I must say it isn't obvious at all
| why the web app wasn't included. It was clearly removed on
| purpose [4], but I don't really know what to do to get it into
| the next Debian release. Doing an "apt install ntfy" is going to
| be quite disappointing for most if the web app doesn't work. Any
| help or guidance is very welcome!
|
| [1] https://github.com/binwiederhier/ntfy
|
| [2] https://tracker.debian.org/pkg/ntfy
|
| [3] https://github.com/binwiederhier/ntfy/pull/1420
|
| [4]
| https://salsa.debian.org/ahmadkhalifa/ntfy/-/blob/debian/lat...
| heywire wrote:
| Just wanted to say thanks for ntfy! I use it daily to notify me
| on events from my home Meshtastic node.
| tremon wrote:
| The maintainer has a short explanation here:
| https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1098866#10
|
| > The webapp is a nodejs app that requires packages that are
| not currently in debian.
|
| Since vendoring dependencies inside packages is frowned upon in
| Debian, the maintainer would have needed to add those packages
| themselves and maintain them. My guess is that they didn't want
| to take on that effort.
| winter_blue wrote:
| _> but several features in ntfy won 't be available through
| debian packaging due to missing golang and nodejs packages_
|
| Woah. Shouldn't Node and Golang be in Debian's official repos
| by now?
| baobun wrote:
| Yes but not all packages written in those languages are.
| jonp888 wrote:
| Nodejs itself is, but when you install a node project
| manually, you type npm install and wait while it downloads
| the 500 different packages it depends on.
|
| Debian follows the same philosophy as for other more
| traditional languages and expects that all these
| dependencies are packaged as individual Debian packages.
| baobun wrote:
| On the web part:
|
| Debian sources need to be sufficient to build. So for npm
| projects, you usually have a debian-specific package.json where
| each npm dependency (transitively, including devDependencies
| needed for build) needs to either be replaced with its
| equivalent debian package (which may also need to be ported),
| vendored (usually less ideal, especially for third-party code),
| or removed. Oh, and enjoy aligning versions for all of that.
| That's doable but non-trivial work with such a sizable
| lockfile. If I would guess the maintainer couldn't justify the
| extra effort and taking on combing through all those packages.
|
| I also think in either case the Debian way would probably be to
| split it out as a complementary ntfy-web package.
| esseph wrote:
| It might be a better idea to release this as a container (if it
| isn't already) to take care of the dependencies.
| yjftsjthsd-h wrote:
| https://docs.ntfy.sh/install/#docker
|
| > The ntfy image is available for amd64, armv6, armv7 and
| arm64. It should be pretty straight forward to use.
| leansensei wrote:
| Thank you for ntfy, it's such a useful piece of software!
| scbrg wrote:
| ntfy is a very useful tool. Thank you very much for making it
| and also for maintaining the ntfy.sh service for those of us
| too lazy to self host.
| StopDisinfo910 wrote:
| > As a result the Debian-ized version of ntfy doesn't contain a
| web app (which is a reaaal bummer), and has a few things
| "patched out" (which is fine).
|
| My advise to you is to deny all support from people using the
| Debian version of your software and automatically close all bug
| tickets from Debian saying you don't support externally patched
| software.
|
| You would be far from the first to do so and it's a completely
| rational and sane decision. You don't have to engage with the
| insanity that Debian own policies force on its maintainers and
| users.
| jraph wrote:
| I agree that maintainers should not be expected to support
| patched versions of their software, but as a user I like the
| Debian policies you call insane. I would actually pick Debian
| exactly because they are cautious with the dependencies.
| Venn1 wrote:
| I have been tracking Trixie on my Resolve workstation for the
| past couple of months. The only hiccup was that the latest kernel
| did not support the ondemand governor, so I had to build a custom
| kernel to fix that.
| sheerun wrote:
| Debian was often the only linux os that worked on old
| "spacestations" of mine. Great sentiment
| sheerun wrote:
| And I mean Debian 12, not some old version, much more
| impressive
| spauldo wrote:
| Do you mean SparcStations?
| gcarvalho wrote:
| Looking forward to upgrade over the weekend.
|
| Have had my RPi on Debian since Debian 9, with smooth upgrades
| every time.
| imoverclocked wrote:
| I have used Debian starting sometime around slink. I still type
| "apt-get ..." and it still works reasonably well. There have
| definitely been hiccups in upgrades over the last 25+ years but
| the amount of time/effort dealing with those is almost nothing in
| comparison to other linux and non-OSS systems I've dealt with
| over the same span of time. My only regret is not contributing
| more to the community.
|
| The thing I like most about Debian is that you need to know at
| least a little about what is going on to use it. For me, it does
| a good job of following "as simple as possible and no simpler."
| Nursie wrote:
| Which one was slink?
|
| My first Debian install was in 1996. I had no real idea what I
| was doing, but it was amazing to me that I could remote-display
| windows from machines across campus, and it was alien compared
| to the windows 3.x/95 I was used to at that point. There was no
| apt at that point, or none that I was aware of, and adding new
| stuff was painful.
|
| I started using debian preferentially as my workstation/desktop
| OS in about 2005, and was installing it on embedded systems
| (linksys nslu2) to make micro servers by ... etch I think it
| was.
|
| By 2008 I was at IBM and they allowed a choice of windows or
| redhat on your laptop, and if you were adventurous there was
| experimental support for Ubuntu which _might_ work on Debian. I
| made it work and discovered that among 330k people there were
| 22 of us running it!
|
| Always loved it, it always just made more sense than other
| distros somehow. My daily driver is a Mac now, but I still have
| a few Debian machines around.
| markus_zhang wrote:
| When can we have Bandit or Bluey?
| Balinares wrote:
| Presumably not before Debian runs out of Toy Story characters.
| seba_dos1 wrote:
| ...and since there's Toy Story 5 scheduled for 2026, the pool
| of yet unused characters will become larger again soon.
| juujian wrote:
| 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.
| lucb1e wrote:
| 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
| esperent wrote:
| I've been testing Cinnamon on my Ubuntu machine recently. I
| was close to deciding to switch from Gnome but I keep running
| into an issue whenever I have long running tasks in Blender.
|
| In Gnome, Blender becomes unresponsive but everything else is
| still usuable. In Cinnamon, the entire system becomes
| unresponsive.
| bbarnett wrote:
| 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 <-- note the
| NIC name that will happen after reboot
|
| Here's a one-liner, excluding a bond interface and lo. Gives a
| nice list of pre and post change. for x in $(cat
| /etc/network/interfaces | grep auto | cut -d ' ' -f 2 | grep -Ev
| 'lo|bond0'); do echo -n $x:; udevadm test-builtin net_setup_link
| /sys/class/net/$x 2>/dev/null | grep NET_NAME| cut -d = -f 2;
| done
|
| The doc's logic is that after you've upgraded to trixie, and
| before reboot, you're running enough of systemd to see what it
| will name interfaces after reboot.
|
| _So far_ I have not had an interface change due to upgrade, so I
| cannot say that the above does detect it.
| foresto wrote:
| 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
| champtar wrote:
| You can easily keep the current naming behavior with the
| 'net.naming_scheme=' kargs
| foresto wrote:
| I already have systems that use net.ifnames=0. My question
| is about whether this new behavior can affect them.
| champtar wrote:
| It'll not, the new behavior is just a new naming scheme,
| and you just choose not to use any, which is totally fine
| if you have a single NIC.
| champtar wrote:
| Hopefully the last breaking change.
|
| enoX should always stay stable, as it's the BIOS (in some ACPI
| table) telling that this device/port has this ID.
|
| ensX means the NIC in PCIe slot X, but in your PCIe tree you
| can have PCIe bridges, so technically you could have multiple
| NIC in the same slot (what the BIOS declare as a slot), so
| there was a lot of breaking NIC naming changes over the years
| in systemd to figure out the right heuristics that are safe,
| enabling/disabling slot naming if there is a PCIe bridge, but
| just in some cases.
|
| Also for historical reasons the PCIe slot number was read
| indirectly leading to some conflicts in some cases (this was
| fixed in systemd 257)
| dur-randir wrote:
| >Hopefully the last breaking change.
|
| Every year's cope with systemd.
| bayindirh wrote:
| Debian's signature feature (upgrade from stable to stable under
| 15 minutes) shines here too.
|
| My first system migrated in less than 10 minutes, incl. package
| downloads and reboot. It's not a beast either. N100 mini PC
| connected to a ~50mbps network.
| mr_sturd wrote:
| What was the process for this? Does it involve manually
| modifying the sources.lists files, or is there a single command
| to instigate the upgrade?
| bayindirh wrote:
| There are two main ways:
|
| If your sources file references the release name
| (e.g.:bookworm), you change them to trixie, then "apt update
| && apt dist-upgrade".
|
| or,
|
| If your sources file directly reference distro-suites (e.g.:
| stable), you just "apt update && apt dist-upgrade" since
| stable is now pointing to trixie.
|
| In the first reboot, you run "apt autopurge" to remove
| packages which are not needed anymore.
|
| ...and you're done.
| Pet_Ant wrote:
| It can be a little hard to navigate to so the .torrent links for
| x86-64 are
|
| Minimal: https://cdimage.debian.org/debian-cd/current/amd64/bt-
| cd/deb...
|
| Full: https://cdimage.debian.org/debian-cd/current/amd64/bt-
| dvd/de...
| duskwuff wrote:
| Note that you probably don't need the DVD ("full") image. Most
| users should use the "minimal" netinstall CD and download
| packages at install time.
| synack wrote:
| Agreed, but for laptops it's nice to keep a copy of the DVD
| iso on disk and in your apt sources so that you can install
| stuff offline.
| Pet_Ant wrote:
| I downloaded both because I intend to seed, but yes, if you
| have a fast internet connection then minimal is perfect...
| but if you are on a crappy third-world connection where it
| might take all day to get the image, it's nice to have it all
| in place when you are ready to install.
| wltr wrote:
| It baffles me I keep searching for these files every time I
| want to download Debian. And it's been like that for over a
| decade at least.
| pabs3 wrote:
| They are linked from the "Other downloads" page linked from
| the front page.
| wltr wrote:
| Yeah, I think I remember that, but each time I'm puzzled
| and not sure. It feels like they hid that deliberately.
| While Arch is the opposite, it's so easy to get the torrent
| file.
| yonatan8070 wrote:
| 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 and IBM System z being used these
| days? Are there modern Linux systems being deployed with
| something other than amd64, arm64, and (soon?) riscv64?
| kev009 wrote:
| Both Power and z are many billion dollar businesses each.
| Banking and other high finance is the stronghold for both. IBM
| still seems proud of z, Power seems merely tolerated these days
| which is a shame because it is a nice ISA and the systems are
| very nice too.
| Palomides wrote:
| 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
| pabs3 wrote:
| 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.
| ndiddy wrote:
| 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.
| snvzz wrote:
| Very important to note the lack of x86 (32bit x86) support.
|
| The end of an era.
| Nursie wrote:
| > I do wonder, where are PowerPC and IBM System z being used
| these days?
|
| IBM.
|
| And they own redhat, so I imagine they put a lot of time and
| money into making the kernel work.
|
| Why Debian in particular, not sure.
| Narishma wrote:
| > 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.
| yjftsjthsd-h wrote:
| 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?
| jabl wrote:
| 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.
| Linux-Fan wrote:
| I have a few old PCs (towers) here which don't support amd64
| mostly Pentium 4-based.
|
| They all still have DVD reader drives and are nice for
| ripping CDs. Despite the fact that the drives are nearing 20
| years of age (machines are from ~2005) they still perform
| better than most "new" external drives. Of course one could
| also move the drives to a newer machine but many of them use
| the IDE connector which is not commonly found on modern
| systems. Also, modern cases typically don't account for
| (multiple) 5.25" drives.
|
| The other use case is to flash microcontrollers. When
| fiddeling around with electronics there is always a risk of a
| short circuit or other error that could in worst case kill
| the attached PC's mainboard. I feel much safer attaching my
| self-built electronics to an old machine than to my amd64
| workstation.
|
| Due to their age, I think the old machines may not live much
| longer -- I fear not even 10 more years, some of my old
| 32-bit laptops have already failed. Hence even for me it does
| not make sense to try keeping up the software support. Maybe
| I switch them to a BSD or other Linux distribution if they
| live long enough but for now the machines run OK with Debian
| Bookworm (newly oldstable), too.
| Narishma wrote:
| In my case I have a couple of first gen 32-bit Atom netbooks
| that I use regularly for the same things I've always used
| them for. The hardware still work just fine so I see no
| reason to replace them.
| krylon wrote:
| As an owner of two i386 systems (both netbooks built around
| Intel's Atom N270), that run Debian, I am a little sad. I
| understand the reasoning, and I won't deny it is a very niche
| platform by now. But I had hoped Debian, with a history of
| supporting a wide range of platforms, would keep i386 going for a
| while longer.
|
| Fortunately, bookworm will continue to receive updates for almost
| 3 years, so I am not in a hurry to look for a new OS for these
| relics. OpenBSD looks like the natural successor, but I am not
| sure if the wifi chips are supported. (And who knows how long
| these netbooks will continue to work, they were built in 2008 and
| 2009, so they've had a long life already.)
|
| EDIT: Hooray, thanks to everyone who made this possible, is what
| I meant to say.
| dschuessler wrote:
| Out of curiosity, what do you use these netbooks for?
| krylon wrote:
| One sits in my bathroom so I can browse random Wikipedia
| articles while I'm, uh, busy. The other one sits on my
| nightstand and plays audiobooks/podcasts when I'm going to
| sleep.
|
| So nothing critical. But something they are still good at,
| and being very small makes them a natural fit for these use
| cases.
| thiht wrote:
| Curious, why not use your phone for both these use cases?
| Seems like it would be even more convenient
| CogitoCogito wrote:
| I can't speak for the other poster, but I like the idea a
| lot. Having tools with specific purposes means I can
| avoid using my phone for everything. No matter what games
| I play to remove notifications/interruptions/etc. it's
| always a distraction and easy to be distracted from
| whatever I originally intended to use the phone for.
| krylon wrote:
| I do use the phone for audible, but I started both uses
| before I had a smart phone (I was very late to the game),
| and I am a creature of habit. Plus the netbook has a
| bigger display, more storage, and a real keyboard (again,
| creature of habit).
| homebrewer wrote:
| Alpine supports i686, I see no current deprecation plans. This
| may change in the next three years though, who knows.
| anthk wrote:
| OpenBSD runs perfectly fine. Atom netbook, n270, 1GB of RAM,
| cwm+git dillo (plus DPI plugins), mpv+yt-dlp.
|
| My ~/.config/mpv/config: #inicio
| ytdl-format=bestvideo[height<=?480][fps<=?30]+bestaudio/best
| vo=gl audio-pitch-correction=no
| quiet=yes pause=no vd-lavc-
| skiploopfilter=all demuxer-cache-wait=yes
| demuxer-max-bytes=4MiB #fin
|
| My ~/yt-dlp.conf #inicio de fichero
| --format=bestvideo[height<=?480][fps<=?30]+bestaudio/best
| #fin de fichero
|
| For the rest, I use streamlink from virtualenv (I do the same
| with yt-dlp) with a wrapper at $HOME/bin:
|
| yt-dlp wrapper #!/bin/sh .
| $HOME/src/yt-dlp/bin/activate $HOME/src/yt-
| dlp/bin/yt-dlp "$@"
|
| streamlink wrapper #!/bin/sh
| . $HOME/src/streamlink/bin/activate
| $HOME/src/streamlink/bin/yt-dlp "$@"
|
| To install streamlink mkdir -p
| ~/src/streamlink cd ~/src/streamlink
| virtualenv . . bin/activate
| pip3 install -U streamlink
|
| The same with yt-dlp: mkdir -p ~/src/yt-dlp
| cd ~/src/yt-dlp virtualenv . .
| bin/activate pip3 install -U yt-dlp
|
| On the rest, I use mutt+msmtp+mbsync, slrn, sfeed, lynx/links,
| mocp, mupdf for PDF/CBZ/EPUB, nsxiv for images, tut for
| Mastodon and Emacs just for Telegram (I installed tdlib from
| OpenBSD packages and then I installed Telega from MELPA).
|
| Overall it's a really fast machine. CWM+XTerm+Tmux it's my main
| environment. I have some SSH connection open to somewhere else
| at the 3rd tag (virtual desktop), and the 2nd one for Dillo.
| krylon wrote:
| Thank you very much!
| UncleSlacky wrote:
| antiX will be creating a Trixie-based 32-bit ISO. There's also
| Void, Alpine and Slackware (at least).
| kachapopopow wrote:
| Plasma 6.3 - I can finally ditch kde neon.
| ACS_Solver wrote:
| 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 locally built versions of Kate and Konsole without
| issue.
| foresto wrote:
| > 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.
| jpetso wrote:
| 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 unsupported version for another two years or
| however much.
|
| Debian is great for what it is, but you better hope you
| don't run into issues with your desktop environment because
| they will not be addressed.
| spauldo wrote:
| 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.
| charcircuit wrote:
| So what is the actual difference. These release notes are not
| very clear. They just give version bumps. How can people get
| excited when you give them nothing to get excited about?
| aborsy wrote:
| The difference between Debian and Ubuntu is decreasing with each
| release recently. I was pleasantly surprised that Debian
| recognized all hardware components in my laptop released one year
| ago out of the box.
|
| Hardware support is good and UI is great! It feels snappier than
| Ubuntu, may be due to lack of snap and fewer services and
| applications installed by default.
| sohrob wrote:
| I love Debian and have a tremendous amount of respect for the
| people who work on the project. I no longer use Debian, but I
| think it's vitally important to have an anchor Linux distribution
| which isn't overly reliant on a for-profit entity and is truly
| community driven.
| Santosh83 wrote:
| Arch isn't truly community driven?
| perdomon wrote:
| How soon can I update my raspberry pi 5 from Bookworm to Trixie?
| Does PiOS have to initiate that first?
| treve wrote:
| Raspberry Pi OS is a derivative and not straight up debian.
| It's not a released yet. A beta exists and looks like this one
| will support an in-place update
| kwk1 wrote:
| The images are a bit out of date, but check out
| https://raspi.debian.net/
| pss314 wrote:
| A new APT sources format "debian.sources" is announced with
| trixie. The now older "sources.list" format is still supported,
| but is likely to be deprecated in a future Debian release.
|
| See below: APT is moving to a different format
| for configuring where it downloads packages from. The files
| /etc/apt/sources.list and *.list files in
| /etc/apt/sources.list.d/ are replaced by files still in that
| directory but with names ending in .sources, using the new, more
| readable (deb822 style) format. For details see sources.list(5).
| Examples of APT configurations in these notes will be given in
| the new deb822 format. If your system is using
| multiple sources files then you will need to ensure they stay
| consistent.
|
| - https://wiki.debian.org/SourcesList#APT_sources_format
|
| - https://www.debian.org/releases/trixie/release-notes/upgradi...
|
| "apt modernize-sources" command can be used to simulate and
| replace ".list" files with the new ".sources" format.
| Modernizing will replace .list files with the new .sources
| format, add Signed-By values where they can be determined
| automatically, and save the old files into .list.bak files.
| This command supports the 'signed-by' and 'trusted' options. If
| you have specified other options inside [] brackets, please
| transfer them manually to the output files; see sources.list(5)
| for a mapping.
| __david__ wrote:
| > apt modernize-sources
|
| Oh nifty, I hand converted all mine a couple years back. It
| would have been nice to have that then (or know about it?). I
| do really like the new deb822 format, having the gpg key inline
| is nice. I do hope that once this is out there the folks with
| custom public apt repos will start giving out .sources files
| directly. Should be more straightforward than all the apt-key
| junk one used to have to do (especially when a key rotated).
| sgarland wrote:
| Same. It took me a little bit to get used to it; my initial
| snap judgment was "this will be more annoying to create via
| scripting," but then Ansible added deb822_repository [0] in
| 2.15 (shortly before Bookworm was released), and then it was
| no longer a concern.
|
| [0]: https://docs.ansible.com/ansible/latest/collections/ansi
| ble/...
| duskwuff wrote:
| Ooh, that's nice. Especially nice that it lets you specify both
| Suites: and Components: in the same stanza, so you don't have
| to repeat the rest of the line to add -updates and -backports
| suites.
| sgarland wrote:
| DEB822 was available from at least Buster [0]. I think Bullseye
| was the first release I used it in.
|
| [0]:
| https://manpages.debian.org/buster/apt/sources.list.5.en.htm...
| chupasaurus wrote:
| It was announced in 2015 with apt 1.1 which was a major change
| of configuration, different things from it are being enforced
| each release since.
| lucb1e wrote:
| > "trixie" includes numerous updated software packages (over 63%
| of all packages from the previous release)
|
| Wow, I'm amazed a third of packages haven't seen an update in,
| ehm _checks_
|
| > After 2 years, 1 month, and 30 days of development, the Debian
| project is proud to present its new stable version
|
| I'm a fan of old software myself, in the sense that I find it
| cool to see F-Droid having a (usually tiny) package that is over
| 10 years old but it does exactly what I want with no bugs and it
| works perfectly on Android 10. I wonder if those 30% more
| commonly fall in the "it's fine as it is" category or in the "no
| maintainers available" category
| luismedel wrote:
| Kudos to the team.
|
| My first contact with Linux was with Debian 2.1. Exactly with
| this distro CDs https://archive.org/details/linux-
| actual-06-2/LinuxActual_01...
|
| To be honest, it was a miserable experience to install it on your
| main computer without anything else available to look for help in
| case of problems. It was also hard to really try it due to lack
| of drivers for current (at that moment) ADSL modems.
|
| But here I am a crapload of years later, still loving it :-)
| dismalaf wrote:
| 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.
| natebc wrote:
| Lots of debian love in this thread and it's great to see. If
| you're so inclined I encourage you to donate to Debian. We're all
| better off the more support goes to an ecosystem and operation
| like Debian.
|
| https://www.debian.org/donations
|
| Not affiliated, just a happy user for a long, long time.
| pabs3 wrote:
| Lots of other ways for individuals, companies and other
| organisations to help too:
|
| https://www.debian.org/intro/help
| fhdnfjf wrote:
| I'm too impatient to use a non-rolling release distro like Debian
| as my main OS, that, by my standards, already starts a new distro
| version with some outdated packages. I admire Debian though and
| it is my favorite server OS.
| JonChesterfield wrote:
| Testing is a rolling release. Unstable is a more exciting
| rolling release.
| theandrewbailey wrote:
| > The overall disk usage for trixie is 403,854,660 kB (403 GB)
|
| That's too big. I'm going to need a smaller distro.
| JonChesterfield wrote:
| You're unlikely to install everything in it.
| hsbauauvhabzb wrote:
| I'm sure it's small compared to some alternatives.
| Biganon wrote:
| You're probably being sarcastic, but in the eventuality you
| aren't, this is if you install every single package.
| LtdJorge wrote:
| No, it's actually the disk usage of hosting a full mirror,
| other users commented on that
| keernan wrote:
| Apparently Trixie needs a larger boot petition than prior
| versions and therefore I have to do new installs on three of my
| homelab machines - and probably my proxmox machine too. What a
| headache.
| o11c wrote:
| That sounds concerning, especially since Debian had hard-coded
| (!) a tiny /boot partition for encrypted disks for a long time.
| This already caused problems quite frequently (you have to
| manually delete them quite frequently, and which inhibits your
| ability to revert after a kernel regression - which, hm, I have
| noted to have been relatively common for Debian 12 "Bookworm"
| compared to usual ... hopefully Trixie is better, but if it
| makes the kernel-management problem harder that's a bad sign)
| shmerl wrote:
| Congrats to the Debian team!
| nodesocket wrote:
| I just upgraded a mini pc with no real issues. Main steps were:
| 1.) sudo apt-get update && sudo apt-get --yes upgrade && sudo
| apt-get --yes autoremove --purge 2.) Update all entries of
| bookworm to trixie in /etc/apt/sources.list. 3.) sudo apt
| full-upgrade 4.) sudo reboot 5.) sudo apt modernize-
| sources
| int_19h wrote:
| 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 is tainted: unmerged-
| bin. It is recommended to ignore this message. Merging these
| directories manually is unsupported and will break future
| upgrades. Further details can be found in bug #1085370.
|
| No option to disable this either, per discussion in
| https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085370
| jcgl wrote:
| You may not like it, but "arbitrary" isn't a fair description;
| there's reasoning behind it that is over 10 years old:
|
| http://0pointer.net/blog/projects/stateless.html
|
| https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor...
|
| That said, my knee-jerk is also that this is about strong-
| arming distros. Which leaves a bad taste in my mouth. I'd be
| interested to hear other viewpoints though.
| int_19h wrote:
| Note that this is about a different thing - Debian has also
| merged its /bin into /usr/bin, but now systemd also wants
| /usr/bin and /usr/sbin to be merged.
| Arnavion wrote:
| >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.
| kasabali wrote:
| > 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.
| spookie wrote:
| Lovely.
| TacticalCoder wrote:
| Debian choosing systemd (not that it's a new decision) is the
| reason I'll be switching my Proxmox to FreeBSD/bhyve (FreeBSD
| has great ZFS support btw).
|
| Once I get the hypervisor systemd-free (no systemd on FreeBSD),
| I can then install a minimal distro in a VM mean to do
| containerization (like, say, the Talos Linux distro for K8s,
| that only has a few executables and they're all immutable) and
| then I can run containers that, by design, have something that
| is precisely _not_ systemd as PID1.
|
| So life is good: there's a systemd-free world at the end of the
| tunnel.
| zahlman wrote:
| > Debian choosing systemd (not that it's a new decision) is
| the reason I'll be switching my Proxmox to FreeBSD/bhyve
|
| Did you consider Devuan? Or is this just taking one annoyance
| as motivation to fix others at the same time?
| creatonez wrote:
| 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.
| kasabali wrote:
| > Why do you think this is an attempt at a persuasion tactic
|
| Because they said so:
|
| > As part of that we sometimes adopt schemes that were
| previously used by only one of the distributions and push it
| to a level where it's the default of systemd, trying to
| gently push everybody towards the same set of basic
| configuration [1]
|
| 1. https://0pointer.de/blog/projects/the-biggest-myths.html
| ilvez wrote:
| Nice, more chaos to unstable again. Sincerely happy because of
| the release and new stable, but also selfishly happy because now
| unstable starts moving again.
| starkparker wrote:
| Maybe a niche concern, but SDL2 is still in Trixie. The
| sdl2-compat layer (translating SDL2 APIs to SDL3) is in testing,
| where SDL2 also exists side-by-side with it and is intended to be
| used to test and verify that SDL2 apps that use it are actually
| compatible.
|
| Night-and-day decision-making process compared to Fedora and
| Arch, which both replaced SDL2 with sdl2-compat, broke a bunch of
| SDL2 apps because sdl2-compat isn't actually SDL2-compatible yet,
| and sent everyone to yell at the SDL team about it.
| anthk wrote:
| 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.
| rs_rs_rs_rs_rs wrote:
| dpkg/apt in Debian fells slower even compared with dpkg/apt in
| Ubuntu, not sure why that's the case
| endorphine wrote:
| If you're upgrading, see
| https://www.debian.org/releases/trixie/release-notes/upgradi....
| LoveMortuus wrote:
| I'm very sad to see them drop support for 32-bit, since that is
| the computer on which I have been using Debian for the past 10
| years...
|
| Does anyone have any suggestions for a 32-bit distro that's still
| being updated?
| jama211 wrote:
| Linux mint technically still does, perhaps because they're
| lagging behind Debian. AntiX does but that has its own
| tradeoffs. With full potential respect for your situation, if
| you're not able to obtain 64 bit hardware, there's nothing that
| wrong with not upgrading your OS for now
| 2b3a51 wrote:
| Bookworm will get updates for another year if I have read the
| Debian Wiki correctly so perhaps there is no need for
| immediate action as Bookworm becomes oldstable?
|
| In addition to Mint and AntiX there is also Slackware (I use
| xfce rather than KDE) but adding software outside the (large)
| base install is not an 'apt-get thing' process.
|
| Salix Linux, based on Slackware, does have package
| repositories with a reasonable selection of applications.
| Salix is based on the stable Slackware 15.0 so has nicely
| aged packages.
|
| Void Linux also has an xfce4 based live i686 iso you can look
| at and decide to install from.
| morserer wrote:
| They only mentioned it briefly, and not by number, but this
| release includes 95%+ bit-for-bit reproducibility on AMD64,
| ARM64, and RISC-V across more than 30,000 packages (92% mean
| across all architectures).
|
| Congratulations to the team--phenomenal work!
|
| https://reproduce.debian.net/
| guerby wrote:
| Is there a tool on a given debian trixie system to know what
| installed packages are not currently reproducible?
|
| Alternative to parsing the reproduce web site :)
| morserer wrote:
| Yes! From the site: sudo apt install debian-repro-status;
| debian-repro-status
| andersa wrote:
| I've been using the Debian trixie branch for about a year now on
| my local server, never once had a real issue with anything. Very
| impressive.
| jjgreen wrote:
| I've been on Debian forever and love it to bits. But in an act
| which can only be described as batshit insanity, they have chosen
| to patch Python's pip3 in a manner which breaks the --prefix
| option. On Debian pip3 install <whatever>
| --prefix=/usr/local
|
| will install into /usr/local/local, so one has to use the prefix
| /usr. The same command on, say, OpenSuSE will install into /usr
| and break your system. Barking mad.
|
| https://sources.debian.org/src/python3.7/3.7.3-2+deb10u3/deb...
| zahlman wrote:
| > python3.7
|
| Certainly a terrible UX, but the motivation is clear: they're
| trying to get PEP 668 protections for older versions.
|
| Virtual environments work a lot better anyway, honestly. (With
| a properly crafted `pyvenv.cfg`, it should be possible to
| convince Python that your /usr/local is a virtual environment,
| but I can't be sure offhand if there are any serious negative
| consequences of that.)
| Aldipower wrote:
| Looking forward to 13! Debian 12 in combination with Pipewire is
| my go to daily use professional audio workstation for 2 years.
| Coming from Windows, there are no more forced updates anymore
| preventing me from doing my job. This is a releave. It works so
| good! Linux for professional audio is really an option now! Most
| high-end converters are connected via MADI or ADAT anyway, so
| there is no driver problem existent. Drivers are a consumer grade
| discussion..
| teleforce wrote:
| > The overall disk usage for trixie is 403,854,660 kB (403 GB),
| and is made up of 1,463,291,186 lines of code.
|
| This makes Debian Trixie about 32 times larger than Windows XP
| with approximately 45 millions lines of code, arguably the best
| Windows OS ever.
|
| Debian Trixie is released about 24 years after Windows XP.
| 3836293648 wrote:
| Sure, but XP came with minimal amounts of bundled software,
| that's every package in the debian repo.
| torium wrote:
| Ooo la la, GnuCash 5.10. I'm still on 4.4.
|
| Can't find release notes though, help?
|
| I've found the docs, but they're huge. I'll looking specifically
| for a list of differences between 4.4 and 5.10. (Or at least the
| biggest differences)
___________________________________________________________________
(page generated 2025-08-10 23:01 UTC)