Why debian rocks

Notify me of new comments via email. Notify me of new posts via email. Excellent package management tools I find that the package management tools that Debian offers is really fantastic.

Flexibility with the choice of installation of debian itself Debian offers various ways to install Debian. More suitable for programming and development In the past having used SuSE, which offered a host of gizmo stuff for managing, installation and other utilities by default, it made me feel that I was no longer in control of my Linux System.

Ports available for a large number of architectures and target device Debian is available for a variety of architectures and platforms, which further increases the user base as well as the support base.

Like this: Like Loading At any rate, Debian is good, but there are a lot of good Linux distributions out there. I use Ubuntu, but I will be the first to acknowledge debian as the fountain of Ubuntu goodness. Go Debian. Leave a Reply Cancel reply Enter your comment here Fill in your details below or click an icon to log in:.

Email required Address never made public. See Rocks Licensing. The latest update of Rocks codename Manzanita is now released. Manzanita is a bit only release and is based upon CentOS 7. The Rocks-supplied OS rolls have all updates applied as of December 1, Release notes are available. This is not a Rocks-specific issue, but Rocks-based systems are vulnerable.

Since Debian is the source from which dozens of other distros draw, notably Ubuntu, its major updates are well worth paying attention to, even if you aren't a Debian user. If you are a Debian user and you've been patiently waiting for an updated kernel to work with all the latest hardware, I have good news, the 5. More on that in a minute. First, for the Linux newcomers, it might help to understand why Debian only releases new versions every couple of years when most popular distros crank out several new versions each year.

Debian is a huge, sprawling project and probably has more moving pieces than just about any other software project around. That's part of the reason Debian releases don't come along very often — it takes a long time to get that many ducks in a row.

The other reason Debian is slow to change is that it's supposed to be rock solid and reliable. In my experience at least it is exactly that. I've been running Debian on servers for well over a decade now and have never had an update break something. There isn't a single other piece of software I could say that about. Still, Debian's infrequent updates are an oddity in a software world obsessed with "moving fast and breaking things" as some like to say.

Debian has a reputation for being a good choice for servers, but a little boring and behind the times on the desktop. That hasn't been true for a while now thanks to Flatpaks and Snap packages, but it's a reputation that lingers. For many users, myself included, Debian is like a rock in an ever-swirling sea of updates. I recently rejoined the league of Debian desktop users after a few years in the Arch camp. While I still think Arch is a fine distro, I have reached an age where I have better things to do than look after my laptop.

I want to install a system and not think about it again for at least five years. This is the use case where Debian excels and Debian 11 is no exception. It's been solid and "just works" since the RC 1 release I installed earlier this year. Debian 11 ships with the shiny new Linux 5. The 5. Debian calls itself "the universal operating system" and indeed its chip architecture support is far broader than most distros.

That makes it a popular base for developers of everything from embedded devices to auto-based systems. It's also worth noting, given that just about everyone else has abandoned it, Debian will still support i At this point, if you have a bit machine still around, Debian is likely your best option for getting a well-supported system. Along with the improvements mentioned above come the usual slew of kernel updates and hardware drivers to support new devices, including kernel-level support for exFAT filesystems.

You no longer need to install Fuse just to mount a Windows drive. If you're curious to know the finer details of everything new in this kernel, you can read through the changelog. Debian's repositories are legendarily massive and they just keep growing.

Bullseye boasts 13, new packages, which brings the total to over 57, packages. Well over half of all that software has been updated for this release, over 35, packages. That's obviously beyond the scope of what I could begin to cover here, beyond the scope of what anyone can cover anywhere really, which is why I say Debian's scope is staggering.

The distributed nature of Debian development and distribution makes it really easy to set up a separate repository of custom packages that can then be distributed in house; and the policy and build mechanisms ensure that third parties can build the system just as easily in a reproducible fashion. Support for the high quality hardware is mostly the same. I also like the multiple journaling file systems that have come into the Linux kernel recently. For desktop, the killer factor is drivers.

And Linux leaves all the other X86 Unixes behind by a mile. When it comes to portability, NetBSD is supposed to be the byword. I am sure which set I am more interested in though it might be cool to have a VAX puttering around in the basement.

Note that what NetBSD call architectures are often labeled sub-architectures by Debian, and thus do not count in the 11 supported architecture count. Source Builds I have heard a lot of things about the ports mechanism of BSD, and the portage systems of gentoo. I have also heard about how people have problems actually getting things to compile in the ports system.

Apart from the fact that compiling everything rapidly gets old I have been there, done that, when I used Soft Landing Systems SLS distribution back in ' It is not as if you can't do a port like auto build of Debian -- we have auto-builders on 11 architectures that do that, continuously, every single day -- the question is why would one want to?

I have yet to see a single, replicable test demonstrating any palpable performance improvement by local, tailored optimized compilations -- and certainly none that justifies, in my eyes, the time spent tweaking and building the software all over. Specific programs can benefit greatly, though, and you can always tweak a critical app for your environment in Debian.

I think whatever time is saved by running an optimized system is more than compensated for by the time spent building the system, and building upgrades of the system. I've heard of people running doing their daily update in the background while doing other things in the foreground. Not to mention how integration suffers by not having a central location where interoperability of the pieces can be ever tested well, since every system would differ wildly from the reference.

A source build system is also far more problematic when it comes to major upgrades -- I have anecdotal evidence of it not being as safe and sane as the Debian upgrade mechanisms.

Anyway, if I do want to build packages from source on Debian, I can use apt-get source -b, apt-src, or any of a number of tools. And when doing local builds I do trust that locally built deb's will be installed in a safe and sane way, replacing properly the old stuff. The build depends pull in any required dependencies for builds, and I routinely build in pbuilder-user-mode-linux to ensure uniform builds.

I know Gentoo also provides pre compiled binaries -- but does that not defeat their supposed advantage? For an enterprise environment where down time does cost money this is simply inadmissible and Debian provides the best solution.

Security and Reliability There is always a trade off between security and convenience -- the ultimately secure computer is one that is never turned on. Secure, but not very useful. You have to decide where your comfort zone lies. What does one think of when one says Security and Unix like OS? OpenBSD, with some justification. It is audited and has the small size, small system requirements AND the pure text based install.

If you stick to the core install, you get an audited system, with no services turned on by default and an assurance that there are no holes in the default install that can lead to a remote root compromise.

However, you tend to end up with old software, and the default install really does very little. Most people agree that the secure and audited portion of OpenBSD does not provide all the software they require. OpenBSD's secure reputation is justified - but only when you know the project, when you are familiar with what does it really cover.

OpenBSD may be a great firewall, maybe even mail or static Web server - As long as you keep out of the ports tree, you do have an audited, security-conscious system. I know few applications, however, for such a system. The OpenBSD userland ports break more often than stable Debian -- but, in OpenBSD, ports are officially not part of the system, and should a security problem appear in one of them, you are on your own.

Arguably, Debian stable equals or beats the exact claims -- and there appears to be little real world difference between Debian and openbsd at this time. One has to work a bit to harden the default Debian install with just Standard priority packages, but this is just a few minutes work for experienced admins.

Code audits are in a more advanced stage for OpenBSD; though one must bear in mind that despite all the audits there have been high profile bugs in OpenSSH recently -- so take the audited label with a pinch of salt. We have an Security team, automated build systems to help the security team quickly build versions across all the architectures that are supported, and policy geared towards those goals.

Even though you don't quite need a tool chain on every target BSD system to roll out security updates "make release", or "make package" to build on one machine and install elsewhere , it is quite a bit more inconvenient than the Debian packaging system.

Debian handles binary package distribution much better. One can have his own aptable archive and feed all productive servers from is, using Debian's native mechanisms. When it comes to real security, however, without mandatory access controls you have very little assurance. Even without SELinux, I find the rock solid stability of Debian stable, with the peace of mind that comes from back ported security fixes provided by the Security team, very persuasive.

It is easy for an untrained recipient to keep up to date with security; and reduces the likelihood of compromise. This is very important in a commercial environment with a large number of computers, where is it important that the software NOT be upgraded every few months.

There is another benefit of the Debian's Security team when it comes to the stable distribution. There is, however, only one version of the ports tree. Whereas in Debian, you have multiple versions of, e. Although, of course, the port makefile will be updated if a vulnerability has been found in a given package, the only way to plug the hole on your system in such a situation is to install the new version of the package, with all possible problems that may cause.

Compare to Debian, where you have the ability to install the same version of the software, with the security fix back-ported. Also, if you're working with a ports-installed version of the vulnerable package, you'll stay vulnerable for as long as the compilation runs, which may or may not be a considerable amount of time. I have some data comparing Linux distributions and the time to patch known security vulnerabilities, no data of BSDs, however.

Scalability and Performance I was not initially going to talk at all about performance and numbers, since these have mattered little to me personally, and performance numbers change from release to release.