Debian 11 “bullseye” freeze started | Hacker News Reader

Debian 11 “bullseye” freeze started

lists.debian.org

135 pointspsxuaw89 comments

Debian is an amazing project. I love how it's so fundamental but doesn't call attention or hype to itself. It's used by millions but doesn't try to be sexy or glamorous. Even the website is minimal.

Also, it "just works". It's so reliable that I almost forget it's there. 10+ years in production and not once an OS/distro bang-up.

As an outsider, it's not the reliability of the software that is amazing to me. It's the governance and management of the project. The distro has managed to be amazingly consistent and stable for years. But the reason for this is how the project is run. It's hard to do that for so long with minimal drama and they deserve tons for kudos for that effort.

Like some others, where CentOS was my go-to distro, I've started moving over to Debian as my distro of choice when I can. Thus far, I've been very happy with this choice.

100%. That management makes it happen.

I think we all (who can afford it) should send them a few bucks.

You're right. I just did that.

There is some fun drama though, but overall it's indeed minimal.

See: http://aaonline.fr/search.php?search&criteria[sequenceId-is]...

1. http://aaonline.fr/player.php?trial_id=57684

2. http://aaonline.fr/player.php?trial_id=57899

3. http://aaonline.fr/player.php?trial_id=58428

4. http://aaonline.fr/player.php?trial_id=60363

5. http://aaonline.fr/player.php?trial_id=69970

6. http://aaonline.fr/player.php?trial_id=70639

7. http://aaonline.fr/player.php?trial_id=71040

8. http://aaonline.fr/player.php?trial_id=71116

9. http://aaonline.fr/player.php?trial_id=71715

Yes! One of the things that stands out to me about Debian is that it is community governed and not underwritten by a specific large corporation. There are a special few huge open source projects that can boast that kind of stable, persistent governance.

I love to tell that, I forgot to check on a Debian server for a year. I also forgot its physical location in our server room (it's one of the many identical servers amongst the racks).

When I remembered its existence, I logged in and it was just doing its thing happily, with all its security updates applied automatically.

You can set up and forget a well set up Debian Stable installation. It'll just truck along without complaining. With a little bit of work, you can make it tell you if it needs any attention but, it's very unlikely.

Hmm, popcon says only 199127 submitters, I wonder how many Debian systems there actually are.

https://popcon.debian.org/

We have hundreds, if not thousands of vms running Debian in our datacenter, none of them have popcon installed.

So yeah, I think this statistic is orders of magnitude lower than in reality.

What I like about Debian is that they don’t really force you to install this.

I only enable popcon on long-living personal servers to prevent transient noise in the system.

I bet popcon is enabled at most 10% of the systems since its default state is disabled (at least in expert install, anyway).

would ubuntu also count?

I've been using Debian or Debian derived distros for quite a while, everything from straight up Debian on various servers, Armbian for my SBC's, to my secondary PC running Kubuntu and later KDE Neon.

For me as a more casual Linux user, it's great as it essentially "just works" and I don't have to invest a great deal of time to fiddle with auxiliary things.

However, if I could get one wish, it was to ditch the codenames. As someone who's not on the dev mailing list, I find it so confusing when people reference the Debian version just by codename and have to search just about every time to make sure I understand what's what.

Regardless, a big thanks to the contributors!

The code names make issues with specific versions or eras easy to search

Ubuntu at least does it in alphabetical order of the first letter of the codename. Eg, the release after Ubuntu 20.04 Focal was Ubuntu 20.10 Groovy. This means that hearing the Ubuntu codename "Bionic" provides some information: it was 4 releases before Focal.

But Debian codenames are arbitrarily based on characters from the movie Toy Story, so there's no relation to the Debian release.

To fix this, I propose for future releases the Debian codename naming scheme be replaced with numbers written out in words. Eg.

Debian 14 (fourteen)

Debian 13 (thirteen)

Debian 12 (twelve)

Debian 11 (bullseye)

Debian 10 (buster)

Debian 9 (stretch)

Debian 8 (jessie)

This retains the ability to easily search for eg, "Debian Thirteen", while making it much easier to remember earlier codenames as time goes on.

Also unlike Ubuntu's alphabetical naming scheme, the number approach doesn't have any overflow issues (which isn't as big of an issue anyway because Debian's provides new releases every 2 years instead of 6 monthly).

Sure; but (IMHO) I think the code names provide an visible and fun reminder that this operating is a operating system for hackers, and this is a tiny bit of personality from that ethos baked into the system.

Debian labels itself the 'universal operating system', and makes no aspirations to cater to the lowest common denominator of users.

>Debian labels itself the 'universal operating system', and makes no aspirations to cater to the lowest common denominator of users.

That's a bit of a contradiction.

Universal operating system for a wide variety of hardware, but some expertise is assumed for the user.

Kind of a novel choice now that I think about it... most projects aim for more users, which means less assumed knowledge, which necessitates more limits on hardware. Not a bad choice, just different.

Since debian both provide version numbers and codenames, I don't think making codename same as the release version makes any sense.

When I google Debian 5, I get results to Debian Lenny (which is 5). Also Debian denotes versions in official notices and it's widespread in internet so, codenames are not hindering anything in practice.

OTOH, codenames play a bigger role in the ecosystem. It adds motivation, fun and sense of originality. I love to have them, I love they're in fact Toy Story characters.

It makes it almost lifelike and masks the burden of maintaining one of the biggest distro projects in the existence.

While I love minimalism and utility, I think Debian should keep these. It's fun, memorable and original.

As someone who doesn't use Debian as my only (or even main) OS, but does manage a few Debian servers, I completely disagree on memorable. I can never remember the order of code names and whenever I read something like "stretch or later" I always have to Google to find out if the servers I have qualify or not.

Other than that, I have zero complaints about Debian

> whenever I read something like "stretch or later" I always have to Google to find out if the servers I have qualify or not

This is exactly my problem as well.

Oh well, luxury problem in the grand scheme of things.

> I can never remember the order of code names...

Me neither, don't worry about it :)

> I read something like "stretch or later"...

Well, they're really irresponsible if they're writing like that. All of the places I've seen, downloaded debs either write Debian 9+ or Debian 9+ (Stretch and later) or any similar fashion.

I didn't encounter any Debian $codename only compatibility notes. I also don't write $codename only readme files, etc.

> All of the places I've seen, downloaded debs either write Debian 9+ or Debian 9+

Just a couple of recent examples I stumbled upon:

https://www.armbian.com/nanopi-r2s/#kernels-archive-all

https://louwrentius.com/configuring-scst-iscsi-target-on-deb...

Sure a bit of searching lets me figure out what's what but...

If it helps, the list of Debian codenames is here:

https://www.debian.org/releases/

Also the corresponding Devuan (systemd-free Debian) release names, with "Bullseye" equating to "Chimera":

https://www.devuan.org/os/releases

I'm a big Debian fan. Every time someone asks me for "computer" help with their windows machines, I tell them I can only solve their problem installing Debian (which is true, I haven't used Windows in a long time).

So far my mom and dad have been using Debian for the last 4 years and I had to assist them almost never (we live in 2 different continents). Both of them work with the computer, and my dad is that person that is not good with computers.

I've also installed Debian to at least 6 friends, who never had a complaint again.

I also thought a friend how to code, she got a job as a developer after 9 months, she picked up Debian/linux super fast.

I hope it keeps getting better and better and easier.

Following the recent CentOS fiasco, I'm advising friends to go with Debian. It's rock solid and can be depended upon.

Maybe for servers. But it still has plenty of rough edges as a desktop OS. Mint is a much better choice (IMO) for the desktop, that still is somewhat within the Debian ecosystem.

What are your rough edges? I have found Debian Unstable with latest Gnome to be way more stable and productive than I expected.

I'm not sure if they count as rough edges, but most common things I've come across tend to be security related and the limitations on a normal user. From (foggy) memory you can't sudo by default, and you also can't mount as a normal user. These things are probably perfectly reasonable choices to make for a secure server but annoying for a desktop.

This may not count as desktop, but another annoying one is /usr/sbin and some other common directories being missing from the default PATH.

Still, it's way less annoying than ubuntu's constant nagging about updates and trying to shove snap in your face.

For me it was outdated browsers, i switched from Ubuntu just for Chromium and was shocked when i saw the version available, not just Chromium but also Firefox, they backport fixes but don't release new version to stable channel. Not really comfortable using Unstable/Testing channels which my have newer version.

It's also hard to download first time you want to install, coming from Ubuntu there is just one x64 .iso and one big "download" button that auto select the right file. In Debian i had to google which file to download from CDs and DVDs version just for x64.

And there is the install UI, it give you a 2006 vibe.

This small things are easy to fix but still there for some reason, probably because they focus on core and more important stuff, but this are great things to have for new users.

> Not really comfortable using Unstable/Testing channels which my have newer version.

Debian now has a backports channel with up-to-date kernels, browsers and more, and those packages will install cleanly on a Debian Stable release. You're not supposed to use Testing/Unstable packages, as installing these on Stable will give you a mixed system that's not necessarily expected to work, and might also break unpredictably upon further upgrades.

Similar to what flukus said, the default configuration is surprisingly minimal in some cases and surprisingly sophisticated/messy in others. And for a desktop user everything is kind of a bare default experience. And that's not to mention the ancient package versions, but if you're a moderately experienced desktop user you might want to consider using Sid/unstable anyway.

I've switched from CentOS to Debian 7-8 years ago (Debian 7) and I just love it.

I was trying a lot of distros, but I always came back to Debian and I stopped doing that for the past few years because Debian just works.

Fill me in? What recent fiasco?

CentOS as we know it is basically going away. Worse, they reneged on their promise of long-term support for the last release.

What will be known as "CentOS" will be the "stream" version, i.e. a rolling release distro with goals completely antithetical to what was out there before.

CentOS 8 had its EOL brought forward to 2021 and CentOS 9 won't exist. Folks are expected to switch to CentOS Stream, RHEL or another distro.

https://lwn.net/Articles/839257/

Some of the highlights (from my point of view) that have been frozen, according to the packaging website:

Linux kernel 5.10

gcc 10.2

libc 2.31

Perl 5.32

And some non-essential packages that look to being included in the upcoming release (I'm sure there's plenty of other exciting inclusions that I've missed):

GNOME 3.38

KDE Plasma 5.20

Xfce 4.16

LXQt 0.16

MATE 1.24

Cinnamon 4.8

Apache httpd 2.4.46

Python 3.9

LibreOffice 7.0

QEMU 5.2

Which website are you looking at? The release notes I saw said Bullseye would use the 4.19 kernel. I expect them to use a LTS kernel, so I'd be a bit surprised if they choose 5.10.

5.10 is LTS

Woops, my bad!

They're considering dropping i386, which is interesting. Does anyone know more about that?

Fedora has considered and largely executed on the same:

https://fedoraproject.org/wiki/Changes/Stop_Building_i686_Ke...

We still build packages for it, e.g., https://koji.fedoraproject.org/koji/buildinfo?buildID=166966...

Some other related discussion: https://lists.fedoraproject.org/archives/list/devel@lists.fe...

Time64 is the death of i386 - the time_t structure needs to be expanded to 64-bit to handle dates beyond 2038, but that's an ABI break, and the primary reason anyone still runs 32-bit binaries is for closed-source games which won't come along for an ABI upgrade.

You can either do the ABI break and lose most existing users when the main set of apps stop working, or have the main set of apps stop working anyway in 2038.

You could switch it to unsigned 32-bit time_t, and most things would still work right up to 2106.

With any luck, civilization will collapse by 2038 and it won't matter anyway. But, struggling back up from collapse on scavenged 32-bit microcontrollers powered by scavenged solar panels, we won't need the extra burden of post-y2038. Switch to unsigned 32-bit time_t for the sake of the (surviving) grandkids.

You keep saying this, but you're too late. The 64-bit signed time_t path was already chosen long ago and is being implemented.

Not on those.

The kernel has already been fixed, but userspace (glibc) is AFAICS still in progress. Glibc is going to do it in a similar fashion to large file support (LFS), where if you define some particular macros you get the 64-bit time_t interfaces, otherwise you'll continue with the old 32-bit time_t. Similarly, existing binaries will continue to work, so in order to take advantage of 64-bit time_t you need to recompile (with those macros set, and fixing any resulting problems of course).

I hope it means dropping the i386 distro, not dropping i386 multiarch which is still needed like for older 32-bit games and such.

I don't see much value in i386 distro these days.

386 distro and i386 multiarch are pretty much one and the same for Debian, we don't have any "cut-down" ports without a kernel, bootloaders etc.

Well, then they shouldn't be. It's less of an overhead to maintain packages that focus on multiarch use cases and drop ones that focus on making it an i386 hardware targeted distro.

Debian keeps IBM Thinkpad T41 alive. :)

I'm guessing that fewer maintainers are running i386 to the point where i386 is not "tested by default". So they're asking porters to step up and take over testing/maintaining packages for i386 if they want the i386 releases to continue.

Can you provide a link about this?

I think it may be because the software packages for i386 are closed-source, but don't quote me on that.

It's because in 2021, i386 processors are obsolescent. The last non-amd64 processor that ran x86 is the Pentium 4E from 2004, a 17-year-old machine. The packages will still be available as long as there's a maintainer, but it's not worth packaging a full debian release for such a small and shrinking portion of the userbase.

> The last non-amd64 processor that ran x86 is the Pentium 4E from 2004, a 17-year-old machine.

Atom CPUs without x86_64 support were released up until 2013.

Debian Buster LTS is supported until 2024 and then probably ELTS until 2026. Also how many of these 32-bit Atom CPUs are actually in use anymore? It's a pretty edge case.

I run my home automation on atom. Considering that cost of asus eee pc is around $70 it still is a lucrative option of a complete system compared to raspberry.

Debian is (or at least used to be) popular for old hardware - e.g. they supported m68k for longer than most distros. I had an i386 Atom netbook that I was using up until about a year ago, and if I hadn't moved internationally I'd probably still use it.

The Intel Core Duo (such as found in the 1st generation Intel macbook pro) from 2006) is not 64-bit capable.

But i386 will still run on 64 bit hardware. A place I was working recently was insisting on sticking to 32 bit linux while they migrated off Solaris, mostly for stupid reasons on code that wasn't too hard to port, but just because the hardware is no longer compatible doesn't mean the software is, especially for any proprietary software that will never be upgraded.

Debian is my favorite distro for web dev, but, MIPS is also near and dear to my heart since I learned its hardware architecture in college.

I view MIPS as the simplest possible instruction set that satisfies most of the modern scalability constraints (RISC, short pipeline, etc). It will likely be replaced by something like ARM which also incorporates instruction compression for basically free (since memory latency matters more than computing power more with each passing year).

So I'm sad to see them remove MIPS support since I think next-gen 16+ core processors will probably use it. But, after reviving more failing projects than I can count, it's not a huge deal to use old commits to re-implement functionality. Most of that work is probably around stuff like endianness issues, atomic instructions, protected memory, caching, etc etc etc. If it helps them to set it aside for now, great, but I hope that MIPS support returns someday is all I'm saying.

MIPS (Little Endian) and MIPS64 (LE) are still fully supported architectures!

Are you sure for mips? It says (emphasis added)

> We have decided that the architectures that will be part of the bullseye release are: amd64, arm64, armel, armhf, i386, mips64el, mipsel, ppc64el and s390x (i.e. the same we had for buster minus mips).

"mips64el, mipsel"

Those are MIPS, but Little-Endian instead of Big-Endian.

Thanks, got it now, I was confused by the differing notations. (I thought the parenthetical was a description, not a name.) Listening to my MIPS internet radio now FWIW (Pure brand).

> It will likely be replaced by something like ARM

Er... the spiritual successor to MIPS (as "that nice little instruction set that academics love") is definitely RISC-V, not ARM, and a Debian port for riscv64 is in progress.

Debian can always use more porters, especially for MIPS as that family of ports isn't doing great. The debian-mips mailing list should be able to help you get involved and there are similar lists and IRC channels for other ports, as well as the #debian-ports IRC channel for all the unofficial ports.

MIPS has no SMP memory model.

One could be cribbed from POWER or ARM, or even x86, but it is a paste-up.

Well, SGI used to make those huge shared memory NUMA machines based on MIPS (then they switched to IA-64, after that x86-64, and then they got bought by HPE).

But yes, I guess that's far enough back in time that they didn't have any formal model for the behavior. I guess they had some kind of prose specification, and then they just winged it.

My recollection (from discussion with an engineer on that project) was that they were using Itanium there. They used Itanium in preference to amd64 because amd64 had one fewer address pin than they memory they wanted to put on needed.

They sold multiple generations of these huge NUMA machines. First were the MIPS-based Origin 2000 and 3000 (https://en.wikipedia.org/wiki/SGI_Origin_2000 and https://en.wikipedia.org/wiki/SGI_Origin_3000_and_Onyx_3000#... ) supporting up to 512 CPU's running Irix, then came the Itanium-based Altix (https://en.wikipedia.org/wiki/Altix ) with up to 4096 cores running Linux, then finally the x86-64 based Altix UV supporting up to 2048 cores, also running Linux.

I don't know about SMP, but back in the day SGI built NUMA machines with hundreds of MIPS cores.

I just installed yesterday. I tried an in-place upgrade from Buster, but that didn't work, so I did a new install. So far, so good. It's an interesting time to be running Bullseye because it includes GNOME 3.38, which is what you get in Fedora 33 and Ubuntu 20.10.

I hit the gcc8 / libgcc-s1 migration problem when trying an in-place upgrade from Buster to Bullseye. I'm sure it will be resolved before the final release, but the issue for me was https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=961990 and several workarounds were available, but running `apt full-upgrade libgcc1-` worked for me as per https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964477#41 .

Not my distro of choice, but I very much respect their work and product

What is your distro of choice?

Big fan of NixOS - It's a hard start but rewarding

Why?

Anyone care to list the "things they wish were different" ?

Trying to remember how to build a package some months back I ran into all the old headaches. Debian packaging is ancient, and the packages don't provide all the information and functionality other package management formats do. Trying to contribute a package (much less write one) is a pain. The structure of the files and how to build them seems over-complicated, and at the same time not very useful. The tools largely rely on a bunch of weird magic variables to fix common problems. Modern conventions could be added as tool shortcuts, like installing a package once in a container and then cleaning up all the crap you don't need before saving the layer. Navigating the website requires a high degree of tribal knowledge that no other distribution does (compare looking for packages across Debian releases to looking for packages across Alpine releases, as a neophyte). Why do source packages have to be renamed when nobody else does this?

Is there a sort of "wish list" or "suggestions box" for Debian? This is something I wish I had at work, but not sure how to manage it.

The author of i3 Windows Manager has a series of interesting blog posts about his pain points with Debian project. [1] Well worth reading the blog series.

He also has a research distribution named 'distri' that tries to fix certain aspects of those pain points. [2]

[1] https://michael.stapelberg.ch/posts/2019-03-10-debian-windin...

[2] https://michael.stapelberg.ch/posts/2019-08-17-introducing-d...

> https://michael.stapelberg.ch/posts/2019-03-10-debian-windin...

This is really an excellent post. While I'm not a debian developer, some of those challenges enumerated affect end users directly as well. Like plenty of packages being single-maintainer fiefdoms, with wildly different quality of maintenance.

I thought they were both excellent, thoughtful posts. Not being an i3 user, I wasn’t previously aware of Michael Stapelberg but I like the way he’s willing to work on solutions that he has identified, e.g., he offered to create proper archives for the Debian mailing lists.

His proposal for speeding up package management also seems like a useful project. If only he had the same political clout as other prominent FOSS developers.

From what I read online, bullseye is only expected to be released in Q3 or Q4. Does anybody have experiences with using pre-release versions of Debian?

i915 GPU freeze on kernel 5.x solved?

do you have a bug report link about this?

I got micro freeze on ThinkPad x260 + kernel 5.4.x + firefox.

You can find many reports like this:

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1872001

https://bugzilla.redhat.com/show_bug.cgi?id=1843274

https://groups.google.com/g/linux.debian.bugs.dist/search?q=...

A Debian terminal version in a container is what Chrome OS distributes. So far I am completely satisfied with it, but then my needs and demands are fairly minimal...

Reply on news.ycombinator.com