Weekly Edition
Return to the Distributions pageSponsored link
Vyatta –
Linux & Open Source
Alternative to Cisco –
Advanced Routing,
Firewall, VPN, QoS..
Free Download ->
| |||||||||||
Review: Debian-Installer Release Candidate 1 (linux.com)
Here's a review
of the new Debian installer on linux.com. "Debian-Installer Release
Candidate 1 (RC 1) has some ways to go in accessibility. It is still
text-based, a sub-project to provide a GTK GUI having apparently suffered
crib-death. In places,too, it requires system knowledge that might make the
inexperienced feel a trickle of sweat. Yet compared to the labyrinthine
twists and turns of the old installer, the new Debian-Installer is a stroll
through a suburb whose streets are laid out on a grid. Unless you choose
more control, only a minimal amount of user input is required - language,
keyboard, time zone, root and user passwords - and in less than forty
minutes the result is a working Debian system." (Thanks to Steven
G. Johnson)
(Log in to post comments)
Review: Debian-Installer Release Candidate 1 (linux.com) Posted Aug 11, 2004 3:02 UTC (Wed) by jwb (subscriber, #15467) [Link] I just installed using debian-installer for the amd64 port mere moments ago. It was a pretty okay experience. The only minor trouble I saw was that the autodetection of network devices offered to install the distribution over my firewire port by default, with the ethernet port as an option. There should probably be some minimal hack to assign eth0 to an actual ethernet device, in preference to cockeyed tunnelling schemes, but that's a pretty minor error and I suppose it is probably somehow related to the nforce3 chipset acting bogusly.
My sysadmin side is glad to see debian-installer is automatable. It's easy to make a custom installer. I have a hack here that boots and installs the system with a given package list, totally unattended. All I had to do was drop some minimal shell scripts in various *.d/ directories and burn the disc.
So debian-installer, besides being a human-friendly way to install unsupported ports, also excels at tasks without involving the human.
Review: Debian-Installer Release Candidate 1 (linux.com) Posted Aug 11, 2004 8:02 UTC (Wed) by debacle (subscriber, #7114) [Link] Could you please elaborate on the automation issue?Better: Could you publish a HOWTO, please or point to a possibly existing one?
biggest problem is long release cycles = out-of-date kernel, X11 Posted Aug 11, 2004 3:33 UTC (Wed) by stevenj (subscriber, #421) [Link] I've installed Debian a number of times, and the biggest problem is not the installer, but rather the fact that Debian's long release cycles mean that (except immediately after release) the installer relies on an old kernel lacking the latest drivers.X11 is also quickly out of date too and you often need to upgrade to recognize recent cards — this is somewhat less of a problem since you can upgrade to (Yes, it's possible to load additional kernel modules off a floppy during the install process, but this is fairly hairy for non-experts.) They really need to update the installer kernel periodically, or better yet have a shorter release cycle for a small core including the kernel and X11.
biggest problem is long release cycles = out-of-date kernel, X11 Posted Aug 11, 2004 7:19 UTC (Wed) by lolando (subscriber, #7139) [Link] I believe the current rc1 is using kernel 2.4.26 on most arches, which was the latest released kernel available when the rc1 images were built. They may still decide to go for 2.4.27 before final.
As for X11... I'm not convinced the version used is really old either.
And the "split release" (core/rest) has been discussed numerous times with no clear advantages being found.
biggest problem is long release cycles = out-of-date kernel, X11 Posted Aug 11, 2004 7:33 UTC (Wed) by lolando (subscriber, #7139) [Link] Update about the kernel: the *default* kernel is 2.4.26, but as far as I know there's always the option of installing using 2.6.7, which was also the latest 2.6.* kernel released at the time of rc1.
biggest problem is long release cycles = out-of-date kernel, X11 Posted Aug 11, 2004 9:34 UTC (Wed) by climent (subscriber, #7232) [Link] And the "split release" (core/rest) has been discussed numerous times with no clear advantages being found.Huh? No clear advantages being found? I thought after having 9000+ binary packages for Sarge we had already decided to go for a Core+Components release for Sarge+1, since is humanly impossible to get a decent release with so many packages.
biggest problem is long release cycles = out-of-date kernel, X11 Posted Aug 11, 2004 10:50 UTC (Wed) by broonie (subscriber, #7078) [Link] IIRC the main problem is that the stuff you want to include in the core (kernel, glibc, X, GNOME, KDE, GCC, whatever) is the stuff that has problems: with most of the rest of the packages you can relatively easily just drop it from the release if it's buggy.
biggest problem is long release cycles = out-of-date kernel, X11 Posted Aug 11, 2004 15:41 UTC (Wed) by ncm (subscriber, #165) [Link] The problem is that they will get out-of-date very, very quickly. It needs some process whereby the installer's kernel and drivers get frequent updates in between releases.
biggest problem is long release cycles = out-of-date kernel, X11 Posted Aug 12, 2004 0:41 UTC (Thu) by BrucePerens (subscriber, #2510) [Link] The new installer comes in a 2.6 version and a 2.4 version. Nothing seems to break. Debian packages both 2.4 and 2.6 .Bruce
biggest problem is long release cycles = out-of-date kernel, X11 Posted Aug 12, 2004 5:22 UTC (Thu) by stevenj (subscriber, #421) [Link] Bruce you are completely missing my point (just like another respondent above, sigh).Yes, immediately after a Debian release, the kernel and X are up-to-date — I'm not complaining about any current problems with Sarge. The problem is that they quickly will be out of date, just as Woody's installer is out of date now ... Debian's long release cycles essentially guarantee that any installer will use obsolete versions for a majority of its lifetime. So, improvements to the installer UI are nice, but they don't address what, for me, has been the major hassle in installing Debian — to address that, Debian needs to have a shorter release cycle for the installer kernel and X. (Or at least, have supplementary kernel modules and video drivers backported to stable periodically.)
biggest problem is long release cycles = out-of-date kernel, X11 Posted Aug 12, 2004 8:16 UTC (Thu) by lacostej (subscriber, #2760) [Link] Except that Debian stable is targetted at servers. Yo don't need a new X nor a new kernel on those machines, most of the time.
Maybe the backports site takes care of this for you, but I am not 100% sure.
biggest problem is long release cycles = out-of-date kernel, X11 Posted Aug 12, 2004 11:53 UTC (Thu) by jhs (subscriber, #12429) [Link] I agree with stevenj on this one. New server hardware does come out periodically, for example network and disk controllers (I'm thinking about new SCSI and RAID cards). Installing woody on a system with such new hardware is not fun.
biggest problem is long release cycles = out-of-date kernel, X11 Posted Aug 12, 2004 15:36 UTC (Thu) by jeld (guest, #22397) [Link] Debian web site, clearly states, that security patches are not issued foreither unstable or testing, and that security is not a primary concern for these branches due to their experimental nature. http://www.debian.org/security/faq.en-gb.html#testing I would not want my desktop system to have a few gaping security holes just because I installed Debian testing/unstable system. On the other hand I do not want to run KDE 2.2.2 or Gnome 1.4.1 o(versions taken from current stable branch) just to have a stable secure system. The sarge release will help this issue for a couple of months (if that), but KDE 3.3 is right around the corner, GNOME 2.8 is coming in huge strides, and once these and other packages are released the Debian stable will be back to being a horrible dinosaur. Some people have suggested running stable with some packages from testing/unstable using apt pinning. Unfortunately, as soon as testing/unstable changes version of some major piece of software such as glibc everything starts to depend on it. So, trying to install latest version of say abiword will pull latest GNOME, GTK+, XFree, glibc, etc. Effectively your system will become a testing/unstable with a few outdated packages. The only true remedy (IMHO) for the situation, would be for the security team to become responsible for testing branch. This might mean that some stuff will take longer to get from unstable to testing, but at least testing will have most latest versions of stuff and be binary compatible with latest and greatest.
biggest problem is long release cycles = out-of-date kernel, X11 Posted Aug 19, 2004 8:50 UTC (Thu) by xoddam (subscriber, #2322) [Link] Making the security team keep up-to-date with testing won't help a thing.Certainly maintainers of packages in unstable ought to be a little more security-aware than they are (at the very least, they should be alerted to get an upstream fix by the very fact that the stable version has had a security update) but the Security team itself should not be obliged to track the latest-and-greatest of everything; their job is to keep production systems secure. By-and-large unstable gets security fixes shortly after the upstream fix to the latest version. Remember than *Debian* unstable/testing is actually a collection of upstream maintainers' latest *stable* packages. The only real solution is to shorten the gap between *stable* releases of Debian. Another stable release in one year instead of three wouldn't hurt anyone. The pain of upgrading from a three-year-old stable to a current one is about to be inflicted on thousands of users; as Debian developers have to go through all that *anyway*, they may as well go through a minor dose of release-agony once a year than heaps every three or four years. The security team will then not have to worry about back-porting at all! I think this is the plan anyway.
biggest problem is long release cycles = out-of-date kernel, X11 Posted Aug 17, 2004 14:39 UTC (Tue) by hazelsct (subscriber, #3659) [Link] WRT X, you're right, out-of-date X does cause problems for newer hardware.
WRT kernels, my experience with both potato and woody was that -proposed-updates had new kernels very quickly; I don't see why this would change with sarge. Just add one extra line to /etc/apt/sources.list:
deb http://http.us.debian.org/debian stable-proposed-updates main contrib non-free
Review: Debian-Installer Release Candidate 1 (linux.com) Posted Aug 12, 2004 6:43 UTC (Thu) by dmantione (guest, #4640) [Link] At the risk of being flamed, I can't help but notice that Debian has nowachieved the level other distributions achieved more than five years ago: A user-friendly text-mode installer.
Review: Debian-Installer Release Candidate 1 (linux.com) Posted Aug 12, 2004 7:20 UTC (Thu) by mark (guest, #1921) [Link] I know that was a bit of a troll, but ... the debian installer is typically used only once on anyparticular machine. after that, you use apt to keep your distro up-to-date. by comparison, when using red hat linux (at least until after RH 8, at which time i stopped using RH), every upgrade used the installer. so the installer was a far more critical component for RH than it was for Debian, at least in my experience.
the old debian installer was a bit of a handful but it's not like it was broken. on the other hand,
Just my 2 millicents.
Review: Debian-Installer Release Candidate 1 (linux.com) Posted Aug 12, 2004 8:16 UTC (Thu) by lacostej (subscriber, #2760) [Link] Can you cite me any other Linux distribution that, 5 years ago, or even now, had an installer that worked with 11 architectures and over 9000 packages?
And the problem solved by the installer as of today are also different in nature as the one solved some years ago. Integration with new hardware detection library for one.
Review: Debian-Installer Release Candidate 1 (linux.com) Posted Aug 12, 2004 8:37 UTC (Thu) by dmantione (guest, #4640) [Link] The amount architectures and packages in definately a point in favour ofDebian. However, apart from hardware detection (which was completely absent by the way), and booting, an installer is not that architecture dependend. So, IMHO, the amount of packages and architecture cannot not have been an excuse for being unable to code a better installer. In fact, the matter only got attention after a series of bad reviews the previous release got. I hope it is not too late. While this installer may make it a bit more doable to install a system for many people, the expectations of people have increased over the years. @mark: This is true. Debian did have an advantage. But that was a few years back. You know, a few years back I had to write my own scripts to configure Ghostscript in front of my jet-direct network printer (since it cannot be done with a single print-queue). Today, no one wants to write his own scripts to use his printer. And it is not need anymore. Today I can configure pre-filtter queues, print-filter queues all from within YaST. In other words, today people expect good tools. Some more than other; I, personally, edit a lot of config-files by hand, but in general the expectation is nowadays that all important settings can be done from the desktop, with as few mouseclicks as possible. And this is what other distributions currently have made great progress at. But the Debian people are still struggling with a problem that other distributions have solved years ago.
Review: Debian-Installer Release Candidate 1 (linux.com) Posted Aug 12, 2004 18:15 UTC (Thu) by vmole (subscriber, #111) [Link] But the Debian people are still struggling with a problem that other distributions have solved years ago. I guess that depends on your point of view. The other Linux distribution installer I have significant experience with (RH, in various guises since 7.1 on), works fine, so long as nothing unexpected happens. When it does, you're screwed, and you've wasted a lot of time. The Debian woody installer, OTOH, requires more attention. But it *works*. Yeah, you may have to handload some drivers, or replace the installation kernel if you've got fancy new hardware. It's really not for your Linux newbie. But then, neither is Debian, and I think this is what many people miss: not every distribution has to be aimed at rank beginners. There's room for a distribution that supports the experienced user, w/o getting in their way. I think the strengths of Debian are best appreciated by those who've suffered in the darkness :-). Don't get me wrong: I'm all for a Debian installer that has a "click 3 times and go away" mode, but not at the expense of supporting obscure requirements and situations.
Review: Debian-Installer Release Candidate 1 (linux.com) Posted Aug 13, 2004 13:43 UTC (Fri) by micampe (guest, #4384) [Link]
I was discussing exactly this with some Debian-using friends a couple days ago. What's the point in supporting 11 architectures when those used in the real world are like 3 or 4? For people with particular needs I think a dedicated distribution would be much better than one you need to tailor to your needs after the install. When I installed Debian on my iBook a year ago or so, it installed APM (wich is x86-only) but not PMU (wich is its PPC counterpart) and told me it successfully configured X and networking but that wasn't the case. At all. What's the point in supporting 9000 packages when many of them are just dead or used by a handful of people? What's the point in building packages on architectures where they will never be used? I mean, who's going to use GNOME on m68k or mips (I've checked, it is built, thank God OOo is not)? My opinion is that a lot of resources are wasted in this approach and the Debian project could work much better if it focused more on the real world.
Diversity of architectures Posted Aug 17, 2004 14:33 UTC (Tue) by hazelsct (subscriber, #3659) [Link] Just FYI, I did a lot of the experimental GNOME 2.6 package building and uploading for ARM, and even on a 200 MHz Netwinder (with 128 MB RAM), performance was quite acceptable. This is much slower hardware than many mips(el) machines, quite a bit slower even than most new handhelds. And numerous people use m68k machines for tasks for which you don't seem to have sufficient imagination.
Furthermore, for organizations with significant installed base of PA-RISC, SPARC or SGI (MIPS) workstations, S390 mainframes etc., or a mixture of architectures, the ability to install a modern desktop and server OS whose operation and administration is uniform across all of these arches is a tremendous benefit. Such machines also suffer vanishingly close to zero successful attacks even when left vulnerable for long periods of time, as they are immune to script kiddies who just pull the latest x86 or PPC exploits off the net. (Yes, there have been Linux PPC exploits, and they have caused significant damage.)
|
|||||||||||