Debian turns 23(bits.debian.org)
bits.debian.org
Debian turns 23
https://bits.debian.org/2016/08/debian-turns-23.html
56 comments
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".
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".
> 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.
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)
- 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.
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'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...
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:
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.
[1] https://reproducible-builds.org/docs/
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.
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.
[1] https://reproducible-builds.org/docs/
If you want `apt-get install foobar` to always do the same thing, just use snapshot.debian.org in your apt sources.list:
deb http://snapshot.debian.org/archive/debian/20091004T111800Z/ lenny main
deb http://snapshot.debian.org/archive/debian/20091004T111800Z/ lenny main
Many thanks for the explanation. I hadn't quite grasped the difference between "reproducible" and "deterministic" in this context.
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).
"They" being Debian, I presume?
The guys behind the reproducible builds. I don't know how much "in" debian they are.
Reproducible builds are a cross-distro effort that is spearheaded by folks who started doing Debian reproducible builds.
https://reproducible-builds.org/who/ https://wiki.debian.org/ReproducibleBuilds/History
https://reproducible-builds.org/who/ https://wiki.debian.org/ReproducibleBuilds/History
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.
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.
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.
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.
Link to 8.5 on x64: http://cdimage.debian.org/cdimage/release/8.5.0/amd64/iso-dv...
~13 years ago, I picked up a KNOPPIX 3.3 CD on the front cover of Australian Personal Computer and experienced the wonders of a Debian-based distro for the first time.
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!
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!
13 years ago, I downloaded Debian stable. The 'nv' driver for XFree86 didn't work on my machine, so my first Unix experience was learning how to use vi to edit the configuration file. Never did get it to work, but Knoppix did (in those days it had famously good hardware detection - I think the key might have been using the 'vesa' driver instead of 'nv').
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).
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).
All those, uuuuuh, positive and happy memories of editing modelines in XF86Config...
Mandatory xkcd reference: https://xkcd.com/963/
I tend to agree with the graph, though - editing XF86config / xorg.conf was not a lot of fun.
I tend to agree with the graph, though - editing XF86config / xorg.conf was not a lot of fun.
My first GNU/Linux experience was with Red Hat 5 on an old hand-me-down laptop during the late 90s. For the first two weeks I couldn't get X to work so I got plenty of command line experience and learned enough vim to edit XF86Config. Still, it was a piece of cake compared to configuring Sendmail!
I understand the desire to keep corporate communication positive, but it's sad to see the absence of Ian Murdock so soon after his passing.
Strangely, Murdock's death is mentioned, but not a word about his founding role.
The linked timeline at https://timeline.debian.net/ has entries linking to announcements by Ian including the annoucement of the first official release; "Debian GNU/Linux 0.93R6 released" -- https://lists.debian.org/debian-announce/1995/msg00007.html
I'm old enough to remember all the "Debian is dying" posts on Slashdot back in the day. As a very happy convert since the potato days, it's amazing how far Debian has come and a testament to the power of free software. Go Debian!
Potato was my first eyesore as well. Win98 kept on crashing on me, so one day I borrowed the CD from one of my professors' desk and tried installing. Three days later after lots of probing for my network card and then lots of elinks browsing to get the xfree86 configuration working, I ended up with my first graphical interface. (xterm, running xeyes)
Good old days!
Good old days!
> I'm old enough to remember all the "Debian is dying" posts
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...
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...
Debian you are my hero! And I cannot think of a more fitting tribute to all of Ian's hard work. This is how he should be remembered.
I've been using various forms of Unix, Linux , and BSD since 1998. Early days were a lot of Slackware, and eventually moved into FreeBSD, where I was happy for years. In the end the usability, stability, and package management of the Debian system has me using it for all of my server setups. I've found it the easiest of the Linux environments to get up and running quickly. It's what I would consider the "standard" for a Linux OS at this point.
After fighting RPM hell so much in the late 90s, Debian linux was such a revelation. I've been using Debian and its derivatives ever since.
I used to use debian. But their bureaucratic self righteous organization have -at my own personal- opinion created a drift between them and upstream packages.
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
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
For my birthday in 1996, I ordered a Debian CD and some game. I played the game once or twice, but am still using Ubuntu, a Debian derivative. Debian has its faults, but has done a lot of good work over the years.
I've been using Debian for ever .. but honestly it's mostly b/c the critical mass it has. If I have a problem it's pretty straightforward to find solutions. I think there are distributions that are more advanced and interesting (NixOS) and with quicker updates to their packages (Arch), but since I don't want to fiddle with my computer all day I just use use Debian.
Maybe some day something a little more modern will take off but for the time being I'll stick to what works - Debian
Maybe some day something a little more modern will take off but for the time being I'll stick to what works - Debian
around 17 years ago i remember flapping betwee slack and debian .... debian package management was always superior so i stayed ... still using debian today.
Also remember that I've always liked gnome-panel but not the whole desktop env , so i would use window maker + gnome-panel :) .
Never did get into Debian, only because the configure files were in different locations than red hat, at least back in the day. Using fedora and Slackware.
I a week ago I upgraded an oldstable debian installation to stable and now it hangs on shutdown and reboot due to systemd.
Thanks Debian.
Thanks Debian.
Does anyone know what happened to the case of the debian founder?
Don't use stable. Stable doesn't mean what you think it means. It means that, among other things, it doesn't get any major updates to core software.
Some notes as to your use case would add to your comment I think. I have in the past run Sid (aka Unstable) for non-critical use on a laptop without too many issues.
major problem with unstable is that you get completely addicted to upgrading your system each time a package evolve. That's a huge time sink, thanks Debian :-)
> It means that, among other things, it doesn't get any major updates to core software.
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.)
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.)
_RPM(3)
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"