Slashdot Mirror
Anthony Towns Elected New Debian Leader
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."
As the old saying goes, "Hell freezes faster than Debian Stable". Good to see that Towns intends to take action.
I guess things will heat up for debian now....
"Sure there's porn and piracy on the Web but there's probably a downside too."
What is this "Debian" you speak of? Is it more like Ubuntu, or Fedora?
(yes, it was a joke)
Save your wrists today - switch to Dvorak
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.
Beer! It's what's for breakfast!
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.
The ratio of people to cake is too big
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.
Using plain ol' text since 1968
I can see I'm not the only one who read that as, "Anthony Debian Elected New Town Leader."
-Loyal
I aim to misbehave.
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".
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?
...welcome but question the new Debian emperor.
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).
Because teenage pranks are fun when you're about to die!
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.
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:
so it's just extra annoying.I really wish Debian Stable wouldn't erase important config files like you said it doesn't!
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.
The ultimate plays for Madden 2006
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.
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.
:-P)
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
man, I feel like mold.
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.
The ultimate plays for Madden 2006
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.
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.
Please, for the good of Humanity, vote Obama.
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.
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.
:) and even that kernel problem was worked around and then resolved in just a day or two. And I truly am not a developer.
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
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.
man, I feel like mold.