I blogged about why #Debian is the way it is.
@liw The thing about the release naming; I don't understand how naming avoids the problem?
@penguin42 @liw I think the missing piece here is that Debian does assign versions, but they only appear as such in the archive once the release is actually official as opposed to being in preparation.
@cjwatson @penguin42 I don't remember all the details, and I couldn't find links to discussions back then, but my memory claims that the idea was that code names are less likely to be misunderstood as finished releases.
The later development of the archive pool structure and `dists` directory handle this betterer.
@liw @cjwatson @penguin42 Also, you can switch a server (or any machine) to the new stable by name (the “close to be new stable”), and not had it become something different under you after release (if you switch by using “testing”). I always thought that was one of the main benefits.
@penguin42 @liw I've been a Debian developer for 22 years and I still have to look up the numbers when I need them.
@cjwatson @penguin42 @liw on the flip side I can give you the numbers but I usually have no idea how to order buster, bullseye and bookworm.
@cjwatson @penguin42 @liw I've been a user about the same amount of time and I keep forgetting what Debian version I'm on. It changes every two years! Who can keep up with that.
I think the last few have started with b, so I'm on breezy or bullseye or bookworm or something.
@JordiGH @cjwatson @penguin42 You can open a terminal and run the command "watch lsb_release -a" and you never need to wonder again.
(The watch command is there so that it updates, just in case the version changes without a reboot.)
@liw @cjwatson @penguin42 No, I mean, I know, but I can never remember unless I look. It's like trying to remember my age, y'know?
@penguin42 @liw A nick name is not a fixed release. It was mainly to avoid pre-mature CDs and such ... You would be having a hard time selling "Debian Buzz", or at least that made it clear to the user that it wasn't Debian 1.1 or whatever.
@penguin42 @liw Yeah, it is not obvious at first, but there is a virtual release "stable", which is just a symlink in the ftp tree, so releasing a new version is just a matter of pointing that symlink to something else.
@liw Interesting, thanks!
FYI: there is a small typo: "An obviously solution" -> "An obvious solution"
@liw "that consists only of free and open source software" -- a goal that Debian got rid of.
@amszmidt No, it didn't.
@liw It very much did, and it isn't the silly "everything is software" shtick anymore (wrt to the GFDL). Debian now installs non-free software automatically without the users consent.
"From Debian 12, the installer will automatically check for needed firmware blobs and add them as required. If you would prefer it not to, add ..."
@amszmidt Right. I assumed that was you meant.
You're intentionally distorting the situation, like a troll. I have no tolerance for that. Bye.
@liw great read! even for someone who is familiar with the most of the ideas behind the project.
@liw oh, I wasn't aware of the origin of the constitution. what was the leader's overstep about?
@ilmari I don't think the details are relevant to my blog post, so I'm not going to discuss them here, sorry.
@ilmari
Bruce Perens
@liw I appreciated your perspective.
One thought which occurs to me is that Debian is not that large. It is roughly as large as it can be, given its approach to packaging and releases, but there are much larger distros; in particular, Arch and NixOS have many more available packages: https://repology.org/graph/map_repo_size_fresh.svg
This isn't a bad thing, but it does highlight how size is relative to our choice of gauge.
@corbin @liw That is a fascinating chart. I've done a little bit of packaging for both Debian and NixOS at times and I'm not quite sure what explains why nixpkgs has, what, twice the number of packages as any of the Debian-family distros.
I'm really curious if there are lessons that other free software projects can take from a comparison and contrast of these two approaches, or for that matter that these two distros can take from each other. I used Debian exclusively for something like 17 years before switching to NixOS and I still have a great deal of fondness and respect for the goals and structure of Debian as an organization.
@jamey @liw @michelin I think it's a mix of two effects.
First, there's the confounder of AUR, which isn't as fresh as nixpkgs but bigger than Debian and most other distros. I think that this is wholly due to allowing uploads from nigh-anonymous users, which isn't part of any other distro's contribution path.
Ignoring AUR, it seems like there is a correlation between fresh packages and total packages, which could easily come from folks tending to add packages at relatively fresh versions. So, the question is why nixpkgs has so many packages in toto.
At the current point, I think it's structural. nixpkgs doesn't just have descriptions for building packages, but also for unit tests and integration tests. Nix's design allows for caching the results of tests, somewhat. This means that the angle of repose is better; the cost of augmenting the tree of packages is smaller than in Debian.
@liw everything is the way it is because it got that way
@liw quality writeup!
@liw I think for folks that are really new there's still some fundamentals missing. in particular "self-contained" and "no bundled libraries" don't really make sense without an understanding that Debian fundamentally cares about its users' experience more than it cares about upstreams - that's why it offers stability guarantees and that's why it has its own security team that doesn't like bundled libraries, as opposed to having no/a significantly smaller security team and a reliance on upstreams to bump vendored libraries when appropriate.
there's a healthy amount of distrust of upstreams' processes in Debian and that's a feature. but that can be hard to understand as a newcomer who's wondering why all the software is so old.
@liw
I lived through most of this, but also due to advanced age had forgotten a lot - thanks for the refresher! I've been using Debian for well over 20 years, but I have to say the apparent inability to resolve the usrmerge controversy is beginning to make me doubt the health of the project for the first time :(
> Debian insists on being self-contained.
> Anything that is packaged in Debian,
> by Debian, must be built (compiled)
> using only dependencies in Debian.
> Also, everything in Debian must be built by Debian.
I appreciate this very much. It is absolutely awesome.
@liw Pretty good writeup. Debian is the most stable OS I've used, period. It's also the only OS I've used in which the OS being at fault is pretty much never a possibility when troubleshooting
@liw tysm! learned a lot
@liw Great post! Q: what constitutes Debian? Which packages are a "part of" Debian, and which ones are just packages? How do you decide that something should be moved in or out?
@liw Interesting article to read, thanks. Debian needs many persons to manage all of it. Any view of today and future - are there enough of persons to manage Debian?
@liw Thank you, quite enjoyed the post, learned a few things
@liw Bogus final sentence: "Debian developers tend to be conservative in technical decisions. They often prefer solutions that don’t require large scale changes."
@dyne Why do you say that?
@liw transitioning to systemd was a large scale change
@dyne I see. You're trolling, Please don't. Good bye.
@liw
> For example, current programming language tooling often assumes it can download dependencies from online repositories at build time, and that is not acceptable to Debian.
This is a terrible state of affairs and a full blog post on dealing with that would be useful.
Also, I for one, think the contrast between the two oldest distubutions: Slackware (17 July 1993) and Debian (August 16, 1993) is intriguing. Slack is still basically a one man shop and has such on old-school feel.