Debian Release Mgr. Proposes Dropping Some Archs 377
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.
The hell? (Score:5, Funny)
Re:The hell? (Score:5, Funny)
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.
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.
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.
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)
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.
Re:I disagree wholeheartedly. (Score:3, Informative)
We already use FAI. It has installed over 200 hosts for us. It's a nice system, and makes enterprise deployment possible (doing several hundred stand-alone installs is simply unreasonable, IMHO), but it doesn't eliminate any of the problems with Debian releases. Maintaining local snapshots of sarge is somewhat helpful, but then you're awfully close
Re:The hell? (Score:4, Insightful)
For guys mantaining stuff like Sparc servers or developing on ARM it was a great choice.
The real headline.. (Score:4, Funny)
Re:The real headline.. (Score:4, Funny)
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.
Re:Those would be the good ones to keep... (Score:2)
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.
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.)
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.
Re:Those would be the good ones to keep... (Score:3, Informative)
I was thinking along the same lines. Heck, I'd think that sparc's are more prevalent out there than the IA-64....
What about ARM ? (Score:5, Interesting)
Perhaps Debian isn't trying to address the embedded segment.
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
Re:What about ARM ? (Score:3, Insightful)
Smaller Distros are mostly Debian-Based (Score:3, Insightful)
Re:Those would be the good ones to keep... (Score:2)
IA-64 vs AMD64 (Score:5, Informative)
Re:IA-64 vs AMD64 (Score:4, Interesting)
Re:IA-64 vs AMD64 (Score:4, Interesting)
The real paradigm shift of commercially released risc processors wasn't a simplified instruction set (they may have once been simple, but that's definately no longer true). The real difference is a consistent addressing schema and a load/store architecture. EPIC, the instruction set architecture of the itanium, does this also.
In fact, if you read each instruction sequentially out of ia64 bundles, each could be an instruction on a hypothetical risc processor. This defeats some of the purpose of the ISA, but is technically valid. I have to agree with the previous poster who suggested that the itanium is risc-like. It is. It's a rather-wide risc processor whose pipe-line control logic is part of the compiler, rather than embeded in hardware. Everything else in the itanium could be added to a risc processor except for the back-wards compatibility thing. (rolling register window, predicated execution, speculative loads, etc)
Re:IA-64 vs AMD64 (Score:3, Informative)
x86-64 is a natural extension of x86 to 64 bits (just like 386 turned the x86 family into 32-bit). IA64 if the name used for Itanimum (or Ita
nooooooo (Score:5, Funny)
well, I can still be using NetBSD. Of course the toaster runs it!
Re:nooooooo (Score:3, Funny)
If by toaster you mean a 3GHz x86 CPU, which gets hot enough to almost be a toaster, then you're in luck.
Re:Yesssssss..... (Score:3, Informative)
But I am not sure where you're getting your PowerPC storyline from. AFAIK POWER1 grew out of the ROMP processor used in IBM RT-PC machines (precursor to RS/6000). PowerPC project spawned from the POWER project, AFAIK, but with the 970 whatever differences the two architectures had have apparently disappeared.
Dropping ARM??? (Score:5, Insightful)
Re:Dropping ARM??? (Score:3, Insightful)
and there's barely any arm desktops/servers.
Re:Dropping ARM??? (Score:3, Interesting)
I think the nslu2 hackers start with deb.
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.
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.)
Well... (Score:5, Funny)
About time (Score:4, Interesting)
Sparc and Solaris are dead (Score:2)
Man, when will people learn that one cannot beat Intel when it comes to R&D and their blitzkreg-like manufacturering of processors?
As anal as Debian is, this is kind of sad. (Score:5, Insightful)
Re:As anal as Debian is, this is kind of sad. (Score:3, Insightful)
That's what drew me to Debian, that's what keeps me with Debian.
Re:As anal as Debian is, this is kind of sad. (Score:3, Informative)
Re:As anal as Debian is, this is kind of sad. (Score:3, Informative)
I have debian on servers and suse on desktops at work; and while I believe we have everything apt for SuSE set up correctly with all the popular apt repositories; you still get a tiny fraction of the packages.
Re:As anal as Debian is, this is kind of sad. (Score:5, Insightful)
-matthew
Not apt... (Score:4, Insightful)
Re:As anal as Debian is, this is kind of sad. (Score:2, Informative)
Re:As anal as Debian is, this is kind of sad. (Score:2)
Seriously, it's a good point. Someone correct me if i'm wrong, but of all the "major" distros, Debian was pretty much the one which offered good support for exotic architectures - specially if you wanted to build a server, it's always been rock solid. It's sad.
I'm sure you could volunteer to take on the work (Score:2)
I thought not.
Re:As anal as Debian is, this is kind of sad. (Score:3, Insightful)
Excuse me? (Score:5, Informative)
Re:Excuse me? (Score:3, Insightful)
Porting and supporting are two very different things.
MIPS but not MIPSel (little endian) (Score:3, Informative)
I don't know which Gentoo has, but it doesn't have both.
-molo
Re:As anal as Debian is, this is kind of sad. (Score:3, Informative)
Well, no, they don't. What Debian does is running their deb Packages through a autobuilder for the given arch and do some surrounding work to get it going. In practice the result is not all that good, since you end up with either a bunch of packages dropped for that arch or simply build into a non-working state. At least that was my experince with trying Debian on Alpha, sure it somehow worked but it was a whole lot less smoot
In other news... (Score:5, Funny)
Re:In other news... (Score:5, Insightful)
Re:In other news... (Score:3, Insightful)
apt/dpkg is neat, but I like the ease AND utility of pkgsrc. How easy is it to port the entire apt/dpkg packages tree to a new operating system? That is all of the packages avai
Damn... (Score:4, Funny)
Re:How did you get around the lack of a MMU? (Score:3, Interesting)
I didn't get around, I just installed an mtec 500/030 board, they're not fast (3 bogomips
Hooray "limber release process!" (Score:4, Funny)
Oh, wait...
Re:Hooray "limber release process!" (Score:3, Interesting)
Last release was 19 July, 2002. While one can apt-get his way to modern times, I have to believe an annual release (or more frequent) will only help bring in fresh users.
FWIW, I run Gentoo with a 2.6 kernel. I have issues from time to time, but they get ironed out with a
Older Hardware (Score:4, Interesting)
So the question becomes, who will bother supporting non-mainstream hardware? They are still functional machines for me...
Re:Older Hardware (Score:2, Insightful)
Re:Older Hardware (Score:3, Funny)
Sweet christ...move out of mom's basement and learn what it is like to kiss a girl. There is ZERO reason to keep these ancient systems running. Recycle the things or donate them to a museum.
Re:Older Hardware (Score:2, Insightful)
Re:Older Hardware (Score:2)
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.
Seems fairly reasonable. (Score:3, Insightful)
I'm not sure how developers and users of the possible unsupported architectures would feel. I'd imagine that they would be pretty upset. There's no reason why they couldn't continue working on their respective platforms on their own, and have whatever release cycle they would like. I've seen an i586 Debian project, but I don't know how successful it is. I also know Slackware recently picked up S/390 support, and Gentoo has a wide range of architectures that it supports. Switching flavors always seems like another possible option.
Re:Seems fairly reasonable. (Score:3, Insightful)
I think the best way to handle this is to have a few supported architectures and let maintainers port to the rest. That way the release schedules of the most important platforms won't be held back, which I believe is a major problem for Debian today.
Re:Seems fairly reasonable. (Score:3, Informative)
Most of the folks using SPARC Linux, like me, use older boxes. They work now, and there isn't a huge number of new systems being sold with the expectation of running Linux. Most of the new SPARC hardware will be running Solaris. Since my Ultra1's work just fine under debian, I do
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:3, Interesting)
As a long time Debian user, I'm all for it, but that's probably because I'm only interested in x86 and AMD64. I think having multiple arch's is a great idea in principle, and I'm not overly keen on the idea of stomp
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.)
Debian.. PFHT.. (Score:3, Interesting)
As for their decision to drop SPARC, good.. I ran Debian on my SPARC boxes for a few years, and it was garbage. Slow, clumsy and at times a few bad packages got in causing problems. Debian for SPARC made Solaris look like a rocket ship.
For all you SPARC users, switch to Gentoo (Running it and loving it) or support one of the other SPARC distros like Splack (Slackware-based SPARC distro).
Re:Debian.. PFHT.. (Score:3, Informative)
Well, I'm sure Debian has their reasons, but I suspect they're suffering due to some of their fans dropping it for other distros. Late releases, stupid politics and aged packages isn't doing this distro any justice.
Debian doesn't suffer from lack of users by any stretch of the imagination. Contrary to what you see on Slashdot, most Debian users understand that the delays going into Sarge and the heated discussions about GFDL licenses are painful but necessary.
Re:Debian.. PFHT.. (Score:3, Insightful)
Mostly because "suffering due to some of their fans dropping if for other distros" is an undefined concept in relation to Debian, in the mathematical sense.
But people will persist in using market driven concepts with regard to non-market driven distros, and Linux in general, won't they?
A lack of developers would be a real problem, but other than submitting bugs the number of users is simply irrelevant to the Debian development p
Don't we already have that? (Score:4, Interesting)
drop me too! (Score:3, Interesting)
because of the feature freeze. Making PowerPC be
unofficial would allow this to get fixed.
Heck, drop every port but x86. It's not nice how
the x86 port drags around the others by the
release cycle.
Re:drop me too! (Score:2)
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.
Forks? (Score:2, Insightful)
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 can't the kernel be seperated from the distro? (Score:3, Insightful)
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.
Posted by Timothy (Leary?) (Score:3, 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.]
Debian will mantain support for the rest of arch's (Score:3, Informative)
All the users running rare platforms can continue using debian, and upgrading their distribution, but they won't have a stable release.
I think this is the way to go...
Embed Me (Score:3, Interesting)
Re:Embed Me (Score:3, Interesting)
Re:Embed Me (Score:3, Informative)
Arches will NOT be dropped - misleading article (Score:3, Informative)
Hey, if you guys would just read the actual announcement from Steve: http://lists.debian.org/debian-devel-announce/2005 /03/msg00012.html [debian.org]
You would see that support is NOT being dropped. Rather, the proposal just allows the common architectures to be released before the uncommon ones are fully tested. This seems like an excellent plan, rather than having to wait forever for Debian releases.
Re:Now... (Score:2, Informative)
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
Re:Now... (Score:5, Informative)
If this proposal passes.
Re:NetBSD, here I come (Score:4, Informative)
http://www.gentoo.org/doc/en/mips-requirements.xm
Re:NetBSD, here I come (Score:3, Insightful)
How many of the MIPS, m68k etc. users here are actually using plain *woody* at the moment anyway, as
Re:Debian Sparc (Score:3, Interesting)
According to this proposal, Sarge would still support Sparc, but the next release wouldn't. I'd bet dollars to donuts that you'd get at least two years of use out of Sarge before wanting or needing to upgrade.
Seeing as I have currenlty used Debian on Sparc for about 6 years now or more I can easily see it remaining in use for another two years at least.