Slashdot Mirror
New Debian Installer Coming Soon
gnuman99 writes "Debian just released the 4th beta of the new debian-installer, this time for 9 architectures. Some of the improvements include experimental support for the 2.6 kernel, on i386 only. The 2.4 kernel remains the default and recommended kernel for most hardware. Detection of existing operating systems. The following operating systems can be detected and will be added to the boot menu of the installed system: Windows, Mac OS, Linux, GNU Hurd, DOS. Note that by experimental support for 2.6.x kernel simply means that it is experimental in the installer, NOT the actual OS. Debian supported 2.6.x in the Sarge/Sid before 2.6.x was even officially released."
I used the new installer when I moved to Debian testing on my new workstation a few months ago. There were a couple of rough spots, but nothing a little command line prodding and correcting couldn't get around.
The installer does a nice job of addressing the long-standing issues most people have had with the installer (namely, having to deal with dselect and the 4 trillion packages Debian has :), and breaks the install down into nice, manageable chunks.
Now... if there's a way to script installs (and I believe there is, but haven't checked it out yet) like RH's kickstart so I deploy a couple hundred servers in the datacenter (yes, I know about FAI... doesn't compare to RH's kickstart), I'd be on easy street. :)
Nice work, guys.
Knoppix, as with other installers such as Progeny's PGI and Redhat's Anaconda fail to meet Debian's strict standards. The installer must operate on all of Debian's supported architectures.
If i386 with a CD drive is what you've got then Knoppix is for you. But don't ever think that it can be the installer for Debian. It just isn't up for the challenge.
Except it does not install a clean version of debian (stable, testing or unstable). I have seen someone doing a knoppix hd install only to get lots of package dependency problems because (I think) some important packages are not standard debian packages. Better use some time on the real debian installer.
Since the binaries on the CD are architecture specific what does it matter if the boot system it too?
Do you really want to be able to boot the x86 binary CD on Solaris? How would that help achieve anything? Other than making the boot system completely unintelligible to everyone.
Why oh why hasn't someone come out with a bootloader that detects what OSes are installed _itself_? It can't be that hard. I mean, if there's an NTFS partition, it's not that hard to guess what OS is installed there and how to boot it. For Linux, it's a little more complex. But since GRUB can read Linux filesystems, it could at least look in the /boot directory for promising kernel-type files and put them in the menu for you. I don't know about other OSes, but even if the autoconfiguration only worked for Windows and Linux, it would be a huge step up bootloaders. Think how many newbies would be saved from making their computer unbootable (the scariest thing that can happen to a would-be Linux convert)!
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
The installer is pretty simple - if you know what you want. The other distros (Knoppix, Mandrake, SuSE, etc) make some assumptions based on hardware found and typical usage and set much of the system up for you, but Debian doesn't. Eg, many people won't know which modules they want to load, things like the parport module - obvious if you know, but the installer should detect a parallel port and decide to load it automagically. Imagine a new user doing that, and then hitting #linux with questions about why his printer doesn't work. That's probably the kind of thing that makes it hard for new users, especially users who haven't had much Linux experience.
Forget thrust, drag, lift and weight. Airplanes fly because of money.
What you fail to comprehend is that the precompiled packages may not always be available or that they may not work in the way that you need. Try to find a distro that compiles python scripting support into Vim. Most distros also ship mutt using the ncurses library which often leads to problems when trying to run inside of rxvt. Compiling it with slang support prevents this problem. I also compile in mixmaster support which is not available by default in the distros.
If you ever tried the command line out for a change instead of just discounting it "old" you might find that makes a number of tasks much easier and faster then trying to do them in a gui. Those of us who have some experience with computing choose to use the command line not because we completely disdain the gui but because we understand that it is often the better tool. Spoken language has been advanced for over ten thousand years because it is effective, efficient means of communicating precise information. The same cannot be said about a point and click interface.
It is unfortunate that your ignorance will leave you wasting much of your time fiddling inside of a gui doing what you could have done with a single command at the line. I don't expect that your ignorance is limited to the command line or that you will ever became wise enough to chuck it.
"Spoken language has been advanced for over ten thousand years because it is effective, efficient means of communicating precise information. The same cannot be said about a point and click interface."
Firstly, spoken language is only relevant to communication between sentient entities. However when the communication is between a human and a computer, which is easier?
1) Use a long series of commandline switches in a command prompt after navigating it to the location of the files
2) Click on the file and tick the graphical boxes to get the kind of install you like
Commandline switxhes you need to know, and you have to enter them with the right spaces and the right order. A graphical installer can show the available options spacially with details and descriptions, and help files on hand.
Put quite simply, the graphical installer wins for time-saving and efficiency every time.
I have been a user for about 10 years. This ends Feb 2014. The site's been ruined. I'm off. Dice, FU
The biggest optimizations to be had are already packaged in the kernels to begin with, though there's probably something to be said for tuning up glibc too (IIRC Redhat does this).
> They add detection for GNU Hurd, but not OpenBSD, FreeBSD and
> NetBSD. Funny, really.
Not funny but sad.
Although I suppose they can't really add an installer for
"real" FreeBSD and "real" NetBSD when Debian developers are
working on GNU/FreeBSD and GNU/NetBSD
even if they both have the same amount of users as GNU/Hurd
The Machine stops.
And what objections are against SuSes YAST?
It's only very recently been released under a Free locense so I doubt it was available when most of the decisions were being made.
However, to be clear on this, are you asserting that YAST does work on all the platforms that Debian supports?
MP
Kjella
Live today, because you never know what tomorrow brings
None of that makes Knoppix any less of an excellent installer for Debian.
Knoppix has a first-class installer and I evangelize it alongside the installer for Debian. Knoppix is excellent whenever I encounter a Windows user who has recently been infected with a virus or who is interested in trying out Linux and Free Software.
I have never had any questions come back from users who have decided to run knx-hdinstall. There's no question that the Knoppix installer is both capable and user friendly.
I have also never had any requests for help with the new d-i. I used to help people all the time with the old boot-floppies. Of course, these are possibly different types of people.
Knoppix is not Debian. In the technical sense, Knoppix packages are very customized and would have to be uninstalled to be replaced with the appropriate Debian packages. In the social sense, Knoppix tries to be a demo of what Free Software is capable of. It does not try to be an enterprise-level server, provide a mechanism for distributing security patches
Yes, like 95% of Debian users.
Of English or German-speaking, desktop-using, i386 CD drive wielding users with 2.2GB of disk space free. Don't forget that Debian is the most cosmopolitan of all OSes as web servers. This is because Debian has chosen not to disadvantage minority users. Aside being a moral choice, it's a matter of quality control and quality assurance. Allowing some fraction to be disadvantage worsens the quality of Debian for that fraction. As an example, the installer will ship for all architectures and all languages at the same time.
The Debian Users Worldmap shows that France has the second largest concentration of Debian users, right above USA in third place. Knoppix French is a fork of its own, which shows Knoppix's popularity among French-speaking users.
I hope they share the same installer. Otherwise, the Installation Manual authors would need to document both. Imagine having different installers for each of eleven architectures, then different installers for each of ten supported languages! Who wants to write the installation manual for m68k/atari in Portuguese?
The notion that there should be "the installer" is itself flawed. Many different people need many different kinds of installers.
This is the real crux of your argument then, that installers should be targeted for the people who use them. Let me state that I don't think you're right. Instead, there are many different people need many different kinds of installs. The focus is on the result of the install, not on the installer itself.
One installer is capable of providing all of the different types of installations, in English, French and any language, on i386, PowerPC and any architecture, for servers, desktops and embedded control systems, and that installer is the debian-installer.
None of that lessens Knoppix's quality. If you think that Knoppix has will offer you a better system, more personalized to your tastes, then maybe you didn't want Debian after all. Just install Knoppix.
That's patently false. They just don't think the speed (around 9%) is worth the effort.
I think the real reason is pride, they are afraid of lossing face and admitting they were wrong.
LOL! You've got to be kidding. This distribution is regularly the butt of /. jokes that run along the lines of, "Hey, so I hear Debian is about drop a.out and maybe even make the jump to libc6." If they wanted to invest some ego in a public face there are other things that would play second fiddle to technical matters before they got around to "looking cool" in front of the "133t".
Admitting they were wrong would make it harder to start arguments in the future.
Uhh... Huh?
They argue that debian packages are optimised, the kernel for example has multiple packages each optimised for a different cpu.
Well, that is the most important optimization to make.
The minimum that needs to be done is to modify policy to require packages that can be optimised to have support for end users compiling optimised for themself.
Why bother when you can just install a Debian package that adds that functionality?
I used that technique myself. For 3 years. I would install things into neat little /usr/pkg/<packagename> directories, then use a Perl script I wrote that installed the package to /usr using symlinks. However, you forgot some stuff...
Once upon a time, my computer ran Slackware, but I can't say that with a straight face anymore. I don't even remember which version. Half my C++ programs don't work quite right anymore, inbetween the C++ compiler (dragged kicking and screaming from egcs-2.91) and the C library (I *think* glibc-2.0ish) getting upgraded to modern times. I won't even touch on multimedia dependencies.
Needless to say, as soon as I get a test box to copy everything over to, the server is getting Debian and apt-get shoved up its disk.
Range Voting: preference intensity matters
So file a bug report/mailing-list post/suggestion/whatever. This is a friggen BETA for pete's sake. It's going to change, probably redically, before its final release.
Whining on slashdot is unlikely to get you anywhere - mention it to the developers.
...Rob
The American Dream isn't an SUV and a house in the suburbs; it's Don't Tread On Me.
"How can I remember what was the size and filesystem of the /dev/hda8?"
Because you wrote it down to a piece of paper (just the same for your hardware so you know which modules you have to load for your network card to be usable)?
Usually it pays using simplest solutions to simplest problems.
"In terms of ease of use, it's light-years away from Mandrake"
Still, your Mandrake will probably burn your non-digital monitor by testing it. Debian, on the other hand won't do that. And then, being able to answer "is your monitor able to handle multisync?" puts you in exactly the same situation as asking for refresh frequency supported: just go to the monitor datasheet and read it there.
What's exactly the problem with knowing what your hadware is and how does it work?
Because it's absolutely ridiculous to have to go to a data sheet to install a freakin display? I'm a huge Linux advocate, 3 of my 4 machines run Linux, I like the way the OS works in general. But needing to tell XFree86 low level monitor specs has always annoyed the hell out of me.
I can generally blaze through the install of most Linux distros, but always end up burning 5-10 minutes looking up the blasted vertical refresh rate and other nonsense for my monitor. There's something wrong here.