Debian 11 formally debuts and hits the Bullseye The Debian project has released the eleventh version of its Linux distribution. Code-named Bullseye, the distro emerged on Saturday and will be supported for five years – a lifecycle made possible by its use of version 5.10 of the Linux kernel, which is itself a long-term support release that will be maintained until 2026. …
Feature creep would be the main one for me. The creep of systemd is enormous, overly complex, it has rapidly become a giant monolith.
Red-hat installed their resources (people) into a lot of Linux distributions to shove this down peoples throats.
It started with init, and is now slowly swallowing everything, EVERYTHING.
Feature creep, what do you mean?
Just doing a bit of troubleshooting, don't mind me..
Now where was it I needed to go to find out what DNS servers I am using? /etc/resolv.conf? Nope, not there. Now, I'm sure I put them around here somewhere. I'd forget my head if it wasn't bolted on, must be getting old...
Mutter, mutter, grumble, grumble, kids these days, grumble, grump, get off my grey beard....
Much as I like to take the opportunity to recommend FreeBSD as a SystemD-free alternative, I checked one of my Debian deployments, and the DNS servers are in /etc/resolv.conf.
However, I am aware, that unlike FreeBSD, should you want to change your DNS servers, it isn't as simple as just editing the aformentioned /etc/resolv.conf; you have to edit /etc/network/interfaces then do something else to get it to update /etc/resolv.conf
No it isn't [/Cleese]
There must be something missing with your .conf, whenever I edited my resolv.conf the change was immediate.
In fact, for all the gnashing of teeth about systemd, base Debian netinstall is free of NetworkManager and Systemd-resolved out of the box, you have to go out of your way to activate them.
Of course, if you pile up "Desktop" and "GNOME" (phear!) in tasksel, all that cr*p starts to come to the surface...
I ran into this very problem when making it possible for an RPi (using Raspbian which is based on Debian and has systemd) to act in several wireless modes including AP and Wifi Client, and during startup you have to tweek things LIKE resolv.conf - I think the utility might have been 'resolved'. It's unnecessarily confusing, though (typical of things related to systemd).
The fact that you can still work around systemd to make something cool happen is pretty good. I just hope that the remnants of more 'traditional' network setup do not disappear. Assuming that the future direction will be MORE choice for init systems, it's looking ok.
Re. NetworkManager, when I first hit it it annoyed the p*ss out of me too. In static server installs, it still does.
But I'm presently rolling an application designed to turn a Pi into a network appliance, with the usual Network Appliance gubbins: creating a wifi hotspot, joining an existing network, that sort of thing. And I have to say that while this is absolutely possible without NetworkManager, it's saving me an awful lot of work. "nmcli" lets me create and destroy a hotspot with a one line command - love it.
This post has been deleted by its author
... how does it affect you as a user?
How?
I'll just quote comments from other comentards here at ElReg:
"Systemd also has its dirty fingers into other parts of the system. As a replacement for sysvinit is is supposed to be an init system, but because its scope goes far beyond the initialization phase (and it doesn't let you take the good without the bad) it has become a dependency for many userspace programs that should never have any reason to interact with the init system at all, making it harder to use those programs on a non-systemd system."
---
" ... takes root in its host, eats massive quantities of resources as it grows, spreads unchecked into areas unrelated to the initial infection, and refuses to die unless physically removed from the system, all the while doing absolutely nothing of benefit to the host."
---
That's how.
In a nutshell: systemd is nothing but a developer endorsed registry-class virus set up inside Linux distributions, just like the registry in MS OSs from W95 onwards.
O.
New versions of Debian & derivatives such as Devuan are usually quite usable long before the official release. I'll be switching my main laptop over as soon as I find time. I installed it on another recently & it seems OK. I had Beowulf running on a Pi for my NextCloud server many months before release.
This post has been deleted by its author
At least "Support for init systems other than systemd is significantly improved"
That is climbdown enough for this release, really good to see the Debian community abandoning its burst of ego-driven attitude.
Hopefully, the day is now in sight when Devuan will have made its point and be merged back into Debian.
"Support for init systems other than systemd is significantly improved"
To this day I still do not know what possessed the Debian Project to adopt Poettering's aggregated kludge as the init system for Debian (and hence downstream distributions too).
As with MX Linux, there ought to be easy user choice, not just increased support.
... day is now in sight when Devuan will have made its point and be merged back into Debian.
No.
I . don't . think . so.
You see, trust is like a unique and thus irreplaceable crystal decanter: it must be handled very carefully.
But if you are careless and break it, even if in just two or three pieces, it will be irreparably lost.
Never to be the same thing again.
Yes, you may eventually be able to put the pieces back together.
But it will never be the same crystal decanter as it has been broken.
Such is what happened with Debian and the systemd debacle.
So ...
Devuan merged back to Debian?
As far as I am concerned, not unless hell freezes over.
Twice.
O.
Most desktop users will never have a problem with systemd, but it has issues. The creep and resource hunger are very unpromising, and it's likely beyond salvage. That being said, sysvinit has been outdated for some time, and nobody has produced alternatives seeing the adoption levels of either yet. Until that happens, it doesn't matter what side of the divide you're on, it's a pretty shit place to be once you look past the "my 15 year old computer can still run it!" and "it's what I'm used to!" argumentd the louder side often brings out.
from the article: Support for init systems other than systemd
so the DEFAULT is to use systemd, but apparently easier to switch it out for something SANE.
(I was somewhat impressed by this in any case, a happy surprise)
Still using Devuan, which is based on Debian, but I'd think that Devuan maintainer's job just became easier.
You could kinda say that default Debian comes with GNOME, just like it comes with systemde, and forget that there's a Mate and LXDE (and others) desktop setups available, too.
This post has been deleted by its author
I haven't seen a "Big Ender" build of any OS for quite a while. Used to be thought that Big Endian would run faster on certain hardware and be advantageous for networking. I'm pretty sure ARM can still do it or maybe that was just ARM32. But if it doesn't matter for performance, might as well keep it the same, yeah. Still might be a fun comparison test. Every time you need to flip byte order (htons, ntohs) it adds to the execution time and footprint. On "Big Ender" systems, for these kinds of function calls the compiler doesn't need to generate any code.
> New features that the project saw fit to single out as noteworthy include:
A benefit is an attribute that a user wishes to have / use
A feature is something the manufacturer included in a product.
There is frequently little common ground between the two.
For example, the new Tesla 4XXX features a built-in pizza oven. Compare that with Tesla 4XXX owners will benefit from double the range of the previous model.
I do wish O/S producers would stop listing features and show how user-orientated they are by mentioning a few benefits, from time to time.
A feature is something that is included, like the native exFAT support (which was absent), right? What you are complaining about is that they don't say: "The feature 'sane-escl' comes with the benefit of driverless scanning", which I find overly verbose.
Or would you rather have them say "benefits: driverless scanning (thanks to same-escl)" - which is indeed what they did (except calling it a feature, which is worng, though it is enabled by a feature making it rite again, write?).
To me the list featured in the arcticle (for the benefit of the reader) is a combination of benefits I would have wished for (native exFAT, easier scanning and prining) enabled by new or improved features (things installed in the car, or in this case computer).
But then maybe the finer points of that language elude me, for it is indeed not my native tounge. In that case I really would like to understand it better.
[you can keep all spelling mistakes you can find, but maybe writing worng wrong is the rite whey? Or I might just be a lazy sod.]
It's hard to benefit from something that's not been provided, ergo a feature is there to be used should you wish, and in using it, you may benefit from it.
If you frequently get an urge for fresh Italian-derived cuisine while driving your new Tesla 4XXX, then the inclusion of a built-in pizza oven is indeed something you will benefit from. If you only use your Tesla 4XXX to pop down to the corner shop once a week, then you're not really going to benefit from the extended range.
Good.
I have no problem with people using systemd as an init. There are a bunch of cases where it's obviously the right choice. What I have always objected to is the amount of pointless integration forced on us where if you're not using it it a bunch of utterly unrelated things break because of the hateful level of scope creep in the thing.
11.6. And how about Debian and traditional System V init?
Debian supports booting using traditional System V init, via the sysvinit-core package. The configuration file for System V init (which is /etc/inittab) specifies that the first script to be executed should be /etc/init.d/rcS. This script runs all of the scripts in /etc/rcS.d/ by forking subprocesses to perform initialization such as to check and to mount file systems, to load modules, to start the network services, to set the clock, and to perform other initialization.
After completing the boot process, init executes all start scripts in a directory specified by the default runlevel (this runlevel is given by the entry for id in /etc/inittab). Like most System V compatible Unices, Linux has 7 runlevels:
0 (halt the system),
1 (single-user mode),
2 through 5 (various multi-user modes), and
6 (reboot the system).
reference: Chapter 11 - https://www.debian.org/doc/manuals/debian-faq/customizing.en.html#sysvinit
While I haven't had a chance to look at Bullseye yet, given that it just came out, I assume that the normal Debian installer still doesn't give a choice of the initial init system and forces systemd. However, since they are now saying they have better support for sysvinit (yay!), I imagine the same steps I've been following since Jessie will apply.
After initial boot:
apt-get install sysvinit-core
reboot
apt-get purge systemd
Create /etc/apt/preferences.d/systemd-blacklist to keep systemd init away:
Package: systemd-sysv
Pin: release o=Debian
Pin-Priority: -1
> Eight CPU architectures are supported. Namely:
>
> 32-bit PC (i386) and 64-bit PC (amd64);
Really it should be 9 CPU architectures -- i386 and amd64 are different in this regard, notably using different Debian install media.
In fact it is listed that way in the Debian release notes linked from TFA.
</pedant>
On one device I use Linux Mint which is a Debian derivative. On my two desktops (kept at differing locations) I deploy openSUSE. The latter is through habit because its was the first distribution I was happy with a couple of decades ago and I remain content. Sometimes it is convenient to run a minimal Debian system within a virtual machine on openSUSE.
That said, I am confused as to justification for multiplicity of variants based upon a core distribution as is so for Debian and some others. Options for stable releases, for quasi-stable rolling releases, and for very much at one's own risk 'cutting edge' versions make sense given varying needs among users. However, beyond those what is justification for additional bespoke general use versions? The underlying architecture of each bespoke version is pretty much the same and mainly transparent to ordinary users. The most visible difference rests with default GUIs. Nowadays, on every (?) distribution/variant the user may easily install any of the commonly available GUIs or settle for command line and the X Window schemata. Indeed, if one wishes one may easily swap among GUIs on the same computer.
Compared to MS Windows, Linux is new on the block and mysterious to many potential users. This disregards Linux's roots in the well tried and powerful UNIX systems deployed for several previous decades upon mainframe computers. Thus, in many respects Linux is the most mature and reliable operating system across the range of modern devices. So why the apparent fragmentation now Linux is well established?
Continuing existence of major quasi-commercial distributions such as Red Hat and openSUSE is explicable from their origins and their underlying business models of free open source software with competition for maintenance contracts from corporate users. Nevertheless, that doesn't explain the plethora of additional bespoke versions. Windows and OS2 have retained their identities but open source Linux variants give impression of volatility rather than their true underlying stability.
All of them currently miss key features or are artificially crippled in some way. Fedora/RHEL restricts what ships for legal reasons and discriminates against non-SELinux LSMs, Debian lacks enough resources to backport security fixes for desktop software in a timely manner, Ubuntu foists Snaps on you and ArchLinux doesn’t QA due to a lack of testers (try using it in a Hyper-V VM as a pen testing distro with a desktop environment on Windows Server 2012, been broken for many months).
Heck, the Linux kernel project can’t even encourage uniformity between distros. There’s no reason SUSE, Ubuntu and Debian developers can’t all agree on a base kernel version (namely, LTS builds) for stable releases and work together to provide long term support for said kernel version as the default to avoid the constant stream of quality regressions which happen on the desktop. This problem only gets worse when folks look at the Linux Standard Base userland components, which could benefit from stable distros teaming up to all maintain a common base system for say 5 years rather than constantly duplicating work.
The irony is that if Microsoft used properly version-tagged DLL names and produced its own “Windows distribution” with well-tested versions of Free Software including libraries and runtimes.. it would probably use less RAM and offer far better stability than most Linux distros do today. It is mostly because Windows encourages bundling of DLLs outside the base OS (rather than centralised management) that everything uses so much more RAM and why it’s such a nightmare to maintain. Ditto for macOS, where Apple should have long taken the initiative to bring homebrew in-house as a means to offer better library support to software developers…
why not a single DVD? Traditionally this has been the case. Subsequent DVDs just have other packages on them. I normally do a net install though, so I burn a CD (or just use the IMG for a VM) with the net installer and let it rip for a few hours downloading and installing. Net install is usually pretty small, WAY less than the size of a CD. But the DVDs typically have a live system which sometimes makes fixing things easier.
I should probably verify it but chances are it's still the same as it's traditionally been.
This post has been deleted by its author
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
