[HN Gopher] Debian 13 "Trixie"
___________________________________________________________________
Debian 13 "Trixie"
Author : ducktective
Score : 425 points
Date : 2025-08-09 18:18 UTC (4 hours 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...
| 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.
| bryanlarsen wrote:
| Infinite scroll length on terminals can chew through /tmp, and
| systems misbehave strangely when they're out of /tmp.
| 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.
| 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.
| 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?
| 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.
| 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.
| 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:
| 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
| 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?
| 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".
| 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).
| 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.
| 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
| 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.
| 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.
| 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.
| 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.
| 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.
| 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.
| 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...
| 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.
| 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.
| 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
| 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.
| 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.
| leansensei wrote:
| Thank you for ntfy, it's such a useful piece of software!
| 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
| 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."
| 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
| 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
| 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.
| 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.
| 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
| 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.
| 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.
| 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?
| homebrewer wrote:
| Alpine supports i686, I see no current deprecation plans. This
| may change in the next three years though, who knows.
| 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.
| 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.
| 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.
| 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.
___________________________________________________________________
(page generated 2025-08-09 23:00 UTC)