Slashdot Mirror
Debian Freeze Process Begins
EmilEifrem writes: "Everyone and their mom will have submitted this, but woody aka testing aka Debian GNU/Linux 3.0 is entering frozen stage. Check out the announcement at DebianPlanet." The freeze process is different from previous freezes; read the announcement for details.
The problem with systems like Slackware is libraries -- there is simply no way to upgrade individual packages without a significant chance that other packages will break. If you simply upgrade your entire system at once, them perhaps that isn't an issue. Or if you don't mind having a broken system for a few days while you sort out which incompatible version of an obscure library stops your favorite window manager from starting, then I guess it isn't an issue either. Does experiencing such problems teach one about Linux? Yeah, I guess it does. I sure learned a lot from Slackware and even earlier distributions that I used in the early '90s. So much in fact, that Linux isn't just a hobby at home for me anymore, but also a tool which I use for work. And there, fiddling with libraries for hours just isn't acceptable. And that's why dependencies are useful -- even for gurus who *can* solve problems, given enough time.
Today, everybody I know has a fast connection to the internet and can download the relevant packages as often as is necessary. And everybody has a fast computer on which to recompile the software they use nightly, if necessary.
The trouble with comments like these are that they're simply untrue at best and cravenly elitist at worst. They smack of "I got mine, the rest of you are just SOL I guess."
When I worked ISP tech support, I reserved my foulest curses for Rockwell and USR, who used a totally invalid test (making an interstate call to a toll-free number) to try to tell people whether or not their phone lines were capable of 56K. I had to field literally hundreds of calls from people that went just like this:
"But the modem test said I was OK!"
"The test is wrong."
"But how can it be wrong? They make the modem. I think you don't know what you're talking about. I just spent $200 on this modem and I want 56K!!!"
Even people getting better than 33.6 wanted that last few K and demanded that we satisfy them. Particularly galling were the people who canceled their service in disgust, then went to a competitor, where because of different PSTN vagaries they were able to successfully get a 56K connection, and then called us to gloat about how they were smarter than us geeks who didn't really understand how things worked.
The point of that rambling little tale is, at the time 56K was hitting the scene, fewer than 5% of American residential phone lines were even capable of 33.6 -- 56K was a pipe dream for everybody else. If the figures I see in the PAC ads on TV are to be believed, fewer than 8% of American homes now have "broadband" Internet service. I submit that at least as restrictive as the political maneuverings is the technical limitation of an aging, patched-up telecomm infrastructure. Just taking DSL as an example, it traditionally does well in places with brand-new infrastructure, or places with older infrastructure that hasn't been stressed by population growth. In Charlottesville, VA, there's almost noplace in the city that you can't get DSL from one of a handful of competitors, but a hundred miles north in Northern VA, it's touch and go. If you can't get traditional xDSL you can usually get IDSL, but up here even that's iffy if you live in an apartment complex (and they are legion) that was put up cheaply when the population exploded. They don't have niceties like conduits from the phone closet to the apartment; the lines are just run wherever and if you don't have a free pair already you can forget about getting a new one.
Not everyone enjoys access to broadband; in fact, because of a variety of reasons, the majority can't get it yet. Don't assume that what's true for you and your friends is true for everyone in the country or on the planet.
As to the issue of compiling everything because the computers are fast, a) Not everyone has a fast computer (my fastest one is a Celeron 433), b) Not everybody wants to be constantly compiling from source. It's frankly a pain in the ass and I speculate it's one reason the BSDs haven't caught on in the desktop market even to the extent Linux has. Linux's great strength and one of the main reasons it became the force it did was that it made older "obsolete" machines usable for real work again. Let's not unnecessarily dump that over the side for some vaguely-perceived efficiency that will likely as not evaporate like a puff of smoke on close inspection.
-- Old Man Kensey
well, i can only assume that the joke was calling the new slackware release "8.0" after two 7.x releases, and no major functionality changes.
---
the bsd ports system is interesting, but it takes forever to install anything since it all has to be compiled, and it's dependencies compiled, and it's dependencies' dependencies compiled, ad nauseum.
i'd hate to try installing kde or gnome on a *bsd box. it would take a bleeding eternity.
ymmv, i've only used openbsd. and i know that openbsd is trying to get a binary package system set up, but when i tried it (shortly after the 2.9 release) there were no binary packages for it.
---
I thought Progeny Linux was based upon the current release of Potato.
Are they just going to be quietly rev their version when Debian 3.0 comes out, or will we get a new box out of the deal?
Jay (=
Welcome to the woody freeze.
As previously proposed, the freeze will proceed in four phases: first policy will be frozen, followed by the base system, followed by standard installs, and concluding with the remainder of Debian. The aim of this first part of the freeze is to finalise our expectations of the release (what we want packages to look like, what architectures we're going to release) and to prepare ourselves for the freezing the base system by ensuring that the base system is releasable.
Note that this does not involve a freeze on package development yet: bugfixes, and new features are still welcome, and will continue being added to woody in the usual way. What it does mean is that your packages will be frozen in the near future, so now is probably a good time to limit yourself to only introducing new features that have already been heavily tested upstream, and fixing bugs.
In detail, the goals for this phase are:
Finalise debian-policy: accept any further proposals that woody packages should concern themselves with; and ensure -policy is a useful document for people working on quality assurance.
Deadline: final version of debian-policy for woody needs to be uploaded to the archive by July 21st.
Finalise our target architectures. As well as alpha, arm, i386, m68k, powerpc and sparc, we have the opportunity to include ia64 (Intel's new 64bit Itanium architecture), hppa (HP's PA-RISC architecture), mips and mipsel (SGI and Decstation machines), too. Requirements for inclusion in woody are fairly simple and have been met, or are close to being met, by all those architectures. For reference, they are: a working, relatively stable toolchain, a usable system (including all of base and standard; and a fair chunk of optional and extra), and a functional install. (Hurd people, see below)
Deadline: someone from each architecture that wants to release needs to mail -release with their current status, and a successful install report by July 24th.
Determine whether cryptographic software can be moved from non-US/main to main. Ben Collins (project leader) is hustling this through the appropriate avenues.
Deadline: legal advice needs to be obtained by July 21st.
Ensure the base system is releasable on all architectures: this means making sure we know what packages, exactly, the base system consists of on all architectures; and fixing any and all release critical bugs (ie, with severities critical, grave or serious) in those packages.
Deadline: base packages need to be free of RC bugs by July 21st.
If all goes well, the next phase will begin on the 1st of August. If all goes incredibly well, we'll release in November. Ha ha ha.
The main risk that may affect moving on to the next phase is the possiblity of finding release critical bugs in the base system that take significant amounts of time to fix.
As you've noticed by a careful analysis of the subject line, the woody release will be numbered Debian 3.0, in recognition of the large number of changes made since potato. This is, to put it mildly, a somewhat controversial decision, but it's one I get to make. Personally, I'm pretty happy with the way woody's progressing, and I think by the time it's released it'll easily live up to that number -- and by that I mean the "3", not the ".0".
On the subject of controversial decisions, one I'm not going to make today is what to call the release after woody. That one will be made when woody is released and a new testing distribution is forked from woody. Besides which, I still haven't gotten around to rewatching Toy Story.
While I may not be too concerned one way or another about the name of the next release, I do have some ideas about how it might be good to handle the next release. My overriding goal for this release was to manage to get a short, controllable freeze; one that we can get over and done with in a few months, rather than letting it drag on for seven months with no end in sight, but this came at a cost of letting the development cycle go on for quite a while: ten and a half months, as it turned out. For the next cycle (assuming this freeze actually turns out to be relatively short and controlled), I think it would be interesting to see if we can do the same thing again, with a short (2 or 3 month) development cycle, for a 5 to 7 month release cycle.
Which would mean you mightn't need to worry too much about not getting the neat new feature you were planning on working on into woody, if that's any consolation.
And on that note, I'm inclined to think Hurd is probably better off targetting the next freeze, (in, say, six to eight months from today) rather than woody. In particular, Hurd is at present both a difficult target to port to (and thus has a quite limited range of software when compared to the Linux ports of Debian) and isn't able to self install.
In short, the freeze, she is begun. Have at it.
Cheers,
aj
Stupid job ads, weird spam, occasional insight at
So, does it comply with the recent Linux Standard Base 1.0 document?
load "linux",8,1
I noticed they mentioned MIPS - Which leads me to a question... What other options of OS do I have on an SGI Indy? This debian announcement leads me to believe that debian is now installable on it? What would be the pros and cons of debian linux vs SGI's IRIX?
S.t.e.v.e.
Becuase it lets me, as an admin, standardize on one version. If the "base" Debian was in a constant state of update It would be much harder to build several systems over a span of time to be exactly alike. This way when I say I have Debian 2.2r2 installed, I know what I have. Sure, I could keep track of every package and make sure all new systems have the exact same version of everything (which most people do anyway), but it makes the install much easier.
I'm sorry, someone has to say it: "frozen woody"? That's just plain wrong. I'm opposed.
--
Key to financial independence: Spend less than you earn. Save and invest the difference. Do it for a long time.
How about a couple days ago, a bug that crept in to pam-modules (or something similar) that killed all logins, or 'su' requests, that I only saw after an 'upgrade'? I was lucky I already had a root rxvt running, so I could upgrade the broken package! The screwedness rating would have been pretty high, if I didn't...
---
python -c "x='python -c %sx=%s; print x%%(chr(34),repr(x),chr(34))%s'; print x%(chr(34),repr(x),chr(34))"
So I've got a machine that I want to wipe clean and install something on, and I'm thinking Debian, Slackware, or Linux From Scratch.
Right now I'm leaning toward debian, as all examples I've seen of apt-get are extremely nice. However, I'd have no clue how to even start /using/ apt-get. I don't know what the sources file is. I don't know how to use dpkg. I have no clue.
So the question is: is there an easy way to pick up on this and other debianisms that I'm going to run into?
-Denor
He didn't just break "things," he broke toys. That's what makes it such an, er, apt name.
The only "intuitive" interface is the nipple. After that, it's all learned.
"The question of whether a computer can think is no more interesting than that of whether a submarine can swim" -EWD
Well, it would not have been that fatal, even if you hadn't had a root shell open. Just reboot and pass "init=/bin/sh" to the kernel.
:).
Half the fun of unstable is fixing it when it breaks
While it may be a bit more difficult to do on a distro like Slackware, it's certainly possible.
/most/ shared libraries in Linux use the .so.major.minor convention. If you want to upgrade a library to a new minor version, chances are it won't hurt the applications. If you're upgrading to a new major number, you can simply save the older library. I prefer keeping older libs in /usr/lib/deprecated, then symlinking them to /usr/lib. It may sound odd, but this is what I prefer. That's the beauty about these types of distributions - Without dependencies, you can do things like this (fairly) easily.
Unlike Windows,
signature smigmature
- James
A Roll of Cat5 and Terminators and Tools, $100
A Black skintight suit, $50
Getting into the university and piping your own data link for warez use? PRICELESS!
hehehe.
On the other hand, you have fingers
No, sid is *always* unstable (if you remember, in Toy Story sid was the kid who used to break things a lot, hence the name :)).
At the bottom of the announcement it does say this about the next name:
On the subject of controversial decisions, one I'm not going to make today is what to call the release after woody. That one will be made when woody is released and a new testing distribution is forked from woody. Besides which, I still haven't gotten around to rewatching Toy Story.
--
Blaming GW Bush for the Iraq war is like blaming Ronald McDonald for the poor quality of food.
I have more than "fond memories" of using Slackware, I'm using it right now. It seems to run just fine, for not being a "modern distribution". But gee, it has the latest Linux kernel 2.4.5, and X 4.1.0, and Gnome 1.4, and KDE 2.1.1, and scores of other things: I run a firewall, a CD burner, a scanner, plus I download and install updates automatically from Slackware.com. My Slackware box can run any software that your Debian box can. How is Slackware not "modern"?
People have different tastes and preferences. Most people like a certain distro because it's easier for them to use. That ease of use may not translate to increased technical merit (or performance), however. Some people like a distro because it fits the model of how they think a distro should be organized. Such models are highly subjective, however, as you can see by the dozens of distros out there to meet the needs of users clamoring for things to be done "their way".
I'm not saying that Slackware is better than Debian. I'm not saying that Debian is better than Slackware. I'm saying that they're mostly the same, but organized differently. At the core, they're both running the same kernel and set of core utilities. Many of the apps are the same, and in fact come from the same source.
When I decided to first install Linux, I had a choice of several different distros. I chose Slackware for three reasons: 1) A Linux guru whose skills I really respect was running it, 2) Ret Hat had a reputation for being easy to install and use but highly insecure by default, while Slackware had a reputation of being harder to install and use at first, but more secure by default, and 3) because Slackware wasn't as dumbed-down as Red Hat, it forced you to actually LEARN more about how Linux works. That last point is probably the most important reason to me. The knowledge that I have gained by being forced to do some things myself has helped me immensely. I'm not dependent on a developer to write a handy tool to do something for me, I just do it, because I know how.
In summary, Debian and Slackware are geared for different target audiences. To say that one is more "modern" than the other is something that I disagree with. They're just different approaches to using the same basic tools. Slackware, in my opinion, is geared more to the "do-it-yourself" total-control type of crowd, and for those people, the tools that Slackware comes with work just fine.
Even a battered old violin in the hands of a skillful player sounds much better than a Stradivarius in the hands of a tone-deaf klutz. So when it comes down to it, each distro is limited only by the skill of the user.
Heh. Speaking of "morons"- compare the organizational structure of a Slackware package (and yes, they are packages) to a Debian one. If you would rather have simplicity, that's fine- but questioning the intelligence behind one of the most organized distributions out there is a rather flawed stance.
Calling ~1000 hard working *volunteers* working on Debian "morons", and is just too ignorant to be considered insulting before any Debian user that knows more than what he's read from the back of a CD, or angsty Slashdot posts (you've get the idea).
Slackware, to me, seems more like a wanna-be FreeBSD more than anything else. And it doesn't even have ports... so what's the point? I love FBSD, but realy loathe using Slackware now, with all of the highly more organized and supported alternatives available.
Any halfwit could create his own distro (with lil shell scripts and all) in a day or two. You want to build everything from source?- Debian provides that, and in a much cleaner way than /usr/local/ or SRPM's could ever provide.
Use what you want. Say one way sucks. But trying to insult talented volunteers, just maintaining packages to make life easier for their friends, is pretty harsh. :)
Nathaniel Hewitt
Nathaniel Hewitt
"Having nothing, nothing can he lose." --Shakespeare
I'm very curious about future woody penetration. If that's the goal, I wonder if they're pushing too hard. I think freezing woody at this time might be a drastic step. While it might seem to make further penetration possible, it could cause serious damage to long term usability.
I mean market penetration. Geez, get your mind out of the gutter.
--
Frozen windows is much more common..
Sig this.
I hate it when I freeze my woody....
For a second I thought this was April 1st instead of July 1st. A slackware release and a debian freeze on the same day? ;)
Yes, Debian sucks. It is the nature of operating systems to suck. However, as someone who uses both Debian and RedHat, I have to say that Debian sucks less (in terms of broken depenancies and other weirdness) that RedHat. You mention Slackware, which has no dependancies. While you may have fond memories of using such systems, there is a reason why modern distributions have all gone to including dependancies -- they really cure more headaches than they cause. Now, the BSD source-based packaging systems might work well -- I haven't tried them, but in theory they sound good.
I can only vouch for releases since 4.0, but RedHat really does seem to have a sensible numbering system. They move to a .0 release whenever they break binary compatibility and like clockwork put out .1 and .2 releases that mainly seem to be bug fix releases as opposed to containing drastically different features. If debian went to .0 for every release that broke binary compatibility they'd probably do it every release because of the longer release cycles
I always get the giggles when debian freezes, because we all pretend that we're going to run stable, then in a week we get tired of it and switch back to unstable. "I'm going to not have debconf get raped by a missing perl module and uninstall half my software" we say, but then we end up having it happen anyway... Anyways, It'll be nice to upgrade my server to the new stable *cough* *hack* (who am I kidding... I run testing on my server).
RedHat goes to .0 when they break everything.
They go to .1 when they fix some of it, and .2 when they fix most of it, at which point they are prepared to screw everything up again for the next .0 release.
--
Win dain a lotica, en vai tu ri silota
I run testing/unstable on my workstation, but I do /only/ run stable on my servers. Testing is not good because security patches take much longer to hit it.
Since I'm runing stable on my servers, I can simply put security.debian.org in my /etc/apt/sources.list and apt-get upgrade to automagically install all new security updates, which makes keeping my box up to date /very/ easy.
Also, I've had enough problems with unstable (and they occur in testing from time to time as well) that I know better than to apt-get upgrade to anything but stable on a box serving a web site or thousands of mail messages a day.
Jordan Bettis
``Wherever you go, there's another stupid sigfile quote.''It's very simple, if you want a system like that you can start your own project, use ANY current distribution of Free Software as your base (Debian, OpenBSD, RedHat) and try to find developers to help you make it work (or else impress us all).
Debian however is about creating stable environments which can be used anywhere but because it has an open development process, people can track stable, testing/frozen, unstable. The real interest of this story and why it deserves to be discussed on /. (apart from the managments penchant for it) is that this release of Debian is being handled by a new person with new ideas. The aim (as the link reiterates) is to bring down the release cycle time for Debian (with an ambition of a roughly 6 month cycle). We have seen the arrival of the testing distribution which is basically an automanaged version of Debian containing co-dependant sections which have been through some testing and need to be broken! We are now seeing a detailed breakdown of how this will start being frozen out into a release.
I think that aj deserves all the support in the world (and he'll be getting more and more of mine) as if he suceeds Debian could become a True Power. Debian is continually praised except for package ages and user ease. We have seen a number of Debian based distributions but each of these I feel was probably let down by the need to continually update the entire system as users could not accept an 18 month release cycle. The potential for commercial investment around Debian is huge, what company would not like to be able to base their products on the stablility of a stable Debian. If we have a 6 month Debian stable release cycle, I am certain we would see new-user Debian systems for many purposes (servers, desktops) aswell as embedded Debian and we would also see many of these bodies working actively in Debian itself to improve the base even more in each of those 6 months.
Debian best embodies the ethos of Free Software and it's development model is an example of how impressive open development is. How many people on /. would not move Linux production systems to Debian if it had a 6 month release cycle (without effecting stability)? If we want Linux to take power, we need to support Linux, but that is a hard task at present. When you are asked "which Linux should I try" you make one of the biggest impacts to Linux development you can (unless you actively participate in a project), the answer at present is far from easy. We should be able to say Debian and then you can decide if you need something else simply because Debian is openly developed and stable. Can anyone propose some alternative Linux distro we should support? If the philosophy of Free Software is held widely by it's knowledgable users then we should all be choosing our OS as a sign of support. aj is trying to help the world. How about we help aswell? I know I will!
Never underestimate the dark side of the Source