Introduction
Introduction Statistics Contact Development Disclaimer Help
_______ __ _______
| | |.---.-..----.| |--..-----..----. | | |.-----..--.--.--..-----.
| || _ || __|| < | -__|| _| | || -__|| | | ||__ --|
|___|___||___._||____||__|__||_____||__| |__|____||_____||________||_____|
on Gopher (inofficial)
Visit Hacker News on the Web
COMMENT PAGE FOR:
Debian 13 “Trixie”
torium wrote 19 hours 3 min ago:
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)
teleforce wrote 1 day ago:
> 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 23 hours 35 min ago:
Sure, but XP came with minimal amounts of bundled software, that's
every package in the debian repo.
Aldipower wrote 1 day ago:
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..
jjgreen wrote 1 day ago:
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 --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.
[1]: https://sources.debian.org/src/python3.7/3.7.3-2+deb10u3/debia...
zahlman wrote 1 day ago:
> 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.)
MuffinFlavored wrote 15 hours 12 min ago:
python3.7 is from June 27th, 2018 [1] Why is that the default?
[1]: https://www.python.org/downloads/release/python-370/
zahlman wrote 13 hours 40 min ago:
I don't think it is? Or at least, it only was on some particular
older Debian release.
jjgreen wrote 4 hours 21 min ago:
I think that was the version the patch was introduced, it's
certainly in-place on Trixie (which has 3.13).
andersa wrote 1 day ago:
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.
morserer wrote 1 day ago:
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!
[1]: https://reproduce.debian.net/
MuffinFlavored wrote 15 hours 13 min ago:
Could you help me understand why the remaining 5% is not bit-for-bit
reproducible? For example... if you download a tar of sources pinned
to a version, and you run `./configure` and `make` in some kind of
container and it doesn't embed some kind of timestamp... why are 95%
reproducible and some aren't? Would like to learn/understand.
JonChesterfield wrote 14 hours 18 min ago:
Hashtables keyed off the address of objects would be an example.
On multiple runs, malloc gives out different addresses (thanks to
threads or security concerns) which means things end up in
different slots in the table. Then you iterate through it in memory
order and you're seeing objects in non-deterministic order, which
you do things with.
Embedding file paths / timestamps / git shas and similar was
popular for a while too and unhelpful for reproducible builds.
guerby wrote 1 day ago:
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 1 day ago:
Yes! From the site:
sudo apt install debian-repro-status; debian-repro-status
LoveMortuus wrote 1 day ago:
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?
account42 wrote 5 hours 27 min ago:
Gentoo still supports it but depending on what you want, compile
times with modern compilers on old hardware are a pain.
jama211 wrote 1 day ago:
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 20 hours 35 min ago:
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.
endorphine wrote 1 day ago:
If you're upgrading, see [1] .
[1]: https://www.debian.org/releases/trixie/release-notes/upgrading...
anthk wrote 1 day ago:
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 1 day ago:
dpkg/apt in Debian fells slower even compared with dpkg/apt in
Ubuntu, not sure why that's the case
starkparker wrote 1 day ago:
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.
account42 wrote 5 hours 25 min ago:
Well Fedora is the equivalent of testing for Red Hat and Arch is
Arch.
starkparker wrote 1 hour 43 min ago:
Even Arch kept SDL2 libs in the repo as a fallback. Fedora jumped
straight from SDL2 in the repo to sdl2-compat or nothing. The only
way to get consistent SDL2 builds on F42 is by building SDL2 from
source.
ilvez wrote 1 day ago:
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.
int_19h wrote 1 day ago:
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
[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085370
creatonez wrote 1 day ago:
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 22 hours 47 min ago:
> 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.
[1]: https://0pointer.de/blog/projects/the-biggest-myths.html
creatonez wrote 13 hours 22 min ago:
This was written 11 years before that debug log was added.
Extremely loose connection. Things do actually change over the
course of 11 years, believe it or not.
kasabali wrote 2 hours 13 min ago:
It's their modus operandi and it haven't changed, believe or
not.
> it is definitely our intention to gently push the
distributions in
the same direction so that they stop supporting deviating
solutions for
these things where there's really no point at all in doing so.
[1] > Distros may deviate from this by patching this
downstream,
but by shipping this as secure default I do hope to gently push
everybody in the same direction.
> start pushing people gently to define GPT partition type
UUIDs for missing archs
> Let's generate a single gcc `#warning` message asking people
to define
partition type UUIDs for their architectures if they are
missing. [3] [1] [2]
[1]: https://lists.freedesktop.org/archives/systemd-devel/2...
[2]: https://lists.freedesktop.org/archives/systemd-devel/2...
[3]: https://github.com/systemd/systemd/commit/d42e4fa25870...
TacticalCoder wrote 1 day ago:
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 1 day ago:
> 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?
spookie wrote 1 day ago:
Lovely.
Arnavion wrote 1 day ago:
>No option to disable this either, per discussion in [1] The
discussion in that bug is that the Debian maintainer (and upstream
dev) is open to an upstream patch to add such an option.
[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085370
kasabali wrote 1 day ago:
> 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 ( [1] )
But then they'd face the wrath of Lennart, so the only choice left
is ignoring the report.
[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819703#8...
account42 wrote 5 hours 34 min ago:
Perhaps we need to have a concept of separation of upstream and
distros.
jcgl wrote 1 day ago:
You may not like it, but “arbitrary” isn’t a fair description;
there’s reasoning behind it that is over 10 years old: [1] [2] 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.
[1]: http://0pointer.net/blog/projects/stateless.html
[2]: https://www.freedesktop.org/wiki/Software/systemd/TheCaseFor...
int_19h wrote 1 day ago:
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.
jcgl wrote 3 hours 29 min ago:
Oh thanks, I totally missed that distinctions. You’re right.
My first thought is to wonder: why would systemd care about this
then? Any idea?
My second thought is: with a merged /usr, where /usr/{bin,sbin}
are on the same filesystem, what’s the benefit of even having a
distinct sbin? My understanding is that sbin has historically
been useful to have statically linked binaries that can be made
available early during boot without needing various lib dirs
mounted. But that need seems obviated by a unified /usr…
nodesocket wrote 1 day ago:
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
shmerl wrote 1 day ago:
Congrats to the Debian team!
keernan wrote 1 day ago:
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 1 day ago:
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)
theandrewbailey wrote 1 day ago:
> 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.
Biganon wrote 1 day ago:
You're probably being sarcastic, but in the eventuality you aren't,
this is if you install every single package.
LtdJorge wrote 1 day ago:
No, it’s actually the disk usage of hosting a full mirror, other
users commented on that
hsbauauvhabzb wrote 1 day ago:
I’m sure it’s small compared to some alternatives.
JonChesterfield wrote 1 day ago:
You're unlikely to install everything in it.
fhdnfjf wrote 1 day ago:
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 1 day ago:
Testing is a rolling release. Unstable is a more exciting rolling
release.
natebc wrote 1 day ago:
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. [1] Not
affiliated, just a happy user for a long, long time.
[1]: https://www.debian.org/donations
pabs3 wrote 1 day ago:
Lots of other ways for individuals, companies and other organisations
to help too:
[1]: https://www.debian.org/intro/help
dismalaf wrote 1 day ago:
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.
luismedel wrote 1 day ago:
Kudos to the team.
My first contact with Linux was with Debian 2.1. Exactly with this
distro CDs [1] 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 :-)
[1]: https://archive.org/details/linux-actual-06-2/LinuxActual_014....
lucb1e wrote 1 day ago:
> "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
pss314 wrote 1 day ago:
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.
- [1] - [2] "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.
[1]: https://wiki.debian.org/SourcesList#APT_sources_format
[2]: https://www.debian.org/releases/trixie/release-notes/upgrading...
chupasaurus wrote 20 hours 7 min ago:
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.
sgarland wrote 1 day ago:
DEB822 was available from at least Buster [0]. I think Bullseye was
the first release I used it in.
[0]:
[1]: https://manpages.debian.org/buster/apt/sources.list.5.en.htm...
duskwuff wrote 1 day ago:
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.
__david__ wrote 1 day ago:
> 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 1 day ago:
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]:
[1]: https://docs.ansible.com/ansible/latest/collections/ansibl...
perdomon wrote 1 day ago:
How soon can I update my raspberry pi 5 from
Bookworm to Trixie? Does PiOS have to initiate that first?
kwk1 wrote 1 day ago:
The images are a bit out of date, but check out
[1]: https://raspi.debian.net/
treve wrote 1 day ago:
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
sohrob wrote 1 day ago:
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 1 day ago:
Arch isn't truly community driven?
aborsy wrote 1 day ago:
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.
charcircuit wrote 1 day ago:
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?
kachapopopow wrote 1 day ago:
Plasma 6.3 - I can finally ditch kde neon.
ACS_Solver wrote 1 day ago:
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 1 day ago:
> 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 1 day ago:
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.
kachapopopow wrote 13 hours 40 min ago:
I am more than happy to say on Plasma 6.3 instead of hopping
between versions where dragging files into a browser works and
next update it doesn't.
spauldo wrote 1 day ago:
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.
krylon wrote 1 day ago:
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.
UncleSlacky wrote 1 day ago:
antiX will be creating a Trixie-based 32-bit ISO. There's also Void,
Alpine and Slackware (at least).
anthk wrote 1 day ago:
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 1 day ago:
Thank you very much!
homebrewer wrote 1 day ago:
Alpine supports i686, I see no current deprecation plans. This may
change in the next three years though, who knows.
dschuessler wrote 1 day ago:
Out of curiosity, what do you use these netbooks for?
krylon wrote 1 day ago:
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 1 day ago:
Curious, why not use your phone for both these use cases? Seems
like it would be even more convenient
krylon wrote 21 hours 4 min ago:
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).
CogitoCogito wrote 23 hours 41 min ago:
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.
Narishma wrote 1 day ago:
> 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 1 day ago:
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?
Narishma wrote 22 hours 42 min ago:
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.
Linux-Fan wrote 1 day ago:
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.
jabl wrote 1 day ago:
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.
yonatan8070 wrote 1 day ago:
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?
Nursie wrote 1 day ago:
> 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.
snvzz wrote 1 day ago:
Very important to note the lack of x86 (32bit x86) support.
The end of an era.
ndiddy wrote 1 day ago:
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 ( [1] ), so I guess
it'll be a matter of time before they drop 32-bit support altogether.
[1]: https://www.debian.org/releases/trixie/release-notes/issues....
solatic wrote 9 hours 2 min ago:
Yeah, mainframes are all about cases where the uptime is critical.
Most modern systems are good with offering 99.9% or 99.99%
reliability, with the understanding that trying to offer more than
that just gets more and more expensive. Well... spending huge
amounts of money on mainframes is one of the strategies to get to
reliability numbers like 99.9999999%.
Source: [1] The legitimate usage is typically for workloads like
relational databases (which are anyway single-machine
architectures) that experience heavy load 24/7, part of fragile
architectures that cannot tolerate downtime (remaining fragile as
such because the original source code has been lost etc.), where
"the system is down" causes tens of thousands if not hundreds of
thousands of people to stop work.
[1]: https://itic-corp.com/itic-2023-reliability-survey-ibm-z-r...
Palomides wrote 1 day ago:
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 1 day ago:
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.
kev009 wrote 1 day ago:
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.
Pet_Ant wrote 1 day ago:
It can be a little hard to navigate to so the .torrent links for x86-64
are
Minimal: [1] Full:
[1]: https://cdimage.debian.org/debian-cd/current/amd64/bt-cd/debia...
[2]: https://cdimage.debian.org/debian-cd/current/amd64/bt-dvd/debi...
wltr wrote 1 day ago:
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 1 day ago:
They are linked from the "Other downloads" page linked from the
front page.
wltr wrote 1 day ago:
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.
pabs3 wrote 8 hours 24 min ago:
Yeah, it was deliberate, to make it easy for most people, who
will only want the netinst download.
duskwuff wrote 1 day ago:
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.
Pet_Ant wrote 1 day ago:
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.
synack wrote 1 day ago:
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.
bayindirh wrote 1 day ago:
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.
account42 wrote 5 hours 31 min ago:
Is this really a signature feature when rolling release distros are
common?
bayindirh wrote 5 hours 25 min ago:
Yes, esp. if you are using Debian at infra and in production. I
upgraded three servers in the morning while sipping my tea. Nobody
noticed anything.
For RedHat family, this is nigh impossible, requiring hours of
planning, downtimes, etc., and even then, it's not guaranteed to
work.
If you prefer a rolling release, and won't use it on a server,
Debian Testing got you covered (unless you are in a security
sensitive environment). My systems are well-isolated from outside,
so desktop systems can run Testing without issues.
Servers and exposed systems always run stable with security updates
installed automatically, though.
mr_sturd wrote 1 day ago:
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 1 day ago:
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.
bbarnett wrote 1 day ago:
For those worrying about the NIC change with systemd, this comes from
the release doc: [1] # 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.
[1]: https://www.debian.org/releases/trixie/release-notes/issues.en...
champtar wrote 1 day ago:
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 1 day ago:
>Hopefully the last breaking change.
Every year's cope with systemd.
foresto wrote 1 day ago:
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 1 day ago:
You can easily keep the current naming behavior with the
'net.naming_scheme=' kargs
foresto wrote 1 day ago:
I already have systems that use net.ifnames=0. My question is
about whether this new behavior can affect them.
champtar wrote 1 day ago:
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.
juujian wrote 1 day ago:
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 1 day ago:
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 1 day ago:
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.
markus_zhang wrote 1 day ago:
When can we have Bandit or Bluey?
Balinares wrote 1 day ago:
Presumably not before Debian runs out of Toy Story characters.
seba_dos1 wrote 1 day ago:
...and since there's Toy Story 5 scheduled for 2026, the pool of
yet unused characters will become larger again soon.
imoverclocked wrote 1 day ago:
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 1 day ago:
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.
gcarvalho wrote 1 day ago:
Looking forward to upgrade over the weekend.
Have had my RPi on Debian since Debian 9, with smooth upgrades every
time.
sheerun wrote 1 day ago:
Debian was often the only linux os that worked on old "spacestations"
of mine. Great sentiment
sheerun wrote 1 day ago:
And I mean Debian 12, not some old version, much more impressive
spauldo wrote 1 day ago:
Do you mean SparcStations?
Venn1 wrote 1 day ago:
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.
binwiederhier wrote 1 day ago:
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]
[2] [3] [1] /pull/1420 [4]
[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/lates...
StopDisinfo910 wrote 22 hours 57 min ago:
> 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 19 hours 51 min ago:
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.
StopDisinfo910 wrote 2 hours 30 min ago:
Debian is not cautious with the dependencies. Debian breaks a lot
of what they ship, sometimes flagrantly like removing a whole
feature, sometimes insiduously by introducing new bugs. I don't
really care that Debian doesn't view it as breaking things. From
my point of view, users trying to get my product get subpar
experience in a way which is far from explicit.
I personally wouldn't use Debian but people are free to do
whatever they want. I don't want to waste my time dealing with
Debian maintainers and how they think software should work
however. I advise all software developers to do the same and am
vocal about it because it's easy to get guilt tripped in the idea
that you should somehow support their users because they want to
use your product or that introducing changes to support their
esoteric targets somehow make sense because they have done the
work despite the burden of futur support actually landing on you.
I want to make clear to people who decide they have no interest
in it that they are not alone and it's perfectly fine.
And to be clear, I am singling Debian here because they are by
far the worst offender when it comes to patching but the comment
applies equaly to any distributions that apply invasive patches.
scbrg wrote 1 day ago:
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.
leansensei wrote 1 day ago:
Thank you for ntfy, it's such a useful piece of software!
esseph wrote 1 day ago:
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 1 day ago:
[1] > The ntfy image is available for amd64, armv6, armv7 and
arm64. It should be pretty straight forward to use.
[1]: https://docs.ntfy.sh/install/#docker
baobun wrote 1 day ago:
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.
tremon wrote 1 day ago:
The maintainer has a short explanation here: [1] > 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.
[1]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1098866#10
winter_blue wrote 1 day ago:
> 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?
jonp888 wrote 1 day ago:
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.
Defletter wrote 34 min ago:
Just jumping in to say that this is making me genuinely
reconsider adopting a licence/policy that forbids repackaging:
the fact that someone can repackage my project, but worse, and
still use my project's name? Absolutely not. I do not want the
burden that inevitably comes when people complain to me that
this or that is missing from a repackage.
baobun wrote 1 day ago:
Yes but not all packages written in those languages are.
heywire wrote 1 day ago:
Just wanted to say thanks for ntfy! I use it daily to notify me on
events from my home Meshtastic node.
master_crab wrote 1 day ago:
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.
aragilar wrote 1 day ago:
If upstream makes no releases in that time, then there'll be no
upgrades.
AstroBen wrote 1 day ago:
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 1 day ago:
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.
pabs3 wrote 1 day ago:
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. [1]
[1]: https://security-tracker.debian.org/
[2]: https://security-team.debian.org/
AstroBen wrote 1 day ago:
Theres some information here they've put out: [1] And yeah it
must be an incredible amount of work to stay on top of all this
[1]: https://www.debian.org/security/faq
duskwuff wrote 1 day ago:
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.
bbarnett wrote 1 day ago:
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.
baobun wrote 1 day ago:
> 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.
ACS_Solver wrote 1 day ago:
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.
gradschool wrote 20 hours 59 min ago:
> 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.
KronisLV wrote 21 hours 49 min ago:
> And one of the best parts is, I've never had a Debian system break
without it being my fault in some way. [1] [2] Then again, I’ve had
most software occasionally break, I’m thankful that Debian exists.
[1]: https://blog.kronis.dev/blog/debian-updates-are-broken
[2]: https://blog.kronis.dev/blog/debian-and-grub-are-broken
StopDisinfo910 wrote 23 hours 4 min ago:
> 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.
throwaway81523 wrote 1 day ago:
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. [1] I still use Debian but
it's hard to forget stuff like that even after all these years.
[1]: https://16years.secvuln.info/
jraph wrote 1 day ago:
What do you expect Debian to do today about this 17 years old
incident?
dotancohen wrote 1 day ago:
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.
exe34 wrote 1 day ago:
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.
Galanwe wrote 1 day ago:
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.
jlarocco wrote 1 day ago:
> 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 1 day ago:
I’m not trying hard enough. Feel the same as you and GP for two
decades and counting.
umvi wrote 1 day ago:
Do you usually update in place or do a fresh install whenever a new
major version comes out?
madphilosopher wrote 22 hours 37 min ago:
I always update in place. And I follow all the upgrade procedure
advice in the release notes.
heresie-dabord wrote 1 day ago:
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 1 day ago:
Why do you remain on old stable instead of stable?
rbanffy wrote 1 day ago:
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.
Linux-Fan wrote 1 day ago:
It is a well-known issue with probably less well-known solutions,
cf. < [1] >
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.
[1]: https://unix.stackexchange.com/questions/723675/debian-ubu...
rbanffy wrote 1 day ago:
Good pointer. I remember learning it, and then forgetting it.
Probably more than once.
Still should be the default behavior.
JackeJR wrote 1 day ago:
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.
account42 wrote 5 hours 45 min ago:
This is the "you're holding it wrong" response to a clear design
issue.
rbanffy wrote 1 day ago:
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 1 day ago:
Debian bundles AppArmor profiles for most services. This will
prevent an attacker from accessing outside the perimeter drawn
by the AppArmor profile.
johnisgood wrote 1 day ago:
That is a workaround for a ridiculous issue.
teo_zero wrote 1 day ago:
Aren't firewall rules part of the "configuration" the OP talked
about?
mjochim wrote 1 day ago:
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.
foresto wrote 1 day ago:
> 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.
djfobbz wrote 1 day ago:
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 1 day ago:
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.
madars wrote 1 day ago:
>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.
seba_dos1 wrote 1 day ago:
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.
kasabali wrote 1 day ago:
> 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.
jama211 wrote 1 day ago:
Classic Linux user response. Jeez…
yjftsjthsd-h wrote 1 day ago:
AFAICT, the patches are here: [1] Whether that qualifies as
"heavy" or not is of course a matter of opinion, but it's not
nothing.
[1]: https://salsa.debian.org/kernel-team/linux/-/tree/debian...
kasabali wrote 1 day ago:
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
raggi wrote 1 day ago:
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.
WD-42 wrote 1 day ago:
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.
zozbot234 wrote 1 day ago:
> 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.
porridgeraisin wrote 1 day ago:
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 1 day ago:
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 1 day ago:
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.
bbarnett wrote 1 day ago:
Bear in mind, LTS and ELTS are not Debian maintained.
The wiki has more info on this.
pabs3 wrote 1 day ago:
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. [1] /Team [1]
/Funding [1] /Extended
[1]: https://wiki.debian.org/LTS
[2]: https://wiki.debian.org/LTS/Team
[3]: https://wiki.debian.org/LTS/Funding
[4]: https://wiki.debian.org/LTS/Extended
bbarnett wrote 1 day ago:
[1]: https://news.ycombinator.com/item?id=44853371
aragilar wrote 1 day ago:
I think they mean the LTS kernels, not Debian's LTS.
kasabali wrote 1 day ago:
Yep, I mean longterm trees from [1] , to be clear.
[1]: https://www.kernel.org/
bbarnett wrote 1 day ago:
Yes, seems so, thanks.
brirec wrote 1 day ago:
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 1 day ago:
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.
bayindirh wrote 1 day ago:
Which GPU, display server and compositor stack are you using?
madars wrote 1 day ago:
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.
ACS_Solver wrote 1 day ago:
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
[1]: https://gitlab.freedesktop.org/drm/i915/kernel/-/issue...
bayindirh wrote 1 day ago:
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.
ThatMedicIsASpy wrote 1 day ago:
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
zvmaz wrote 1 day ago:
> after Ubuntu went way downhill and haven't had cause to regret it.
In what way Ubuntu went downhill?
tmtvl wrote 1 day ago:
Amazon ads in the Unity application menu (what was it called,
'lenses' or something?).
spauldo wrote 1 day ago:
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.
ocdtrekkie wrote 1 day ago:
Minutes to start Firefox on one of my machines.
28304283409234 wrote 1 day ago:
Oh....snap.
ACS_Solver wrote 1 day ago:
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.
doublepg23 wrote 1 day ago:
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.
Arrowmaster wrote 20 hours 57 min ago:
They have also had more malware on the snap store than all other
distros have had in their official repos combined.
bayindirh wrote 1 day ago:
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.
kev009 wrote 1 day ago:
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 1 day ago:
> 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).
nextos wrote 1 day ago:
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.
Eduard wrote 1 day ago:
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 1 day ago:
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 23 hours 10 min ago:
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.
yjftsjthsd-h wrote 1 day ago:
Snaps, and ads in the motd
bayindirh wrote 1 day ago:
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 1 day ago:
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 1 day ago:
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.
happymellon wrote 1 day ago:
Snaps? Proprietary package managers are never great.
Santosh83 wrote 1 day ago:
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".
happymellon wrote 1 day ago:
> 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.
BearOso wrote 1 day ago:
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 1 day ago:
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.
tannhaeuser wrote 1 day ago:
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 1 day ago:
In addition, applications under snap are much slower to
start. That's just not acceptable.
bayindirh wrote 1 day ago:
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.
dismalaf wrote 1 day ago:
No, but it's trivial to implement since Snap is open source
so you know exactly what sort of payload it wants.
curt15 wrote 1 day ago:
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.
mmcnl wrote 1 day ago:
I don't really understand why this is such a big problem. You
don't have to use snaps.
wkat4242 wrote 1 day ago:
Yes you do. Some packages aren't available anymore in apt
superb_dev wrote 1 day ago:
If you use Ubuntu, yes you do. It’s why I ditched Ubuntu
tasuki wrote 1 day ago:
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.
L3viathan wrote 1 day ago:
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.
mkesper wrote 1 day ago:
You migrate to Debian.
Everything else is a bandaid that can be rug pulled any time
Canonical feels like doing so.
tasuki wrote 54 min ago:
I've done that some years ago and couldn't be happier.
justinclift wrote 1 day ago:
I made this snap "alternative" to solve this exact problem:
[1] Packaged as: [1] /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.
[1]: https://github.com/justinclift
[2]: https://github.com/justinclift/snapd-empty/releases/...
justinclift wrote 58 min ago:
Ugh, I somehow managed to paste an incorrect repo url in my
comment above.
It should be this:
[1]: https://github.com/justinclift/snapd-empty/
npteljes wrote 1 day ago:
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.
sofixa wrote 1 day ago:
> 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.
npteljes wrote 1 day ago:
>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 1 day ago:
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.
ACS_Solver wrote 1 day ago:
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.
homebrewer wrote 1 day ago:
> systemd [1] > 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.
[1]: https://bbs.archlinux.org/viewtopic.php?pid=114953...
yjftsjthsd-h wrote 1 day ago:
>> 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.
jeltz wrote 1 day ago:
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 1 day ago:
ChromeOS still uses upstart.
teddyh wrote 1 day ago:
Upstart came before systemd; much of the reason for
systemd’s creation was fixing what was considered
fundamental design mistakes in Upstart: < [1] > (under
the heading “On Upstart”).
[1]: http://0pointer.net/blog/projects/systemd#:~:t...
Santosh83 wrote 1 day ago:
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.
type0 wrote 1 day ago:
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 1 day ago:
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...
npteljes wrote 1 day ago:
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 18 hours 42 min ago:
> Mint is not part of the discussion.
Read the parent comment I responded to
npteljes wrote 1 hour 40 min ago:
Mea culpa, I glossed over that!
fsflover wrote 1 day ago:
[1]: https://news.ycombinator.com/item?id=44849691
npteljes wrote 1 day ago:
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.
bayindirh wrote 1 day ago:
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 1 day ago:
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.
LeoPanthera wrote 1 day ago:
You sort of do. It's really hard to avoid them, because they've
modified "apt" to install snaps by default without asking.
bayindirh wrote 1 day ago:
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).
ants_everywhere wrote 1 day ago:
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.
splatter9859 wrote 10 min ago:
Preach.
This has got to be the most user-blind self-imposed
preference in a modern operating system outside of
Microsoft's BS.
If you're going to use an OSS operating system, the control
of what is placed on the system should be inherently with
the user. If the developer has a question if a new package
should be added or is required, throw a prompt and ask --
with a default to not use application containers and the
default packaging system.
Really not hard.
hsbauauvhabzb wrote 1 day ago:
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.
yjftsjthsd-h wrote 1 day ago:
You really have to work to avoid them; ex. `apt install
firefox` will install the snap
potato-peeler wrote 1 day ago:
> 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?
ethan_smith wrote 22 hours 32 min ago:
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.
toenail wrote 1 day ago:
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 1 day ago:
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).
accrual wrote 1 day ago:
> 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.
spauldo wrote 1 day ago:
OpenBSD requires at least a Pentium these days.
accrual wrote 23 hours 23 min ago:
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. ;)
winrid wrote 1 day ago:
Man, I thought I was behind using a P3 in like 2007 lol. You can get
something 100x faster for $1 :D
accrual wrote 23 hours 22 min ago:
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.
avhon1 wrote 1 day ago:
Debian (and many other distributors of compiled binaries) uses
"i386" to refer to all 32-bit x86 processors, including the Pentium
3.
esaym wrote 1 day ago:
Are you confusing "386" with 32bit? 686 is the normal 32bit arch. 386
is something from the 1980's right?
spauldo wrote 1 day ago:
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.
accrual wrote 1 day ago:
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".
astrobe_ wrote 1 day ago:
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.
zozbot234 wrote 1 day ago:
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.
chungy wrote 1 day ago:
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.
bowsamic wrote 1 day ago:
i386 is the most common term used for 32 bit x86
[1]: https://en.m.wikipedia.org/wiki/IA-32
NewJazz wrote 1 day ago:
AIUI Debian kept the i386 name for the arch even as their 32 bit
requirements evolved.
badsectoracula wrote 1 day ago:
AFAICT this refers to Debian support, the Linux kernel does support
32bit CPUs though only since the original Pentium (excluding some
clones).
NewJazz wrote 1 day ago:
Well, isn't there an additional year or so of support for old stable?
So beyond 2025.
abhinavk wrote 1 day ago:
Buster is supported until June 2028.
bbarnett wrote 1 day ago:
Not by Debian it isn't. [1] 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.
[1]: https://www.debian.org/releases/
abhinavk wrote 1 day ago:
I was meaning to write Bookworm. Bookworm is the last to
support i386 kernel and is supported until June 2028.
pabs3 wrote 1 day ago:
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. [1] /Team
[1] /Extended [1] /Funding
[1]: https://wiki.debian.org/LTS
[2]: https://wiki.debian.org/LTS/Team
[3]: https://wiki.debian.org/LTS/Extended
[4]: https://wiki.debian.org/LTS/Funding
bbarnett wrote 1 day ago:
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.
-- [1] "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: [2] 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.
[1]: https://www.freexian.com/lts/extended/docs/debian-10...
[2]: https://www.debian.org/security/faq#contrib
pabs3 wrote 1 day ago:
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. [1] [2] [3]
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.
[1]: https://wiki.debian.org/LTS/Bullseye
[2]: https://wiki.debian.org/LTS/Using#Check_for_unsupp...
[3]: https://salsa.debian.org/debian/debian-security-su...
NewJazz wrote 1 day ago:
Thanks, I assume some of that is sort of extended, asterisked
support though?
pabs3 wrote 1 day ago:
Games are unsupported, and a bunch of other packages: [1]
[1]: https://wiki.debian.org/LTS/Bullseye
[2]: https://wiki.debian.org/LTS/Using#Check_for_unsupporte...
zozbot234 wrote 1 day ago:
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.
pabs3 wrote 1 day ago:
In case anyone wants to do that, here is the doc for new ports:
[1]: https://wiki.debian.org/PortsDocs/New
zozbot234 wrote 1 day ago:
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.)
pabs3 wrote 11 hours 42 min ago:
Well, the existing i386 port is going to remain as-is for
supporting old software (especially games) (but the CPU
baseline will likely get increased), it isn't going to be
removed, so you would need a new architecture for 32bit-only
hardware.
Since i386 is not going to do the 2038 transition either (since
that would break the ABI), also you would need to either make a
new ABI for the new port, or do the 2038 transition for it too.
Over time more and more 32-bit bugs will get introduced, so
there will be lots of maintenance work to do too.
zozbot234 wrote 4 hours 39 min ago:
> ...it isn't going to be removed
I had seen conflicting information about this, though nothing
official. I suppose we'll know more once some actual release
planning happens for forky, which might take some time.
tremon wrote 1 day ago:
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/Package
s.gz | zgrep ^Package: | wc -l
68737
$ curl -s
http://deb.debian.org/debian/dists/trixie/main/binary-i386/Packages
.gz | zgrep ^Package: | wc -l
66958
munchlax wrote 1 day ago:
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 1 day ago:
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:
[1]: https://en.wikipedia.org/wiki/P6_(microarchitecture)
avhon1 wrote 1 day ago:
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 1 day ago:
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: [1] 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.
[1]: https://en.wikipedia.org/wiki/Amd_geode#AMD_Geode
3eb7988a1663 wrote 1 day ago:
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.
shasheene wrote 1 day ago:
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
KennyBlanken wrote 1 day ago:
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 19 hours 54 min ago:
> 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
michaelt wrote 1 day ago:
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)
duskwuff wrote 1 day ago:
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
[1]: https://packages.debian.org/trixie/bash
boomboomsubban wrote 1 day ago:
I don't think this is the case anymore, see [1] though it's not
the default everywhere.
[1]: https://gitlab.winehq.org/wine/wine/-/releases/wine-9....
progval wrote 1 day ago:
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 1 day ago:
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.
bbarnett wrote 1 day ago:
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
JdeBP wrote 7 hours 0 min ago:
I can credit you, in version 1.42, with more than a hyperlink to
random posts on Hacker News if you have something better elsewhere on
the WWW. (-:
*
[1]: https://jdebp.uk/Softwares/nosh/guide/services/systemd-login...
dur-randir wrote 1 day ago:
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.
RVuRnvbM2e wrote 1 day ago:
Why would you want to do this?
zahlman wrote 1 day ago:
To avoid systemd, presumably. Although one could also just switch
to Devuan at that point.
dijit wrote 1 day ago:
choice.
foresto wrote 1 day ago:
Thank you for sharing this. I'm inclined to adopt it in my lxc
containers, at least.
egorfine wrote 1 day ago:
Wait, sysvinit on debian 13 truly practically works?? as in, one can
remove systemd and have a working server OS with sysv init??
UncleSlacky wrote 1 day ago:
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):
[1]: https://mxlinux.org/blog/changes-coming-with-mx-25/
bbarnett wrote 1 day ago:
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.
josteink wrote 1 day ago:
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 :)
hiprob wrote 1 day ago:
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.
foresto wrote 1 day ago:
> 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.
prmoustache wrote 1 day ago:
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 1 day ago:
>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 1 day ago:
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 1 day ago:
>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.
josteink wrote 1 day ago:
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.
accrual wrote 1 day ago:
> 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.
amtamt wrote 1 day ago:
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.
cocoto wrote 1 day ago:
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.
3eb7988a1663 wrote 1 day ago:
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 1 day ago:
I think the title has been trimmed from the word “realeased”.
Might be another case of HN auto title edit botching the original
title.
superkuh wrote 1 day ago:
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. [1] >"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.
[1]: https://www.debian.org/releases/trixie/release-notes/issues.en...
bayindirh wrote 1 day ago:
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
[1]: https://lists.debian.org/debian-devel/2024/05/msg00014.html
bryanlarsen wrote 1 day ago:
Infinite scroll length on terminals can chew through /tmp, and
systems misbehave strangely when they're out of /tmp.
spauldo wrote 1 day ago:
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.
bbarnett wrote 1 day ago:
Also watch out for surprise file deletes in /tmp and /var/tmp at 10
and 30 days.
This too can be turned off.
sgarland wrote 1 day ago:
I can’t fathom why anyone would be surprised that a directory
named “tmp” is ephemeral.
CogitoCogito wrote 23 hours 34 min ago:
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.
KORraN wrote 1 day ago:
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 1 day ago:
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 1 day ago:
It's a systemd thing, see `man systemd-tmpfiles`.
JdeBP wrote 6 hours 47 min ago:
I think that superkuh's point is that it is not a systemd
thing. Cleaning up /tmp by deleting old files has been
around since before systemd was invented. Since before Linux
was invented, even.
bbarnett wrote 5 hours 46 min ago:
Yes but in Debian this was not a default until now.
Before, /tmp was wiped on reboot. /var/tmp was not.
Neither were cleaned otherwise.
So for Debian, this is a systemd thing. And it was pushed
by a systemd maintainer, who is also a Debian developer.
I have zero interest in Debian "being brought inline" with
other distros, because other distros should be coming
inline with Debian.
JdeBP wrote 3 hours 36 min ago:
Outwith the world where only Debian and other Linux
distributions exist, though, this isn't really systemd
doing bad things to poor old Debian. To a wider world it
is Debian and other Linux distributions exceedingly
slowly reinventing things from Unix.
AIX had /usr/sbin/skulker from at least as early as
version 1.2.
For AT&T System 5, Fielder and Hunter were popularizing a
similar utility named rmtrash that is run nightly.
Fielder and Hunter exemplify traditional Unix thinking in
their 1986 book on Unix system administration, which
includes rmtrash:
> By putting all temporary files in one or two
directories, it is easy to clean them all out at regular
intervals. For this reason, it's a good idea to encourage
users to use /tmp for all files they need only a short
while.
skulker is not in the old comp.unix.aix Usenet FAQ
document, but given the number of times "That's what
skulker does, and you should be running it daily." seems
to have been the answer over the years, it probably
should have been. (-:
To old hands, this is not a systemd novelty at all. The
novelty, to old hands, is the idea of doing this not
using a script. I remember the war stories from the
1990s and turn of the 21st century when users did things
like include LF in the names of temporary files, and
administrators suddenly learned the utility of find
-print0 and xargs -0 or find -exec rm {} +. Stéphane
Chazelas for one has had a lot to say on the subject over
the years.
That said, mtree (from 1989) already existed at the point
that systemd-tmpfiles was invented, and already had the
idea of working from a specification file with names and
owners and permissions and whatnot. It is surprising
that no-one ever apparently tried mtree for completely
wiping /tmp. The BSDs are using find to this day in the
several places with they auto-delete stuff in /tmp
including the daily periodic, although they did spot that
their own find had a -delete option in 1999. (-: Hell,
even I am still using find.
[1]: https://github.com/freebsd/freebsd-src/blob/main...
kasabali wrote 1 day ago:
It was available as an option before that:
[1]: https://manpages.ubuntu.com/manpages/xenial/man5/rcS...
Paianni wrote 1 day ago:
The Devuan version may end up being the last that GNOME will run on...
UncleSlacky wrote 1 day ago:
You say that like it's a bad thing.
Paianni wrote 1 day ago:
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 23 hours 5 min ago:
Meh, it looks pretty in screenshots but it's a huge waste of
screen space in the end.
Paianni wrote 16 hours 29 min ago:
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.
kasabali wrote 1 hour 33 min ago:
Being able to use mouse and keyboard makes you a power user
in 2025?
Paianni wrote 1 hour 2 min ago:
No
account42 wrote 5 hours 22 min ago:
Those users won't use Devuan or Gnome but Android/iOS.
Paianni wrote 4 hours 43 min ago:
They may not personally choose Devuan or GNOME but they
might end up using them because an administrator chose
them.
gorgoiler wrote 1 day ago:
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
<- back to front page
You are viewing proxied material from codevoid.de. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.