Debian is my favourite OS[0]. I've been using it full time for years: I use it on my desktop and laptop (Debian testing), and servers (Debian stable). I've installed it with big success on parents and siblings computers, and the extended family's computers.
Debian takes freedom seriously[1]
It's getting better with age:
- Since Sarge (2005) there's been release every ~2 years
- Debian LTS allows you to run Debian securely for 5 years (with caveats)
Things I agree with, that may be somewhat controversial:
- Debian takes packaging software seriously (it splits the application and development files)
- Debian follows the FHS (e.g. config goes in /etc, data goes in /var/lib, etc)
- Debian stable is stable. Apart from security patches, it really doesn't change.
Other great things:
- Debian is a great base to build on (see the many derivatives[2])
Another thing I would add to your list is the availability of the DVD1,2 and 3 .iso images from most mirrors, and for sale at nominal cost from a number of DVD suppliers.
This means that you can install from scratch and subsequently add a huge amount of software locally without access to an Internet connection. Should you be radically off-grid, or confined to expensive mobile Internet access, this is a tremendous advantage compared to most other distributions that I know of.
I've recently taken an interest in NixOS after switching to Debian from Ubuntu about 2 years ago.
Could someone kindly enlighten me as to point [3]? Is the term "reproducible builds" used in the same context as NixOS? Otherwise stated, does this reflect the same goals? On the surface this seems to be the case, but I'm struggling to understand how Debian's approach compares/contrasts.
I quite like Debian, but the transactional approach to package management in NixOS is ... titillating...
Debian is currently leading the way on deterministic builds, I believe. I had a fork at one point that integrated most of the changes in NixOS to make the system tarball (what comes on ISOs) etc deterministic, but it fell to the wayside a few years ago as I lost time to work on NixOS (it works well enough on the servers I've had it on for a few years, after I put some work in).
However, there is another axis to this question that NixOS does address, which is "reproducibility". To clarify, for the purposes here, I define:
- Reproducibility: I can always create a copy of a system state, in terms of the set of steps taken to build it, given some known description.
- Deterministic: I can always exactly reproduce a copy of the system state, down to bit-for-bit replication.
To make this more explicit, by these definitions: NixOS is reproducible, but not currently deterministic (except for a few things like the kernel). Debian is becoming deterministic, but not reproducible. These do not imply each other in any direction, IMO, from the POV of a user.
The reason for this is because, in short, when you run `apt install foobar` on Debian, while you may exactly be able to build a bit for bit copy of `foobar-1.2.3`, exactly matching those results based on the Debian package, the result of actually performing `apt install foobar` is not deterministic.
Today I may run that command and install 1.2.3. Tomorrow it may install 1.2.4 if the maintainer updated `foobar`. In both cases, I could make a bit-for-bit replica of 1.2.3 or 1.2.4, given the Debian package descriptions. But I cannot, without pinning package mirrors explicitly, always ensure the act of running those commands gives the same result.
This is kind of a problem with systems like Docker, for example. Two people may run a Dockerfile running `apt install foobar` at two different times, and get completely different copies of `foobar`! So you have to base determinism on the Docker image, not on the description of the image (the Dockerfile). Because the image you built might not actually match whatever you deploy.
In NixOS, the entire 'system' is actually defined by a single Git repository (called 'nixpkgs'). That means if you and I both have Git revision 0x12345678 of Nixpkgs, and we have the same configuration file for our NixOS systems, `nix-env -i foobar` will always install the same version of foobar, as it was described in Nixpkgs, at that exact time.
In practice this means I can do awesome things, like configure my NixOS laptop in VMWare at first, get my configuration.nix right, pin down the right Nixpkgs version. Put new hard drive into laptop, start ISO, checkout right Nixpkgs git version, copy configuration.nix, hit 'nixos-install' and reboot. My laptop is now identical to what I had before. Obviously this is also great in production environments because developers can get essentially-identical setups to production environments.
Note the definition of 'reproducible' above: you will take the same steps to produce the output. This does not imply fully bit-for-bit determinism. That means if installing `foobar` requires running `gcc -O2 foobar.c -o foobar` and running `copy ./foobar /usr/bin/foobar` (roughly), both you and I will always take those exact steps to install it. But maybe `foobar.c` embedded the `__DATE__` macro into its source, so it is not bitwise deterministic.
NixOS has the story for reproducible builds right, straight from the design -- so bitwise determinism is "only" a matter of some work and not any philosophical hurdle. But it's naturally something that requires care and tooling to do correctly and there are some unresolved bits that meant I never got done with the original work. But it's nothing fundamental.
The Debian developers have really pushed a substantial amount of the work into doing all this and making these tasks feasible, fixing many upstream packages -- including helping get extensions to GCC (to make things like `__DATE__` always a specified constant for packagers), and writing lots of documentation[1]. They deserve much, much praise for this endeavor, IMO.
From a quick search a while back, NixOs determinism is lower than the Reproducible Build team efforts. They patch code to avoid all kinds of incidental variables in source (build dates, orderings).
> I think Debian is one of the few Linux distros that can truly call itself an OS, as opposed to just a "distro"
What do you mean by this? Does this mean there's some sort of "value added" that other distros don't have?
Over the years I've migrated from Slackware to Fedora primarily because of their stated goal to deviate from upstream as little as possible, but I'm always willing to explore.
Debian is much more than just a collection of packages:
- It has a social contract, which it follows (e.g. they take software licensing seriously, developers attempt to upstream changes)
- It has many, many developers (~1000). That is, the long-term health of the project doesn't hinge on one or two people. Although more developers are always needed and welcome.
- Debian attempts to integrate packages together (e.g. the Nagios package configures Apache for you)
- Debian has a lively community around it. Companies care about it (e.g. see hardware donations, money donations for things like Debian LTS, and Valve adopting Debian).
- Debian leads the FOSS community in many initiatives (currently Reproducible builds)
Can you elaborate on the move from Slackware? Fedora's philosophy is excellent and perhaps better documented, but I always thought Slackware was as close to pure upstream source as you could practically get in a single distribution.
Slackware is what you would get if you compiled everything yourself. Indeed its package manager (slackpkg) is really just a streamlined compiler, rather than a typical binary distribution mechanism.
But Slackware is also what you would get if you compiled a specific set of packages from source, and not any others. There is a decent community of packagers at Slackbuilds that has most of the big stuff, but compiling is a hassle if it's not there. Even then, if you want something like Gnome, be prepared to spend a couple of hours getting it going from the Slackbuilds packages. It also lags behind in adopting new technologies that make things easier for the users (udev and wicd pop into my memory immediately).
I started slowly drifting away from Slackware because 10-15 years ago, it was easier to get Red Hat/Fedora/Ubuntu working on my laptop, with support for things like USB thumb drives and wireless (wicd wasn't even added to slackware extras until long past when Ubuntu had this problem solved in the default installation). Most packages are mature enough to do this for themselves now, but at the time distros needed to do a fair amount of heavy lifting in terms of hardware detection and configuration to make things smooth for end users. That said, if I ever needed to get help with a program, I knew I could go straight to the project's forums because what I had installed was what they distributed, not something modified by a package maintainer. This is not meant as a criticism of Slackware, their philosophy is well established and their community will happily tell you that Open Source is about choice and point you in the direction of something that would suit you better if their philosophy doesn't meet your needs.
Fedora seemed to find that balance for me. Packages were closer to upstream so I could get help from a variety of places with minimal hassle, but it still included modern niceties and its community was much larger.
slackpkg itself actually does just wget and install binary packages. You may be thinking of sbopkg or sbotools which grab SlackBuild scripts and source tarballs from slackbuilds.org, builds and installs the resulting packages. They are extremely useful tools every slacker should have, but they're third-party (as is slackbuilds.org) and not officially a part of Slackware.
I agree. I've messed around with Arch Linux quite a bit and I like their model, but whenever I need something that just works I find myself reaching for Debian.
Conversely, as someone who has run Debian for the majority of two decades, I find myself using Antergos (Arch-like) for the things I want to 'just work'.
Again we're running into the different perceptions different people have of "just work".
As for my opinion on this: I've never used a distro I didn't need at least between 2 or 14 days before I could say "it just works the way I want it to work".
read somewhere that Debian is good for servers but not for personal use(something about broadcasting, messages not encrypted, etc), anyone with more knowledge on this care to chime in?
Debian has a user experience that is slightly rougher than a desktop-focused distro like ubuntu. It's caught up a bit recently, but you still need to be a little more technically-minded to use debian - examples: debian's main troubleshooting help is mailing lists, ubuntu's is forums; ubuntu has more 'automagic tooling' to help with things like non-intel graphics cards; debian requires you to understand it's philosophy to understand how it's resources are arranged, why it's website looks the way it does, etc, etc, but a more user-friendly distro hides all of that.
Debian takes freedom seriously[1]
It's getting better with age:
- Since Sarge (2005) there's been release every ~2 years
- Debian LTS allows you to run Debian securely for 5 years (with caveats)
Things I agree with, that may be somewhat controversial:
- Debian takes packaging software seriously (it splits the application and development files)
- Debian follows the FHS (e.g. config goes in /etc, data goes in /var/lib, etc)
- Debian stable is stable. Apart from security patches, it really doesn't change.
Other great things:
- Debian is a great base to build on (see the many derivatives[2])
Cool things to come:
- Reproducible builds[3]
[1] https://www.debian.org/social_contract
[2] https://en.wikipedia.org/wiki/Debian#Derivatives
[3] https://wiki.debian.org/ReproducibleBuilds
[0] I think Debian is one of the few Linux distros that can truly call itself an OS, as opposed to just a "distro"