Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
Debian Businesses Red Hat Software Software Linux

Progeny Ports Red Hat's Anaconda To Debian 199

Posted by timothy from the apt-get-wins dept.
JoeBuck writes "According to this message from Ian Murdock on the Debian developer's mailing list, the Progeny folks have ported Red Hat's Anaconda installer to Debian. They have also written a tool that "facilitates the creation of Anaconda-based Debian installation CD sets". They are also engaged in other interesting unification work, and hope to be able to allow collections of managed RPM and .deb packages to coexist side-by-side." uberkludge points out an article with more details at Ars Technica.
This discussion has been archived. No new comments can be posted.

Progeny Ports Red Hat's Anaconda To Debian More

Progeny Ports Red Hat's Anaconda To Debian

Comments Filter:

  • Historical note (Score:5, Interesting)

    by Xpilot ( 117961 ) on Saturday October 25, 2003 @08:23AM (#7307776) Homepage
    Ian Murdock is the "ian" in Debian. Deb is Debra, his wife.

    • That should be GNU/Deb/Ian

      • Merge? No.

        I have to say that I welcome these developments, but do not believe a merger is possible or desireable.

        Debian is not defined by its technologies, but by its social contract - whch determines exactly what software and technologies can be included in the disrtibution. True, RedHat / Fedora shares a large intersection with the licensing philosophy and package base of Debian. What they do not share makes them wholly exclusive of eachother - at least from the Debian side of the picture.

        This is

        • Re:Great News! But... (Score:4, Informative)

          by Jeremiah Cornelius ( 137 ) on Saturday October 25, 2003 @12:09PM (#7308446) Homepage Journal
          Of course there are other issues...

          Python as a required part of the base install... Some will dance, others will puke.

          Also, tiny root partitions w/ everything other than /bin /lib /etc mounted did not work w/ Ananconda - at least with RH 7x. You needed a couple hundred MBs free in / to install. This required some fancy "behind the scenes" work - from a console between installer stages - for me to get my 6.2 boxes up to 7.0.

          Of course, if you throw the works into /dev/hda1 - there's no prob! Unless you are worried about local priv escalation and other *NIX security issues...

          • others will puke.

            I'll be one of the ones dancing. What's the downside of Python exactly? It's small, it's heavily tested, and its a powerhouse framework for adding more functionality to the base system without adding other dependencies.
            • Yeah.

              but it is just one more - required - interpreter for base functionality, on top of ash/bash and Perl.

              It gets messy when something like this is so basic at the root of the dependancy tree.

              I want a single purpose firewall, or http reverse proxy, or SMTP forwarder - Debian is often my choice for this kind of work.

              I don't like putting compilers or heavy-duty interperter on these.

          • Now, do you think splitting your files up in partitions will help against privilege escalation?

  • installation packages (Score:5, Insightful)

    by Dreadlord ( 671979 ) on Saturday October 25, 2003 @08:25AM (#7307783) Journal
    ... and hope to be able to allow collections of managed RPM and .deb packages to coexist side-by-side ...
    I hope that all other distro creators work towards this too, so many packaging formats just confuse new Linux users, and make it even more difficult for Linux to take part in the desktop world.
    • Oh yes! Especially Slackware. I know that those stuck-up .debs and RPMs will just love having to move into the .tgz ghetto.
    • How about adding support for emerge,cast etc to apt? One installer to rule them all.
    • >... and hope to be able to allow collections of managed RPM and .deb packages to coexist side-by-side ...

      I hope that all other distro creators work towards this too, so many packaging formats just confuse new Linux users, and make it even more difficult for Linux to take part in the desktop world.

      While this sounds all wonderful, how's it going to work? At a binary level, you're going to find all kinds of compatibility issues that can't be addressed by dependencies or by ensuring that the package s
      • For example, you've got Red Hat all but forking glibc by adding the NPTL stuff to it... people compile against that and then those binaries aren't going to work on systems that use a more standard glibc.

        That is not correct. Binaries built using Red Hats glibc do not have any binary portability issues due to NPTL. The only issues are those that are standard with glibc 2.3, such as thread-local locale models.

        In fact Linux is more binary compatible than people tend to think. Under the hood, it's all the s

  • AWWW YEAH (Score:4, Funny)

    by Anonymous Coward on Saturday October 25, 2003 @08:26AM (#7307785)
    My anaconda don't want none unles you got buns, hon.

  • Alien (Score:5, Informative)

    by rf0 ( 159958 ) <rghf@fsck.me.uk> on Saturday October 25, 2003 @08:28AM (#7307797) Homepage
    One very nice utility they might be able to use is Alien [kitenet.net] which allows you to convert from rpm's to debs and many other formats as well

    Rus

    • Re:Alien (Score:3, Insightful)

      by ninkendo84 ( 577928 )

      If alien truly did work well, this story wouldn't be big news. What they're talking about is potentially allowing rpms and .debs to coexist on the same system. Obviously, given the differences between the two package formats, that is a difficult task.

      Right now, it's easy to just convert .debs to .rpms and vice versa, via alien. But you dont see anyone (practically) taking the entire debian/unstable repository and converting them to RPMs, do you? No, because the two package types don't work well together

    • Re:Alien (Score:3, Informative)

      by revividus ( 643168 )
      For some reason alien was not included in redhat 9. I'm not sure why. Now I'm using gentoo, though, and I'm very happy with it.

      Probably for the average newbie who doesn't want to compile things from source (okay, I admit, typing `emerge -u world' doesn't really require you to understand what's going on), having .deb and .rpm work together would be a good thing.

      apt for redhat is a good idea, too, and I believe that can be found at freshrpms.net [freshrpms.net].

    • Alien is good for the occasional package where dependencies are a minor concern.

      The problem with Alien is you lose the dependency tracking information during the package conversion, so it is not good on a larger scale.

      I believe .rpm files can already be handled directly in Debian (not by apt) if they are LSB compliant, but the only thing these packages depend on is the LSB package that provides support for the version of the LSB specification that is required by the .rpm.

      Viewing the quote with that conte
    • Unfortunately, RPMs generally do not follow the Debian packaging guidelines, and are frowned upon with the utmost of eyebrow usage. Native Debian packages are highly preferred.

      Still, Alien is definitely useful in a pinch.

      --Dan

  • Anaconda Screenshots (Score:1, Informative)

    by Anonymous Coward
    These Anaconda Screenshots [redhat.com] look good and could make Debian a lot easier to approach for Joe Average.

    --
    I have a truly marvellous reason to post this as an AC, which however the margin is not large enough to contain.
  • Progeny had a graphical installer available for their Debian-based distro for years, and instead of taking over this one, Debian started creating its own graphical installer despite of a great lack of human resources for the project.

    Now I don't know much about Anaconda or what it really is, and I also don't know much about Debian's reason not to use the Progeny installer, but you'll understand that I'm not really convinced that this would change installing Debian until I've heard confirmations from the Deb
    • IIRC the Progeny installer was i386 only, hence the Debian folks couldn't use it, since the ditro supports numerous architectures. The article doesn't say, but I imagine since RedHat also supports several archs, Anaconda for Debian will as well.

      • "PGI is a multi-architecture graphical installer creation system for Debian GNU/Linux" -- from the PGI homepage, http://hackers.progeny.com/pgi/

        Debian appears to be wanting a completely abstract installer using the debconf system (where code knows how to ask questions and the ui knows how to show the question to the user). Personally, I can't see how that will ever be easy to use - for example, how do you abstractly ask the question 'How should the disk be partitioned?' uniformly across text/gui?

        An abst

        • Personally, I can't see how that will ever be easy to use - for example, how do you abstractly ask the question 'How should the disk be partitioned?' uniformly across text/gui?

          SuSE's Yast does this. Yast had both a Qt and a ncurses interface. They share the same backend. The backend is mostly platform independent.

          SuSE installs using the graphical yast by default, but on the second CD in the cdset the text version of yast is included.

          Both versions are very easy to use.

    • From what I understood, the Progeny installer went mostly ignored in Debian proper because it only worked on x86, and would take yet more retooling and fighting to make work on the _many_ other architectures that Debian supports (like the PowerBook Pismo I'm typing on now - a PowerPC). The Debian developers wanted a truly architecture-neutral, extensible installer framework, and nobody really provides that. I don't know how much work the YellowDog crew had to put in to make Anaconda work in YDL, but I have
    • Anaconda is really easy to use (I use RedHat). To me PickAx is the coolest part of Progeny's project (because I use redhat and not debian.) From my understanding (very limited) it would allow me to create my own linux distribution based on Debian and have anaconda as the graphical installer which is exactly the kind of tool I would love to play with. Does anyone know if this is a correct assumption?

      If it's true I could create very specialized linux distributions for the different types of computers deskt
      • Yes, it makes it easy to _install_ but keep in mind how many architectures Debian supports: x86, Alpha, PowerPC (which covers OldWorld and NewWorld PowerMacs, CHRP and PReP systems, and Amiga PowerUP machines), MIPS, MIPS little-endian, ARM/StrongARM, HP PA-RISC, Motorola 680x0 (which covers 68k Macs, old Suns, Ataris, and Amigas), IA64, SPARC, and S390. How much effort has it already taken to make Anaconda work as a Debian installer for one architecture? (And note those are just the architectures that wood
      • What is a subversion repository?

        Subversion [tigris.org] is a CVS replacement that tries to fix some of the weirdness that is CVS. I've been using it for about a year, and have found it to be very nice -- not much new to learn, and acts in a much more sane manner than CVS. It's still alpha for now (and using it ATM requires that you update fairly regularly), but it seems to be rapidly approaching the beta milestone.
    • Debian didn't use the Progeny installer because it only supported one of Debian's twelve architectures. Anaconda also falls short here, so it'll never be the official installer.

  • Skolelinux and the new Debian Installer (Score:2, Informative)

    by Anonymous Coward
    Debian do have a new installer. Petter Reinholtsen, Michael Cardenas, Tollef Fog Heen and the the others of the Debian-Installer team has made a new installer for Debian Sarge.

    Skolelinux uses this new installer today!:
    http://developer.skolelinux.no/index.htm l .en

    URL to the new Debian Installer:
    http://www.debian.org/devel/debian-ins taller/

    Todo list for the new Debian Installer:
    http://cvs.debian.org/debian-installer /doc/TODO?re v=HEAD&content-type=text/vnd.viewcvs-markup
    • However, as I look it over it appears that this distribution may only work on i*86 machines. Or at least has only been tested on such. And as such it isn't a very strenuous test of the Debian installer. (Progeny had a good installer for that.)

      That said, it's good to see that work is continuing, but I wonder whether it would be easier to finish the Debian-installer or to port Anaconda to the remaining architectures. Somehow I suspect that Anaconda might be the simpler task.
  • This is certainly a good thing for corporations adopting Debian... especially since Redhat now has it's 1 year End Of Life policy for it's desktop products. I've always found Debian's release policy FAR more stable than almost any other distro out there, and stability is probably the main focus of most companies (far more than the latest wizz-bang features).

    Hopefully this will see more corporations adopting Debian, Linux, and will result in a more unified installation process.
    • Who in their right mind would go through install on each and every machine in the "corporate environment"? I would install and configure a system once and clone it for other machines by copying partitions to the other machine's hdd. Reconfigure as needed.

      It is different from Windows, what I said is easy to do, I've done it once :)

  • that's not leet! (Score:1, Funny)

    by Anonymous Coward
    Everyone knows having a shitty installer is what makes an OS leet!

    Then when only super experts can install it just saying you use it shows instant leetness!

    Sure, you don't know why OpenBSD is more secure or how to use ipfilter but by george you got it installed on your laptop! Well now, aren't you mr. leet. When average joes and janes can just slap a debian cd in their drive and be up and running with no troubles how will you get respect as a leet dood? You'll have to switch to gentoo!

    Shit, gentoo is so

  • Changes (Score:4, Insightful)

    by alpha713 ( 701963 ) <`moc.liamg' `ta' `bsurin'> on Saturday October 25, 2003 @09:12AM (#7307931)
    Now I'm not usually one to protect users from computers and in particular linux, but when it comes to the computer illiterate (is that spelled right :P ). I usually try and steer them towards one of the safer distros like RedHat or Mandrake, its not because I prefer either of those two for working on, its simply that debian besides being difficult to successfully install (though not as confusing as OpenBSD), features enough different packages to make anyone a little lost.

    It has quite frankly always been the "power users" Linux. And some of those whould be repulsed at the thought of changing that. Some of my friends suggested that the reason debian was so good was that it only attracted the real geeks, i.e. those that could contribute and make it stronger.

    In the end though what are computer for if not to make the live of both computer literate and illiterate easier. While it may anger some, the masses finally having access to Debian's enormous repository of packages, amoung other benefits, will be a good step forward. And a change that move Linux closer to eroding the market strangle hold that Microsoft Possesses.

    • ...damn and if that ain't bad spelling/grammar I don't know what is. Sorry folks I'll use the preview function next time...

  • Could anyone clarify how this Anaconda installer port relates to debian-installer [debian.org]? In particular, is it also intended to work on PowerPC [soziologie.ch]?
    • Not in the slightest. debian-installer is still being worked on. My guess is this will be yet another effort, like the original Progeny installer (that was used in Progeny Debian) that will be isolated to x86 only. I know that YellowDog made Anaconda work on PowerPC for their distro, though. In any case, I don't expect to see any takeup from the Debian developers of this. Unless it can be made to work on ALL the supported arches with significantly less effort than what debian-installer will take to finish,
    • In particular, is it also intended to work on PowerPC?

      Anaconda is written in Python, so it will probably work or at least will be rather easy to tweak to work on just about every platform that the language does.

      • Re:Relation to debian-installer (Score:1, Interesting)

        by Anonymous Coward
        Anaconda is written in Python, so it will probably work or at least will be rather easy to tweak to work

        Well, apart from assembler or maybe COBOL, I am at a loss imagining a language of which you couldn't say that.

        Isn't the problem rather that hardware detection has a different logic on powerpc?

  • Knoppix? (Score:2, Interesting)

    by bustersnyvel ( 562862 )

    What happened to using the Knoppix [knoppix.org] stuff in the Debian installer? I think the hardware detection of Knoppix really kicks ass.

    The thing I think troubles new users most isn't the choise between package types - it's partitioning the harddisk and knowing what their hardware actually is. That last one can be helped by good hardware detection, but partitioning a disk is something else. What do you think would be best to make partitioning as easy as possible?

    • The debian-installer project (Debian's next-gen installer) is integrating the same discover program that Knoppix uses.

    • Re:Knoppix? Knoppix! (Score:2, Interesting)

      by netringer ( 319831 )

      What happened to using the Knoppix [knoppix.org] stuff in the Debian installer? I think the hardware detection of Knoppix really kicks ass.

      Right!

      I have a UNIX background, including a bit of UNIX on PCs going back 15 years. I'm a Linux newbie, but I've had great luck using Knoppix full time on an obsolete, almost diskless PC in the office.

      Based on the idea that "Knoppix is just Debian" I've been trying to install Debian on a PC where Knoppix just plain works. It's driving me nuts. The network install

  • Comment removed (Score:5, Funny)

    by account_deleted ( 4530225 ) on Saturday October 25, 2003 @09:18AM (#7307952)
    Comment removed based on user account deletion

  • I wonder if they fixed the bugs in Anaconda (Score:3, Interesting)

    by wowbagger ( 69688 ) on Saturday October 25, 2003 @09:35AM (#7308015) Homepage Journal
    I wonder if they fixed the bugs in Anaconda that prevent it from understanding an fstab which contains either:

    a LABEL= line instead of a device name
    a file system type of "auto"

    (and yes, I have reported both to RH.)

    Perhaps they even fixed it so that when there is a failure, you have the option of going to another VC, fixing the problem, and trying again, rather than Anaconda's current behavior of "Nope. Had an error. Gonna reboot now. Definitely gonna reboot. [OK]"

  • Can be used on the same systems without using Alien anyways. They dont really coexist on the server, but my box handles them both flawlessly. SuSE supports APT and RPM's well. I have never had a problem with using either packaging format. Do other "commercial" distro's not do this? I know there is a big (and almost religous) argument on which is the better format, but to me, (just a user, not a developer) I dont see any difference. OTOH, I dont think having things get to standardized is a good idea.
    • This is a common misunderstanding. APT is not a packaging format. It is a front-end to managing installed packages. It supports DEBs on Debian and has been ported by Connectiva to provide support for RPMs on RPM based systems. You are using the Connectiva port with SuSE, so you can't install DEBs with it.

    • This is not a reply to anything you said, just something that seems appropriate (just popped in my mind).

      I know there is a big (and almost religous) argument on which is the better format, but to me, (just a user, not a developer) I dont see any difference.

      From what I have heard (and to some extend, experienced myself), .deb packaging format with APT system used to be better than the old .rpm format and system. However, the latest RPM systems seem to have fixed all the annoying stuff (that I had experien

  • Before passing judgement on Debian's installer... (Score:5, Insightful)

    by Amadablam ( 516748 ) on Saturday October 25, 2003 @09:38AM (#7308024)
    It helps to realize that the debian installer has been developed to work with all of Debian's supported architectures (currently 10 - i386, m68k, sparc, alpha, powerpc, arm, mips, hppa, ia64, and s390). Such an installer has to sacrifice some beauty and convenience for flexibility and power, and those of us who only compare debian's i386 installation to that of RedHat's or Suse's need to realize this. That all said, because of the overwhelming majority of debian users who only use i386 machines, it sure makes sense to me that it would be beneficial to develop a fancy i386-only installer to satisfy the masses. There are plenty of other debian-based distros who have done just that (with varying success). Perhaps this anaconda port is the beginning of just such a project.
    • I honestly don't know what problem people have with the Debian installer.

      I had only installed distros like Red Hat and Mandrake before but I had no problem using the Debian installer.. I just made sure that I had done all the necessary things and it went fine. (Partition, format, install bootloader, etc. in no particular order)

      The only real problem I had was documentation -- it sucks. I wanted to do a net install and had to fight through confusing docs until I discovered that all I had to do was downlo
      • You're soo right.
        People always say that Debian needs a graphical installer, but they never give any real reason. Is there such a huge difference between selecting my root partition with keyboard and using the mouse for that? The only thing this will add to the installer is unsupported hardware.
        Also, I don't really know why I'd have to plug a mouse into my server just for the installation. I could switch to Windows or SuSE if I wanted that...

    • Re:Before passing judgement on Debian's installer. (Score:4, Interesting)

      by Marsala ( 4168 ) on Saturday October 25, 2003 @05:41PM (#7310371) Homepage
      I don't know if you've ever actually worked with anaconda, but (like other open source software) it's possible to hammer it do whatever you need. There is support in anaconda for non i386 archs (s390, sparc, and IIRC, vestigial traces of the alpha installer). Yes, it's going to be a pain to implement code to handle new archs (like the PPC), but there are enough examples of how to do it that it should be possible.

      The one thing that makes me downright ecstatic in all this is the prospect of being able to use the "kickstart" feature of anaconda for Debian. RH's kickstart is pretty damn flexible (as opposed to FAI, FreeBSD's unattended install mode, Solaris's jumpstart, and even the Winders solutions that are available). With the kickstart, it's possible to build and install a customized system from modular parts (instead of having to rely on image based installs)... and that makes it easy to slide in updates or quickly implement new install types.

      Hardware autodetection is abstracted out via kudzu (yes, it's a pain after the OS is installed, but at install time it's a godsend and makes probing hardware programmatically much easier).

      On top of that, you can hack up anaconda to do some other "interesting kickstartish type stuff" (in the words of Matt Wilson).

      Kudos for the Progeny boys for making this available. :) It's going to enable some cool stuff to be done with Debian.
  • From the article:
    Debian variants have been created over the years; none of them has been commercially successful.

    ...err... does "Lindows" ring the bell?
  • One of the roles of a distribution is to provide cohesion between many thousands of seperately managed projects.

    Distributions have policies that dictate how they achive this cohesion.

    The only way to seamlessly mix debs and rpms (or other pkg format) is if they follow an identical policy.

    If people turn to the LSB to provide a common policy then the LSB will effictively become a distribution.

    If distributions have identical policies then they loose their individuality, and their reason to exist.

    If you sac

  • Backwards compatibility (Score:3, Interesting)

    by joeytsai ( 49613 ) on Saturday October 25, 2003 @12:21PM (#7308527) Homepage
    This seems awfully backwards to me. I don't mean to start a ditsro flame war, but as a Debian user I've *never* had to use a Redhat package. Debian's repository is ridiculously huge (actually, too huge, in my opinion) and is well maintained by the packagers and the high Debian standards.

    If anything, Redhat should be making it easier to have debs and rpms live side by side on their machines. In fact, Redhat's whole Fedora thing just seems like an attempt to recreate Debian. Why bother?

    This is getting a little bit off-topic, but take gnome for example. Gnome properly requires dozens of different libraries to accomplish what it needs - but many times I hear people bitch and moan about gnome's "dependency hell". I am throughly convinced the people who are complaining about that are just the people who's distros don't have (or aren't employing) proper library dependency checking, upgrading, versioning, etc. And what do you know, that's exactly the sort of thing Debian solves beautifully.
    • If anything, Redhat should be making it easier to have debs and rpms live side by side on their machines. In fact, Redhat's whole Fedora thing just seems like an attempt to recreate Debian. Why bother?.

      Fedora-Core is Redhat's attempt to have a RHL test bed that they don't have to spend any resources on in technical support. They devlop it, the community devlops it, they take the good stuff and put it in Red Hat Enterprise Linux, Profit!!!

      It's debian like, but will be leaning towards cutting edge fast d

      • If they don't have a "stable" branch, they don't have a workable system. I see nothing wrong with what they're doing...except that I doubt it will succeed. And the reason is that it stops at "testing", which is good enough for hobbiests, but not good enough for either newbies or businesses. (Though I grant that small businesses may be able to use their "desktop enterprise" version at $180-$300 including a year of support and 4 upgrades.)

        Now I suppose that you could say that the commercial version *is* t
    • RPM dependencies have worked very well for me. I notice that Ximian Gnome issues quite a few release that simply fix dependency bugs - but I have never run into any. It seems to work for ordinary users also.

      My dad wanted to try gthumb on RedHat 7.3 with KDE desktop. He just clicked on the rpm in RedCarpet, and it automatically downloaded an installed all 27 megs worth of gtk2 libraries needed to support that. It all just worked. He has a Gig of memory, so having both KDE and Gnome libraries loaded is

  • The only exclusively PowerPC GNU/Linux distro, Yellow Dog, uses the Anaconda installer in its most recent update (3.3, I think). And it is very nice. For me it bested SuSE's Yast2 as the best installer.

    Yellow Dog also uses RPM binaries but includes a version of APT to manage them. They claim that the combination of APT and RPM is not original to them but was converted by a distro in Latin America - I can't remember which.

  • Well folks, I don't know about you, but I think this is a welcome development. I have been using Red Hat for a LONG time now (>5 years), and at one point, I decided to give Debian a try, after hearing how it was supposed to be the REAL "power users" distro. Well, Debian's installer truly is horrible. Not only is it inflexible and difficult to use from the end-users' standpoint, but I understand that MOST OF ALL, it is even difficult for the Debian developers to work with.

    Personally, I think an Anacon
    • What exactly was horrible about the Debian installer? I've never had a problem with it. As for flexibility, the Debian installer allows nearly infinite flexibility: you can use the command-line while running the installation process. Clearly, this is not easy flexibility, but it certainly is a great deal of flexibility.

      What total automation of RPM are you referring to? If you want automation in Debian, you can set a cronjob to run apt-get update && apt-get upgrade daily, and the system will be upgr
      • What was horrible about the Debian installer:

        1) The interface seems slow and clumsy. I think there's plenty of room for streamlining.

        2) It would be nice to have it autodetect my hardware. Granted, I *could* set it up myself if I really wanted to. (Yes, I *AM* a real geek.) However, I don't see any good reason why I should have to do it myself. After all, if the hardware *CAN* be identified automatically and easily, why not do it, and save the work of having to do it manually?

        3) The Debian installer
        • apt-get was not being confused with dpkg. apt-get is very effective at upgrading and installing packages smoothly. Largely, this is because of the quality of the packages. The entire distribution can be upgraded, from one release to the next, using this tool. As I understand it, this is still not possible with other apt-get-related tools. A daemon is totally unnecessary and wasteful for automatic updates anyway.

          As for your other points, they are generally valid but reflect the intended purpose of the insta
          • I agree apt-get is fairly effective; I used to use it before I discovered yum. But yum is truly superior, in my opinion. (For RPM-based distros, anyway.) Yum can also upgrade the entire distribution; I've done that before, too. (Of course, I think it is a pity packages all have such interwoven dependencies that require such a tool, but that's a different matter altogether.)

            As to the problems of hardware autodetection: Sure, there will always be fringe cases, but should we be lowering our standards just
            • Fringe buggy cases are accommodated in the installer, just like there has been no GUI in the installer so that it will install on the most hardware. Using an extraneous addon like a GUI is unnecessary when one isn't using a GUI in a setup. This isn't about eliminating GUI's completely, or eliminating distributions. There's just a difference between the installer and other purposes. The new debian-installer should provide for more options like hardware autodetection due to its modular nature.

              As for the Debi
  • I look forward to all of this being integrated into a stable version of Debian. Shall we say, around 2008?

Slashdot Top Deals

"To take a significant step forward, you must make a series of finite improvements." -- Donald J. Atwood, General Motors

Close