Slashdot Mirror
Debian Release Mgr. Proposes Dropping Some Archs
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.
Seeing as they're the major systems out there. But IA-64? I've barely heard of that, and TFA says Microsoft dropped XP for that. Can anyone elaborate as to why this one was kept?
Obligatory Soundbite Catchphrase
Thanks a lot! This was about time, or else we would never get a new stable release. Lets just hope thats it gets further then just beeing an proposal...
So the question becomes, who will bother supporting non-mainstream hardware? They are still functional machines for me...
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.
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).
It's called Ubuntu.
Perhaps Debian isn't trying to address the embedded segment.
Engineering is the art of compromise.
I wouldn't say that IA-64 is similar to RISC chips. If anything the VLIW paradigm is exactly the opposite of RISC.
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 little patience. There's always someone in the community that has an answer and very often, a solution.
It seems Linux and its distributions are at a minor crossroads where stable releases and unstable, bleeding edge releases meet. On one hand you want to get new features out to users so they can test them and the software can be refined, but now that Linux is finding its way into production environments and a few desktops, bugs can be real backbreakers.
"Play is the only way the highest intelligence of humankind can unfold." -- Joseph Chilton Pearce
It's not a joke. Dropping a port from "official"
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.
As an embedded linux developer (who has worked on both ARM and MIPS), I can tell you that for a production, shipping system, it doesn't matter. You'll almost always end up rolling together your own thing. However, when a vendor (e.g. Cirrus Logic) has an evaluation board (e.g., EDB9315) that comes with a hard drive with Debian loaded on it and you can see that X11 works with the framebuffer driver and USB keyboards and mice work and network apps work, it's very impressive. Most imporantly though it verifies that the drivers (framebuffer, usb, ide, serial, network, pcmcia, CF, et cetera) are implemented in a standard way and will work with "off the shelf" linux apps. This makes things amazingly easier than with other companies whose linux ports are not as complete or functional. And if you're a small company doing an embedded Linux project, it's much better to go with a System-on-Chip processor from a vendor that provides a good Linux port and good Linux drivers than it is to either do your own or write your own drivers.
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.)
My other first post is car post.
That's not exactly true either.
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)