Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Anthony Towns Elected New Debian Leader

ScuttleMonkey posted more than 8 years ago | from the there's-a-new-sheriff-in-town dept.

69

daria42 writes "Australian developer Anthony Towns has just been elected Debian Project Leader starting 17 April. In his platform for election, Towns said the most important issue for Debian was 'increasing its tempo'. 'We've been slow in a lot of things, from releasing, to getting updates in, to processing applications from prospective developers, to fixing bugs, to making decisions on policy questions, and all sorts of other things,' he said."

cancel ×

69 comments

what rush? (-1, Offtopic)

Anonymous Coward | more than 8 years ago | (#15098202)

don't see no rush...

Slowness (4, Funny)

CRCulver (715279) | more than 8 years ago | (#15098205)

As the old saying goes, "Hell freezes faster than Debian Stable". Good to see that Towns intends to take action.

Re:Slowness (1)

MichaelSmith (789609) | more than 8 years ago | (#15098269)

As the old saying goes, "Hell freezes faster than Debian Stable". Good to see that Towns intends to take action.

The three main BSD projects are comparable to Debian, yet they manage to get their releases out on a (fairly) regular basis.

Re:Slowness (1, Insightful)

Anonymous Coward | more than 8 years ago | (#15098389)

The three main BSD projects are comparable to Debian, yet they manage to get their releases out on a (fairly) regular basis.

The only one I have any experience with is FreeBSD, and I can say for a fact that I would never dream of using an X.0 release of FreeBSD. Since I've started following their progress, it's always taken till at least X.4 before a major version was stable enough to consider for serious use.

This is in no way comparable to Debian, which prefers to wait six months longer and then get things right the first time.

Maybe the other BSDs are better.

Re:Slowness (2, Informative)

Homology (639438) | more than 8 years ago | (#15099022)

The only one I have any experience with is FreeBSD, and I can say for a fact that I would never dream of using an X.0 release of FreeBSD. Since I've started following their progress, it's always taken till at least X.4 before a major version was stable enough to consider for serious use.

OpenBSD has a different release policy (i.e. a release every six months) that works very well. The 3.9 release is coming 1th of May, but the release in November will have version 4.0. Of course, someone had to ask if 4.0 will be stable. Theo de Raadt answered thus:

>Yep, the developers magically do more in the 6 months preceding 4.0
>than the 6 months preceding any other release. That's definately how
>it works.

We've been holding back about 50% of our work for each of the previous
4 releases, and now we are going to throw all those very large things
into what will become 4.0. It is going to be a fantastic catastrophy,
exactly like what all of you ".0 release" people expect.

Right... Get a grip.

Re:Slowness (1)

MacJedi (173) | more than 8 years ago | (#15099339)

OpenBSD supports an impressive list of 16 arches. Debian supports 11 arches. However, Debian and OpenBSD use different definitions of "support."

OpenBSD is officially supported on the following [16] platforms. Official support means that the release install media is known to work, that the architecture can self-compile itself, and that most of the basic tools exist on the architecture.

So for OpenBSD this means that they have working installer, you can compile your own kernel on your own box and most of the basic tools exist (emphasis mine.) All the ports are there in source, and they may work for you, but really, who knows? A supported arch in Debian parlance, on the other hand, means that there is a working installer, you can coompile your own kernel on your own box, and virtually every debian package can be auto-built and available in binary form.

Big difference, IMHO.

Re:Slowness (2, Informative)

Homology (639438) | more than 8 years ago | (#15099881)

So for OpenBSD this means that they have working installer, you can compile your own kernel on your own box and most of the basic tools exist (emphasis mine.)

It's requirement for a supported arch that not only the kernel, but userland (including thirdparty applications like perl, Apache httpd, BIND, Sendmail, gcc toolchain and more) must also be built natively: cross-compiling is not sufficient to claim support, unlike some other OS that shall be unnamed. Some archs, like vax, is limited by hardware, while others are not fully supported due to lack of documentation/hardware/resources.

In general, if an arch is supported, it is supported well.

All the ports are there in source, and they may work for you, but really, who knows?

Ports are tested on all platforms, but some ports are not supported on some platforms either due to hardware limitations or bugs in the application.

A supported arch in Debian parlance, on the other hand, means that there is a working installer, you can coompile your own kernel on your own box..

OpenBSD has higher standards than just to be able to compile a kernel natively: Userland must also be built natively and it must be a useable OS.

... and virtually every debian package can be auto-built and available in binary form.

Now, this is silly. Of course OpenBSD offers pre-compiled ports (ie packages) for every arch where it makes sense. Obviously, on vax, for instance, there will be a limited supply of applications that may run on such a platform. However, there are quite a few packages available (not cross-compiled): ftp://ftp.openbsd.org/pub/OpenBSD/3.8/packages/vax [openbsd.org]

Good Move (1)

majjj (644070) | more than 8 years ago | (#15098215)

I guess things will heat up for debian now....

Re:Good Move (3, Insightful)

babbling (952366) | more than 8 years ago | (#15098228)

What makes you think that? I mean, sure, he stated that he wants to get releases out quicker, but that doesn't necessarily mean he will be able to. I imagine that has more to do with the independent, unpaid Debian developers rather than the project leader. It's rather likely that the previous Debian project leader also wanted a shorter release cycle.

This is one of the problems with free software. If developers are less accountable, fixed release dates are more difficult to achieve. On the other hand, almost all proprietary software seems to be facing the same problem, and sometimes to a greater degree...

Re:Good Move (0)

Anonymous Coward | more than 8 years ago | (#15098245)

Meanwhile, Fedora manages to get releases out every 6 to 9 months just fine.

Re:Good Move (0)

Anonymous Coward | more than 8 years ago | (#15100635)

"Meanwhile, Fedora manages to get releases out every 6 to 9 months just fine."

Meanwhile, Fedora manages to get releases out every 6 to 9 months.

That they are "just fine" is much more an idiom than a reality, I'm afraid.

Re:Good Move (1)

DrMorris (156226) | more than 8 years ago | (#15098251)

I think the slowness of Debian has a lot to do with the endless discussions, too. I don't say they're irrelevant or obsolete but they can get very lengthy (and sometimes repetitive) on some topics. In effect some decicions take longer than expected and schedule's getting out of control. Nevertheless, I'm a happy Debian user.

Re:Good Move (1)

babbling (952366) | more than 8 years ago | (#15098259)

I'm a happy Debian user, too. I just thought I should point out that a leader who wants quicker release cycles doesn't necessarily imply quicker release cycles.

Re:Good Move (1)

pintpusher (854001) | more than 8 years ago | (#15103088)

sometimes you have to flog the mules just to maintain the current pace...

and yes, I love deb too. Go Debian Go!

Re:Good Move (1)

Tester (591) | more than 8 years ago | (#15098405)

What makes you think that? I mean, sure, he stated that he wants to get releases out quicker, but that doesn't necessarily mean he will be able to. I imagine that has more to do with the independent, unpaid Debian developers rather than the project leader.

Unlike the equally unpaid Gentoo Developers who manage to make 2 releases every year, and at point even did 4 (but that was, i admit, too much work).

Re:Good Move (TT) (1)

WilliamSChips (793741) | more than 8 years ago | (#15104561)

It's because the binary packages of Debian require you to install 500 packages just to get a window manager, and 150 more for the development packages if you want to *do* anything with them. They also have neutered support for things that less people use, so if you use something rare, like Kerberos with SSH, you're screwed.

Best intentions... (3, Insightful)

QuaintRealist (905302) | more than 8 years ago | (#15098458)

I'd have to agree with you. One of the main reasons Debian has been slow to update has been the range of architectures and applications they attempt to simultaneously support. Other distros update faster, but most of them take one of two paths: a) limit supported architecture (usually to the x86 and x86 64) or b) support only a small subset of applications.

Really, as much as I'd love to see Debian update faster, I'd hate to see them take one of those expediencies to get the job done.

Re:Best intentions... (2, Insightful)

Dan Ost (415913) | more than 8 years ago | (#15098861)

The reason why Gentoo can release predictably and why Debian can't is that Gentoo allows
different profiles for different architectures (Gentoo 2006.0 may have different stable versions for an app for different architectures, assuming the app is available for both
arches in the first place) while Debian requires that the stable profile for each arch is
synchronized.

Re:Best intentions... (1)

Tigen (231147) | more than 8 years ago | (#15102271)

I'd hate to see them take one of those expediencies to get the job done

I wouldn't. Who cares if new releases still work on Alpha? If that slows down the other 99% of the world then drop it, and leave it to a specialized subproject to deal with. The three people who care can work on it.

Joke (5, Funny)

zaguar (881743) | more than 8 years ago | (#15098220)

For those who were wondering, voting started in 2001. He was elected today because the commitee wanted to make sure the candidates were 'stable'.

Re:Joke (5, Funny)

wild_berry (448019) | more than 8 years ago | (#15098255)

You forgot to mention that the candidates were also frozen for bugfixing. Towns has only lost two fingers to frostbite; the debian-privates e-mail list suggests that another candidate lost something more personal and delicate.

Re:Joke (0)

Anonymous Coward | more than 8 years ago | (#15098287)

I suppose that they also wanted a "stable and proven" version...
 
...so they went with Homo Erectus.

Re:Joke (1)

hotspotbloc (767418) | more than 8 years ago | (#15098407)

For those who were wondering, voting started in 2001. He was elected today because the commitee wanted to make sure the candidates were 'stable'.

If we had only used that method in choose the current US President ...

Re:Joke (0, Offtopic)

Bob Uhl (30977) | more than 8 years ago | (#15099628)

Bush unstable?!? Have you seen Gore lately? The man's gone off the deep end.

And as for Bush, he appears to be a level-headed fellow.

Re:Joke (0, Offtopic)

hotspotbloc (767418) | more than 8 years ago | (#15100724)

IMO Gore sucks too. While I think the GOP has a lock on "most evil" the Democrats aren't far behind.

Debian (1)

repruhsent (672799) | more than 8 years ago | (#15098317)

As a project, Debian is about the best example of bureaucracy going wrong that one can think of. Just go check out any of their mailing lists - they spend more time arguing about politics and philosophy than they do writing code. I thought this was a software project - shouldn't they be spending time, oh, I don't know... writing code? When you combine this with the fact that all of their programmers are volunteers and thus don't have tons of time to spend on the project, no wonder they never release.

Everyone here will agree, though, on one fact: there is nothing that Debian can do that Ubuntu can't do better.

Re:Debian (5, Insightful)

lpcustom (579886) | more than 8 years ago | (#15098383)

I have to disagree totally. Ubuntu does have newer software for it's main distro. Debian Testing has just as new software cept it works better. For example, Ubuntu is still using firefox 1.0.7. Debian testing is at 1.5. Ubuntu's latest dapper flights are basically Debian Testing with new artwork that says Ubuntu.
I like a ton of distros but I seem to always come back to Debian. For a bunch of guys that can't get their act together, they still make the others looks bad.

Re:Debian (2, Interesting)

Arkaein (264614) | more than 8 years ago | (#15099525)

I disagree that Debian Testing's packages work better than Ubuntu (or at least Kubuntu, in my case). I used Debian Testing for nearly two years, but late last year I decided to give Kubuntu a shot and haven't looked back. The final straw was a large set of KDE updates. I had a version of Amarok that I believe was either broken or had some key bug that was fixed in more current versions, but due to some kind of broken dependency chain in Debian Testing there was no way to upgrade anything KDE related. It was like this for a couple of months when I finally left.

There's also the issue that once Debian Testing updates a core package, updating dependencies of that package all require the new core package. Again, this was an issue with many KDE apps. I might want to update Kate, but if the KDE core went under some minor bug fix version change then I have to upgrade EVERYTHING in KDE just to upgrade or install one app. Even the small chance of serious breakage made this a serious risk.

With Kubuntu I know that my software might be as much as 6 months out of date, but I've never had a problem installing or upgrading software, including from the Universe and Multiverse repositories. I can wait 6 months for most things.

It's all about tradeoffs. For me K/Ubuntu strikes the right balance between freshness and stability. Neither Debian Stable nor Testing are as good a fit. YMMV.

Re:Debian (1)

Respect_my_Authority (967217) | more than 8 years ago | (#15102319)

Upgrading many packages at once can only become a problem in Debian if you have a very slow network connection (or if you mix branches without understanding how apt-pinning works). Also, I don't believe that Debian packages have different dependencies than in other distros -- you need to have specific version of other (dependent) packages for certain packages to work at all. After the Sarge release there was a lot of confusion with the KDE packages in Unstable and Testing but this was because of some major upgrades in the base system (gcc and other stuff that K/Ubuntu managed to upgrade before Debian). And KDE hasn't always been in good shape in Debian but now it seems to be in great shape. Apparently you've been lucky with Kubuntu -- or maybe you just don't use many packages from Universe. Only the packages in Main are officially supported by the paid K/Ubuntu developers, Universe packages are community supported and Multiverse packages don't get any support at all. This means that QA varies a lot in K/Ubuntu while in Debian (even in Testing & Unstable) all packages are maintained by official developers who have personal responsibility to fix any problems found in their packages. I'm glad to hear that you've found Kubuntu meeting your requirements but I have no doubt that in general Debian packages work better than K/Ubuntu packages.

Re:Debian (1)

pintpusher (854001) | more than 8 years ago | (#15103238)

I've seen a lot of mentions of testing being compared to *buntu and I find it interesting. Prevailing wisdom on debian-user list is that testing should be avoided if at all possible, unless you actually want to do some "testing". Due to policy issues when testing breaks, it tends to stay broken for a while. Unstable (4ever sid) being much more fluid can definitely break, but also tends to fix itself up again in short order. For everyday use the suggestion is to either track stable (for servers and mission critical stuff) or track unstable (desktop/workstation) and avoid testing.

Comparing testing to any other "regular" release by another distro is really unfair as thats not its purpose. It's really in sort of a semi-frozen state by virtue of being in testing.

Personally, I've been tracking sid closely for over a year with no issues to speak of. Well, there was one yaird issue that b0rked a kernel, but I know none of you run with less than 2 or 3 backup kernels, right? And yes, it's desktop ready, and yes I use it everyday, and no I don't boot into windows to do anything, and yes, it's totally comparable to *buntu EXCEPT that *buntu works better right out of the box and has some nice gui front ends on config stuff. not my cup of tea but works great for my mom. (and no, I'm not her resident tech support in the basement :-P)

Re:Debian (1)

Arkaein (264614) | more than 8 years ago | (#15103527)

I agree that it's a bit unfair to directly compare Testing to other distros, but the fact is that for desktop users Testing is probably the most widely used Debian distro. That may be contrary to the intentions of the Debian developers, but it is the reality of the situation. Breakage isn't really even the biggest issue, for me the requirement to upgrade dependencies of newly installed packages was the biggest kicker (e.g. I installed foo-1.0 at one point, later I want to install bar-1.1 which depends on foo-1.1 which is the current version, so installing bar-1.1 requires upgrading foo-1.0 and most likely several packages which depend on foo-*).

In any case, if I could only choose a Debian distro it would probably be Testing because as a desktop user I'd have greater misgivings with the old packages in Stable.

Re:Debian (0)

Anonymous Coward | more than 8 years ago | (#15103987)

Prevailing wisdom on debian-user list is that testing should be avoided if at all possible, unless you actually want to do some "testing". Due to policy issues when testing breaks, it tends to stay broken for a while.

Yep, this is why I switched from Debian testing to Kubuntu. It used to be that testing was a great 'middle of the road' choice - reasonably up to date and reasonably solid. But once they changed the policy and packages started disappearing altogther for extended periods, it became too difficult to manage. Easier to run sid. That was too variable though, so I moved to Kubuntu and have been happy ever since.

Sad really. Whatever those policy changes were, they made Debian testing a much less useful distro.

Re:Debian (1)

Respect_my_Authority (967217) | more than 8 years ago | (#15104576)

From your post it's not obvious what the purpose of Debian Testing is in your opinion, you only seem to suggest that "testing should be avoided." Let me clarify how I see the purpose of both Testing and Unstable.

Unstable is Debian's main development branch and it's INTENDED to break every now and then because it's the branch where most of the development takes place, it's "Still In Development." If Debian Unstable doesn't break often enough, then this can only mean that Debian doesn't develop as fast as it should. Regardless of what the "prevailing wisdom on debian-user list" says, Unstable should be, IMHO, avoided by anyone who isn't a Debian developer.

Debian Testing is also a development branch but packages with known release critical bugs are not accepted to Testing. There's a mandatory quarantine time of ten days before packages can be elevated from Unstable to Testing. This should be enough time that most release critical bugs are discovered and reported by users to package maintainers. For this reason, I think that desktop users should be recommended to use Testing instead of Unstable. (And, for obvious reasons, server users should be recommended to use Debian Stable instead of Testing.)

Debian Testing is the branch from where the next Stable Debian release is made and, ideally, Testing should be always kept close to the "ready for release" quality. So comparing Debian Testing to some other distro's official release is not really that farfetched, after all. But, unfortunately, this ideal of "ready for release" hasn't always been met. Troubles with the Sarge release indicate that Debian testing was at that time a long way from the "ready for release" ideal.

However, things seem to be in a much better shape in the Debian-land nowadays. Now there's a special Testing-security team and release critical bugs are also getting fixed faster, which allows even complex packages like the big desktop environments to migrate from Unstable to Testing without long delays.

In conclusion, using Debian Testing can be painful if the development has stagnated but, on the other hand, it can be joyful when all the little cogwheels of the big Debian development machinery are well-greased and run smoothly.

Re:Debian (1)

pintpusher (854001) | more than 8 years ago | (#15105849)

From your post it's not obvious what the purpose of Debian Testing is in your opinion, you only seem to suggest that "testing should be avoided." Let me clarify how I see the purpose of both Testing and Unstable.

Let me clarify as well, I did mean not that people should avoid testing, but that testing is its own special thing, (as is sid) with its own special requirements to manage properly. And that it can be difficult to maintain a system in good working order over time if you are tracking testing. It lacks both the stability of stable (pun) and the fluidity of sid and by being in the middle, it doesn't quite have the benefits of either. This is tricky to maintain and, IMHO, even more difficult to run than Sid. Why? because you can get stuck while waiting for the slower process to rectify the problem.

And I disagree about sid being intended to break. I don't think that's really right. More that sid is ALLOWED to break. And the reality is that sid has been really easy to use over the last year. Not from a lack of developement either. I typically upgrade over 100 packages a week, sometime many more. True there has been some breakage, but nothing that hasn't been fixed or worked around in short order. I haven't been down at all (thanks to that extra kernel :) and even that kernel problem was worked around and then resolved in just a day or two. And I truly am not a developer.

I agree though that sid is a little scary to run. From a usability standpoint, its great -- packages are pretty up to date and theres really nothing missing. Its the upgrades that are scary. In fact, I run one of my machines with an un-updated sid simply because its working well, is behind a good firewall, and it already does everything it supposed to. Eventually, I'll have to move it, but for now... Well, now I'm just a rambling deb-fanboi so I'll stop. cheers.

Debian? (0)

ultrabot (200914) | more than 8 years ago | (#15098335)

What is this "Debian" you speak of? Is it more like Ubuntu, or Fedora?

(yes, it was a joke)

Re:Debian? (1)

homerules (688184) | more than 8 years ago | (#15098551)

and it was not funny.

Re:Debian? (0)

Anonymous Coward | more than 8 years ago | (#15102218)

I think what you mean is

Ubuntu? I can't believe it's not Debian!

Re:Debian? (1)

WilliamSChips (793741) | more than 8 years ago | (#15104546)

It's like a cross between Ubuntu and Gentoo, minus the benefits.

Debian bites off too much (1, Interesting)

Cthefuture (665326) | more than 8 years ago | (#15098401)

They should remove 99% of the packages from the core distribution and go with a simple small set of base packages for each release. Then switch to a 6 month release schedule like many other projects are using. All those other packages can go into an "extra" repository or something.

I think even Ubuntu tries to put too many packages in the base release. They should take a hint from the BSD distros which use this method with the base install and ports. Hell, Windows uses the same method. After installing Windows there isn't much functionality other than the OS, you can then install whatever applications you want. Note I'm not advocating a ports-like source "build it yourself" thing, I'm just saying that 99% of the packages that are currently in a Debian release don't need to be part of the core.

Worst idea ever? (4, Insightful)

babbling (952366) | more than 8 years ago | (#15098516)

Why? I'm a Debian user, and I appreciate how well EVERYTHING works. I'd hate for them to sacrifice the quality of most of the software I use just so they can release twice as often.

I don't really trust distributions that guarantee a release every 6 months, because I get the impression they must be rushing things. I'd prefer something quality, even if it's usually "behind the pack".

Re:Worst idea ever? (1)

Cthefuture (665326) | more than 8 years ago | (#15098603)

It's not rushing if you work off a small core (see OpenBSD). I would rather have a really stable up-to-date system than 1000's of packages I don't use.

They just can't make everything work stable when there are thousands upon thousands of packages, that's why it takes so long to release anything. In the meantime we're stuck with either an incredibly outdated system or running the unstable branch that changes way too often and sometimes breaks (not good for servers or media boxes and similar).

Re:Worst idea ever? (2, Informative)

Bogtha (906264) | more than 8 years ago | (#15098669)

Why? I'm a Debian user, and I appreciate how well EVERYTHING works. I'd hate for them to sacrifice the quality of most of the software I use just so they can release twice as often.

The idea isn't to skip testing, the idea is to decouple the release schedule of the OS from the release schedule of the applications. So long as the base Debian system maintains compatibility between releases (and I was under the impression it did), it shouldn't matter to the applications when new versions of the OS is released, and it shouldn't matter to the OS when new versions of the applications are released.

By tying the two release schedules together, you essentially make the OS wait for the applications to catch up in stability and make the applications wait for the OS to catch up in stability. If one or other can be made stable independently, there's no need to slow things down by synchronising their schedules.

Re:Worst idea ever? (1)

Homology (639438) | more than 8 years ago | (#15099174)

The idea isn't to skip testing, the idea is to decouple the release schedule of the OS from the release schedule of the applications.

So not only should the package maintainers test for OS release X, but also for several other releases as well. In addition there will be updated packages that needs testing. Nice idea, if you are willing to pay the (mostly) unpaid package maintainers to do this. Do you?

Re:Worst idea ever? (1)

Bogtha (906264) | more than 8 years ago | (#15099375)

Package maintainers don't do the majority of the testing as it is, that's what the 'unstable' and 'testing' distributions are for. Or are you under the impression that each and every package maintainer has a computer of each architecture supported by Debian dedicated to testing? Testing has always been a distributed task.

Did you miss the part of my comment about Debian remaining compatible from release to release? Are you claiming Debian don't already do that? Do you understand the implications that has on the necessity of testing applications against each Debian system release?

Re:Worst idea ever? (1)

Homology (639438) | more than 8 years ago | (#15099999)

Did you miss the part of my comment about Debian remaining compatible from release to release? Are you claiming Debian don't already do that? Do you understand the implications that has on the necessity of testing applications against each Debian system release?

I'm astonished that Debian does this, since it clearly implies much extra work in testing an updated package (No wonder that Debian releases so seldom) That is why I misread your comment concerning compatability from release to release. On OpenBSD you may keep your already installed packages when upgrading, but no port is backported to an older release (unless it's critical for some reason).

Re:Worst idea ever? (1)

turbidostato (878842) | more than 8 years ago | (#15100804)

"id you miss the part of my comment about Debian remaining compatible from release to release? Are you claiming Debian don't already do that?"

I do (in an aspect). While it is true that Debian tries hard to be compatible from release to release, compatible doesn't mean you can just take, let's say, Postfix from Potato and through it into Sarge (that's obviously true if we consider only the binary packages and their DLL dependencies, but it is equally true regarding package configuration tools, integration with other packages, etc.). What Debian means by "compatible from release to release" is that there will be a "soft" upgrade path from one Stable to the next.

But this comes at a prize. It is hard (and, sometimes, *real* hard) to find a proper upgrade path between versions (currently, for instance, Etch is going through one of these passages because they abandoned the hotplug/coldplug structure in favor of an all-udev one. XFree to XOrg won't be just overwritting one onto the other...). For some of those big changes it literally takes more than six months to find the *proper* upgrade path (it's good enough for other distributions just putting together some release notes saying you must manually uninstall some package and install and configure some other; not for Debian).

While it is true that there is quite a lothat can be done regarding the upgrading management systems from Debian (it uses the very logical "all frozen at a time" that made so good outputs in the past, but it shows now it can't properly scale to the behemoth Debian currently is), like defining "dependency rings", make heavy usage of "upgrade branches" and quite a lot of "dirty tricks" from configuration managers, I, like most Debian users, will prefer the old fashioned "all frozen at a time" to what most other distributions claim to be "stable" if there's no other path. But, of course I'd prefer even more a better paradigm that would insure faster upgrades (but probably no more than once a year), while only if that doesn't endangers current stability and multi-platform disponibility (seriously: it wouldn't be a charm finding that Etch on x86_64 doesn't work, sysadmin-wise, exactly the same than on a SPARC or an PA-RISC).

Re:Worst idea ever? (1)

pintpusher (854001) | more than 8 years ago | (#15103177)

So where do you draw the line between the OS and the apps? Some things are obvious: the kernel goes in the OS. and ok, everything that you need to build the kernel, which is really a lot of stuff. And I guess that means you need libc et al. hmmm, but do you need an editor bundled with the OS so you can configure stuff? well you can't pick just one or you lose your [EMACS|ViM] fans. And then what about something like hotplug/udev? You don't really need them, but they are central to the operation of the OS in any kind of real way, so better throw that and all its dependencies in. Before long you've got so much you might as well do it all.

my point is that it's really hard to draw that line, and while I agree that line is out there somewhere, I sure as hell don't want to tell someone that their baby is on the wrong side of that line. Of course, I'm a happy deb user and am biased.

Re:Worst idea ever? (2, Insightful)

Spazmania (174582) | more than 8 years ago | (#15098704)

More to the point, I'd hate for them to release twice as often period. I maintain more than 60 machines; frequent release upgrades would be a serious drain on my time.

If you want a distro that does significant upgrades to core packages every few weeks, get Fedora. Its great for that. Sucks for stability, but it has a really fast upgrade cycle.

Re:Worst idea ever? (3, Informative)

croddy (659025) | more than 8 years ago | (#15098747)

I would definitely agree. It is unusual (in the Linux world) that Sarge took two and a half years to release, but I think that the benefits of the Debian QA process are very apparent. Taking the time to sort out bugs as well as they do -- on a very large number of packages -- makes a Debian release worth waiting for.

The slower release cycle is offset by two things. If you know you need a fresher system, and are willing to sacrifice some stability for updated packages, you have as many choices as you can handle: adding a few packages from testing to your stable system, directly tracking testing or unstable, some mix of any of the three, or even adding packages from experimental if you really want to go out on a limb.

The power of Debian is not only in APT, but in Debconf, the configuration system. Configuration changes are pretty much a given on a system that's directly tracking sid, but are unheard-of (and perhaps even forbidden?) in the stable release. The ease of administration that comes with knowing that changes Debian stable will consist only of backported security patches makes it worth the wait.

Lastly, a system administrator does not want to have to go through a major operating system upgrade on numerous heterogenous servers every 9 months. Knowing that it will be somewhere around 18-36 months between Debian releases means spending a lot less time migrating and fiddling with systems just to keep up with supported releases.

Other distributions do release every 6-9 months. It's not for me... except when it is, and I use testing/unstable in those cases :-)

Not quite true about the config changes (0)

Anonymous Coward | more than 8 years ago | (#15099091)

Configuration changes are pretty much a given on a system that's directly tracking sid, but are unheard-of (and perhaps even forbidden?) in the stable release.

I run Debian stable on about four dozen servers and have for almost six years, and I can tell you that you're dead wrong on the config file changes. Debian stable does change config files. The best example I can think of is /etc/mail/sendmail.cf. Like most admins I use a custom version of sendmail.cf. When Debian stable upgrades sendmail, it overwrites your sendmail.cf without asking! I only have about 250 lines or so that I've changed or added to sendmail.cf, unlike many people that have customized sendmail much more than me, but it's still annoying to have to restore the file from a backup. Diffs are hard to use with sendmail.cf since most of the lines look like line noise:

R$* < @ > $* $@ $>Parse0 $>canonify $1 user@ => user
so it's just extra annoying.

I really wish Debian Stable wouldn't erase important config files like you said it doesn't!

Re:Not quite true about the config changes (0)

Anonymous Coward | more than 8 years ago | (#15100828)

Interesting. So did you not see the gigantic, all-caps message in sendmail.cf that says, "DO NOT EDIT THIS FILE! Only edit the source .mc file."?

You can hardly complain that your changes to this file aren't preserved when it has such a loud warning not to edit it directly!

There is more information in /usr/share/doc/sendmail and in /usr/share/doc/sendmail-cf.

Have a nice day! :)

Re:Worst idea ever? (1)

marcello_dl (667940) | more than 8 years ago | (#15102414)

In fact wanting Debian to follow Ubuntu path makes little sense. It will end up suffering from the same problems and having the same bonuses (I admit the problems i have experienced are minor, the perceived superior quality of Debian may be just subjective, Ubuntu is impressive). I suggest closer interaction between debian ubuntu and other apt based distros and letting the user choose. As long as it's Free software, I see no problem. Of course it makes sense for the leader of Debian project to streamline and speed up the process of releasing the next version without impacting the distro's identity.

Re:Worst idea ever? (1)

pintpusher (854001) | more than 8 years ago | (#15103124)

I totally agree.

I hang out on debian-user a lot and I can say, that having everyone on the same page helps a LOT. In fact, you can count on one hand the number of recurring problems and they usually only involve a couple packages.

What does this mean? That out of something like 16,000 packages, spanning 3+ releases (still some Woodies out there), only a handful are problematic. True, a lot of those packages are not used by many, but still, it is telling. Debian Just Works, by and large.

Re:Debian bites off too much (1)

Julian Morrison (5575) | more than 8 years ago | (#15098611)

I value their large repository for its well-organized dependency tracking and the fact that packages have all been tested for mutual compatibility.

I don't care how often "stable" releases. I track "testing" with frequent dist-upgrades on my desktop machines, and on servers I'd not worry if "stable" was a bit long in the tooth.

Throwing away the packages to get a rapid release cycle would be a bad bargain for me.

Re:Debian bites off too much (1)

Cthefuture (665326) | more than 8 years ago | (#15098722)

I never said to throw away the other packages. They would still be available.

Re:Debian bites off too much (1)

Julian Morrison (5575) | more than 8 years ago | (#15111172)

Taking them out of the core - or in any other way causing them to languish - is as bad as deleting them. They're useful because they're kept current, and kept in sync with each other and with the core.

Re:Debian bites off too much (0)

Anonymous Coward | more than 7 years ago | (#15115403)

That doesn't make any sense. If you have Firefox installed on Windows does it need to be kept in sync with every Windows update? In case you're wondering, the answer is "hell no". You can even run it on different versions of Windows like XP or 2000.

Re:Debian bites off too much (1)

Rekolitus (899752) | more than 8 years ago | (#15098636)

Try the Debian netinst images (~180mb) and don't select any additional packages. Makes a great minimal installation. Very neat.

Re:Debian bites off too much (0)

Anonymous Coward | more than 8 years ago | (#15098986)

That has nothing to do with the release versioning.

Re:Debian bites off too much (0)

Anonymous Coward | more than 8 years ago | (#15098865)

They should remove 99% of the packages from the core distribution and go with a simple small set of base packages for each release. Then switch to a 6 month release schedule like many other projects are using. All those other packages can go into an "extra" repository or something.
I think that's called "Ubuntu".

Deslyxia. (2)

LoyalOpposition (168041) | more than 8 years ago | (#15098483)

there's-a-new-sheriff-in-town dept.

I can see I'm not the only one who read that as, "Anthony Debian Elected New Town Leader."

-Loyal

Re:Deslyxia. (0)

Anonymous Coward | more than 8 years ago | (#15098930)

Yes. Also, it's "Dyslexia", and doesn't absolve you of the responsibility to properly read or write things.

Brandon replaced after only 1 year? (3, Interesting)

JSBiff (87824) | more than 8 years ago | (#15098612)

I don't really follow Debian politics much. But, I remember seeing just last year that Brandon Robinson had been elected project lead (he too was planning to put Debian on a faster release cycle last year as I recall).

So, did Brandon resign the post, or did the Debian voters just decide that 1 year of Brandon was enough? I presume that Debian must elect a new leader annually? Are incumbents allowed to run for a second term? Did Brandon run again? Can anyone provide a post-mortem of Brandon's year - was it generally considered that he did a good job in the post?

Re:Brandon replaced after only 1 year? (4, Informative)

laptop006 (37721) | more than 8 years ago | (#15098679)

Annual term as DPL, Branden decided not to stand for a second term.

Re:Brandon replaced after only 1 year? (1, Informative)

Anonymous Coward | more than 8 years ago | (#15098682)

Brandon did not run again this year - he did not resign, he choose not to run for re-election (Debian DPL elections are indeed held annually).

Re:Brandon replaced after only 1 year? (4, Informative)

joeytsai (49613) | more than 8 years ago | (#15098947)

LWN has a pretty decent interview of Branden, but he's kinda vague about interesting details. Link here [lwn.net] .

I for one.... (0)

Anonymous Coward | more than 8 years ago | (#15098703)

...welcome but question the new Debian emperor.

Changes (2, Interesting)

Hellboy0101 (680494) | more than 8 years ago | (#15098845)

There used to be a time when a new Debian leader election would not have been relegated to a sub headline on Slashdot. I agree with others on this thread that excess architectures need to be dumped, and a firm timeline needs to be put in place. I say putting out a new Stable release every 12 months is the way to go. Debian has an excellent reputation for it's performance and stability. Six months is too soon to keep up that reputation. A new Testing release would be available every six months. With security updates on Stable being current version minus one (i.e. Debian 3.2 comes out, Debian 3.1 will still be supported, but 3.0 no longer will be).

upgrades and release cycles are ridiculous (0)

Anonymous Coward | more than 8 years ago | (#15098868)

They really are. I notice that is a major subdiscussion here, release "cycles" and whatnot. How about just eliminating that whole notion?? Why is this still happening? You should only have to install once, then upgrade the diffs as they happen, unless the entire application has been rewritten from scratch. If this "linux" thing adopted that, it would go a long ways to make universal acceptance and adoption happen and it would help to differentiate linux from the other mainstream OSes.
Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...