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.
"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.
MP
Kjella
Live today, because you never know what tomorrow brings
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.
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.