Slashdot Log In
Debian Release Mgr. Proposes Dropping Some Archs
Posted by
timothy
on Mon Mar 14, 2005 05:08 PM
from the notion-that-could-become-an-idea-and-maybe-a-concept dept.
from the notion-that-could-become-an-idea-and-maybe-a-concept dept.
smerdyakov writes "In this story posted by Andrew Orlowski of the Register Debian Release manager Steve Langasek has announced that support will be dropped for all but four computer architectures. Among the reasons cited for doing this are improving testing coordination, 'a more limber release process' and ultimately a ('hopefully') shorter release cyle. The main architectures to survive will be Intel x86, AMD64, PowerPC and IA-64." Actually, the story says clearly that this is only a proposal at this point, but it's definitely something to watch.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
The hell? (Score:5, Funny)
Re:The hell? (Score:5, Funny)
Parent
Re:The hell? (Score:5, Insightful)
THANK THE LORD!
Someone at Debian is finally getting a fucking clue. I've been telling stupid Debian zealots this for years... your distro is dying because everything has to move in lockstep. Take a look at the Linux kernel -- it's x86, and yet there are loads of ports which move at their own speed. Debian is a slug of a distro because it moves at the speed of the absolutely *LEAST* developed port. Split them off focus on the x86 distro... and let the other catch up or die off. Debian is smothering... and all the puffed up insane zealotry about how other platforms are supported just as well as x86 is worthless if your distro is 5 years out of date.
Parent
I disagree wholeheartedly. (Score:5, Insightful)
Interesting, from where I am it seems to be pretty much alive, thank you.
Take a look at the Linux kernel -- it's x86, and yet there are loads of ports which move at their own speed. Debian is a slug of a distro because it moves at the speed of the absolutely *LEAST* developed port.
There is always sid.
Split them off focus on the x86 distro... and let the other catch up or die off.
And then the only thing that sets Debian apart from the other distros (quality, determined by lots of portability issues spotted, bad code spotted this way, lots of different archs using the same distro, etc. will be dead. People will just use Ubuntu, if they want to use something x86-ppc only.
Debian is smothering... and all the puffed up insane zealotry about how other platforms are supported just as well as x86 is worthless if your distro is 5 years out of date.
Interesting, I run Debian, with kde 3.4 over kernel 2.6.10 and my distro does not feel 5 years out of date.
Parent
Re:I disagree wholeheartedly. (Score:4, Insightful)
>> kernel 2.6.10 and my distro does not feel 5 years
>> out of date.
I would guess you're not running stable or testing but unstable. I run testing and it's too far behind the idea of release early and often. I'll probably go to unstable this evening.
Debian takes too long to do releases. It's not NetBSD it should change to a tiered release structure. The four mentioned are a good idea.
In short the time frame between Debian releases is indefensible, it takes to long.
Parent
Re:I disagree wholeheartedly. (Score:5, Insightful)
Sure, you run sid. You know what that means? It means that this proposal won't affect you at all. (additionally, I'm sure you run x86, along with what, 98% of all other debian users?)
The thing is, you're the type of user who doesn't need predictable release cycles. You can get by on the bleeding edge and run software for which a new package release may be uploaded on any given day.
A lot of Debian users are in very different positions. I, for example, run Debian in an enterprise environment, with literally hundreds of servers and workstations. woody is simply not an option in this environment. Hardware support (both kernel and user space) is dreadfully lacking, and we'd have to backport most of the software we use every day anyway. We'd end up running something so bastardized that we'd no longer see many of the benefits of running Debian at all. So we were forced to go with something more current. We chose sarge, with the understanding that we'd have to be responsible for the security of our systems, with little help from Debian. But of course, there are problems there, too. Sarge changes every day. A machine installed today may look nothing like a machine installed tomorrow. Additionally, we simply have no way of knowing when sarge will be released. The saying within Debian has always been "we'll release when it's ready", but of course, there's never a published metric for readiness, so there's simply no way of knowing when that will be.
Basically, right now, Debian really doesn't have a good release for enterprise users. That really sucks, since IMHO Debian provides a software infrastructure that makes it really appealing for large scale deployments. I really hope this new proposal is a step toward a shorter and more predictable release cycle!
noah
(Debian developer, sysadmin, and user since 1997)
Parent
Re:I disagree wholeheartedly. (Score:5, Informative)
You may want to take a look at FAI (Fully Automatic Installation - google will find it). We've been using it quite successfully for that kind of maintenance.
You basically set up a local debian mirror (snapshot of the real tree) and use it to deploy your machines (FAI does it great) and as only apt-source for them. Whenever it's time to update a pkg you test it, then just drop it to your mirror where the clients can pick it up via apt-get upgrade.
Parent
Re:The hell? (Score:4, Insightful)
For guys mantaining stuff like Sparc servers or developing on ARM it was a great choice.
Parent
The real headline.. (Score:4, Funny)
Re:The real headline.. (Score:4, Funny)
Parent
Those would be the good ones to keep... (Score:5, Interesting)
Re:Those would be the good ones to keep... (Score:4, Informative)
For IA64, kernel, toolchain and libc are maintained by upstream, and Debian itself has sufficient IA64 know-how, as well. That's why it's practical to keep it.
Parent
Re:Those would be the good ones to keep... (Score:4, Interesting)
SPARC has barely any upstream support in the kernel. kernel.org kernels are frequently broken. What's worse, Debian hasn't got a SPARC maintainer right now.
Parent
Re:Those would be the good ones to keep... (Score:5, Interesting)
The lack of a SPARC maintainer is a concern, but one that can easily be addressed. (politics aside.)
Parent
Re:Those would be the good ones to keep... (Score:5, Interesting)
Why use linux on sparc 32 in 3 letters : SMP.
Fine hardware, dead cheap, and NO bsd was up to it (until recently, if it happens to work now).
Debian back out in that area is a stab in the back for any user.
Parent
What about ARM ? (Score:5, Interesting)
Perhaps Debian isn't trying to address the embedded segment.
Parent
Re:What about ARM ? (Score:4, Interesting)
Consider that a minimum Debian installation is over 100MB. Debian is definitly not aimed at embedded systems. Never was.
-matthew
Parent
IA-64 vs AMD64 (Score:5, Informative)
Parent
Re:IA-64 vs AMD64 (Score:4, Interesting)
Parent
nooooooo (Score:5, Funny)
well, I can still be using NetBSD. Of course the toaster runs it!
Dropping ARM??? (Score:5, Insightful)
Re:Dropping ARM??? (Score:5, Informative)
The way I understood it was that each architecture would continue to be included in unstable, but when time came to release stable, the architectures that were not up to snuff would not be included in stable. In other words, they are not going to hold off on releasing stable for the architectures that are ready just because some other, less actively devloped ones are not. This seems fair. If someone wants their favorite architecture to be included in the next stable release then they can volenteer to get it up to stable quality, or commit themselves to maintaining it (security patches) after it is released. Otherwise they can just keep using the unstable. This is better than forcing everyone to use unstable, by holding debian back from releasing stable on a timely basis.
The second set of requirements (for SCC) also make sense. If you have less than 50 users, or cannot support the infrastructure needed make mirrors, there is no reason that all the ftpmasters should have to mirror a full branch of code for you - it is overkill. Those 50 people can get together set up their own apt-get repository for their binary packages.
There are several things that I did not like about this plan however, like the non-merit-based requirement, of requiring a machine to be purchasable new. If there are people that are willing to do the work, who cares if the machine is in production or not.
I also don't like the fact that there is no official option for the less active arch's to make stable releases uncoupled from the main stable timescale. Suppose that a minor arch, has enough support to do a stable release every 3 years compared to the x86's 18 month cycle. Choosing to target every other stable release won't work because while there is twice as much time between releases the bottleneck is the time between feature freeze and release, and that will still be determined by the x86 team's (faster) schedule. Furthermore, all the stable releases for all the architectures really should have the same package versions. This will save effort supporting the releases in the future (security patches etc), and keep user confusion down to a minimum. One possible solution would be if they kept the requirements listed, but did not require them to be met at the same time as the x86 branch - let the architectures enter stable when they are ready, with a time limit of say 2 or 3 release cycles of the x86 branch.
In general, requiring all the architectures to walk in lockstep is a real problem that debian needs to fix, but they should do so in a manner that allows the less active architectures to continue to have stable releases at their own pace, while not holding back the x86 line.
Parent
well... (Score:4, Interesting)
However, it is sometimes very useful to use a full system like this to do native compiles of your applications (instead of cross-compiling) and native debugging. Of course, when you move to your custom hardware, you usually have to drop all that nice stuff.
(By the way, I am really a big fan of the Cirrus Logic 93xx series system-on-chip processors. After working on two other ARM SoC systems and one MIPS system, the Cirrus 9315 was by far the best supported.)
Parent
Well... (Score:5, Funny)
About time (Score:4, Interesting)
As anal as Debian is, this is kind of sad. (Score:5, Insightful)
Excuse me? (Score:5, Informative)
Parent
Not apt... (Score:4, Insightful)
Parent
Re:As anal as Debian is, this is kind of sad. (Score:5, Insightful)
-matthew
Parent
In other news... (Score:5, Funny)
Re:In other news... (Score:5, Insightful)
Parent
Damn... (Score:4, Funny)
Hooray "limber release process!" (Score:4, Funny)
Oh, wait...
Older Hardware (Score:4, Interesting)
So the question becomes, who will bother supporting non-mainstream hardware? They are still functional machines for me...
Scary but beneficial (Score:5, Insightful)
Besides, if you really want to run *nix on your Atari go download NetBSD [netbsd.org].
- Cary
--Fairfax Underground [fairfaxunderground.com]: Where Fairfax County comes out to play
Not quite accurate .. (Score:5, Informative)
They seem to imply it is a proposal to drop the actual releasing after sarge
IMHO: requiring a level of 98% is too high and only releasing if you can still buy is rediculous. Debian still mostly compiles for 386(on x86) and it's hard to buy a 386 these days.
IA64? (Score:5, Insightful)
The few machines sold hardly matters. HP 'claims" they will sppnd $3B on IA64 over next 5 years surely they can afford to pay for Linux on this dud of a processor.
Or better still pay the Debian guys
This is not final (Score:5, Informative)
In the long run, Debian may well have to concentrate more on some architectures than others, but a radical step such as the one proposed will probably not fly well with the community. Since our users are our top priority, you can expect many more emails on the topic before anything will happen.
Re:This is not final (Score:5, Insightful)
I understand that Gentoo supports several architectures, including several (alpha, sparc) that would not be supported with this scheme. How come they don't seem to have a problem getting releases out the door? (You may not have more of a clue than I do, but perhaps someone else does.)
Parent
Don't we already have that? (Score:4, Interesting)
So what thing might mean (Score:4, Informative)
If it's that it might be a good things, granting the more popular(?) architectures a smaller turnaround time for stable releases.
Or maybe hell freezes over.
Damn. (Score:5, Funny)
IA64?!? (Score:4, Funny)
Why keep IA-64? (Score:5, Informative)
misleading (Score:5, Informative)
"unstable" -- which is what hacker-type individuals tend to run anyway (and is both much more up-to-date and not particularly unstable) -- will continue for all. As most of the affected archs fall into the "mostly for hackers" category, this change should have little real impact. I suppose the exception might be the sparc.
The benefit of all this is (besides, maybe, faster releases) that they have a plan for adding new scc archs easily.
[I think the "scc" archs will also not use the Debian mirror network, but probably don't have enough users to receive any real benefit from it either.]
Re:Now... (Score:4, Insightful)
If it significantly improves the Debian release cycle, yes.
If it were the other way round, you'd hear them praising themselves on how Linux is great as it's available on all platforms.
Umm, it still would be avaiable on so many platforms. Debian is just one distribution. I'm sure there will be people who will maintain a Debian-like system for all the existing archs. All they have to do is rebuild the packages and maintain an installer for the architecture in question. They just won't be officially "Debian." But thanks for Trolling.
-matthew
Parent
Re:Now... (Score:5, Informative)
If this proposal passes.
Parent
Re:drop me too! (Score:4, Interesting)
status means that the port is free to ignore the
normal release cycle. The normal release cycle is,
predictably, controlled by the x86 majority.
Once free of such tyranny, the non-x86 ports can
fix things without concern for x86 releases.
I'm a Debian user with PowerPC, and I'd love to
have a modern glibc. The upcoming release isn't
worth much on PowerPC right now, because it's still
using the old pre-NPTL LinuxThreads hack.
Parent
Re:NetBSD, here I come (Score:4, Informative)
http://www.gentoo.org/doc/en/mips-requirements.xm
Parent
Re:Why can't the kernel be seperated from the dist (Score:5, Informative)
If everything was well-written and accounted for differing word lengths, byte orders, etc. then we wouldn't be having this conversation. Unfortunately, that's not the case. On the plus side, Debian's dedication to platform equality means that a lot of bugs get exposed (and fixed) that no one would ever know about if the world only ran x86. This is a good thing for everyone, even those where that software already worked as expected.
Parent