Debian turns 23
bits.debian.org
bits.debian.org
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"
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".
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.
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.
- 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)
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...
https://reproducible-builds.org/who/ https://wiki.debian.org/ReproducibleBuilds/History
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.
deb http://snapshot.debian.org/archive/debian/20091004T111800Z/ lenny main
I think maybe the encryption issue you refer to is a really bad bug several years ago (2008?) with SSH keys. Nothing that bad since, I believe.
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.
http://sohcahtoa.org.uk/pages/wheezy-offgrid.html
Above works more or less the same way for Jessie. Links to DVD iso images need updating as Wheezy has now been archived.
13 years later, and here I am, still using Debian on my home desktop, my personal laptop, my work machine and my VPS, and working professionally as a Free Software developer.
So thanks, Debian devs!
The graphical environment provided by Knoppix gave me enough comfort to learn how to use the command line and install the proprietary NVIDIA drivers, and I was running pure Debian a few weeks later, and still am on my laptop (although I now prefer OpenBSD on my server).
I tend to agree with the graph, though - editing XF86config / xorg.conf was not a lot of fun.
Good old days!
Sadly, the Ian (Ian Murdock) in Debian did pass away (death had something to do with police). http://arstechnica.com/information-technology/2015/12/ian-mu...
Countless decisions of debian maintainers (that are proficient at packaging and NOT at coding) to think of themselves has «smarter» than upstream open source software maintainers have resulted in countless teeth grinding:
- the openSSL randomness «fix» that resulted in openSSH being shipped with only 65535 potential keys
- the complexity of building clean src vs bin packages (in opposition with RPM or slackware packaging) and the numerous kombinat called debian helpers makes packaging a hell,
- latex packages being a tad broken
- ruby/python packages requiring a tad of contorsion to have them work the way they were inteded to work natively (the overzealous package slicing which in python/ruby required you to install non trivial package to use gem/pip)
- the multiplication of packages for «ease of use» that cluttered debian with so many fixed dependencies hell that it makes stable often hard and slow to upgrade vs testing that can break and the hell of version pinpointing
- the bureaucratic approach of splitting configurations in so many directories that it is mind blowing and as usual not always following upstream simpler conventions
- poor default config (like apache cgi-bin being global to help install 3rd party modules)
- and the debian community above all that has taken «the melon» and kind of been evolving to be a tad overconfident leading to impose choices that are more than disputable to the users (such of course as systemd) but let's say that ubuntu having sucked most of their community of maintainer during the split it is even more obvious that they have a «microsoft» syndrome of we know better than you what is good for you (desktop choices...)
As a result, I have almost happily left debian as my main OS, but I still am hating that «securing/hardening» an OS after default install has become the norm in free/open source main distribution.
The more I have seen open source project take a turn of «sectarism» the less I am convinced in the so called intrinsic values of openness in free software.
Yet, there are still enough valuable open source projects out there for my comfort
Maybe some day something a little more modern will take off but for the time being I'll stick to what works - Debian
Thanks Debian.
That is the whole point of "stable". It does get security updates and bug fixes, of course. Most major Linux distros work that way (except for rolling release systems like Gentoo or Arch, of course) - once a version is released, the versions of the software packages are frozen. In return, you get software that is usually very, well, stable.
So "stable" means exactly what I think it means.
(Anyway a general phrasing like "Don't use stable" is useless - different people have different needs, and for a lot of us, Debian stable works very well, thank you very much.)