Gentoo help.....Bootloader

[Crusty]

Allright here is the deal, I have recently started exploring the Linux side of things. I first started off with Mandrake 9.1. Had it installed for a week or two...but had problems with 3D Acceleration and sound. So I installed RedHat 9. I liked Redhat alot, everything worked and I was actually able to accomplish some school work on it, Java programming. I started looking around at some other distros. and came upon Gentoo. I really like the idea of it and how easy it seems to upgrade and install software. So I took the plunge the downloaded the Live1 CD.

I decided to do a Stage 3 install without GPR just to get the feel for the install before I started a Stage 1 or 2 install to take advantage of all the optimizations possible. I followed all of the installation instructions up until the bootloader section. Everything had worked great, everything had been configured as much as I had wanted and things seem to be nice. I am I bit weary about Bootloaders because I have never had a good encounter with them. I have always tried to use LILO because I like the simplicity of it.

What follows is a bunch of information that pertains to this...

/etc/lilo.conf

lba32
boot = /dev/sda
map = /boot/.map
install = /boot/boot-menu.b
menu-scheme=Wb
prompt
timeout=150
delay = 50
vga = normal
image = /boot/kernel-2.4.20-gentoo-r7
initrd = /boot/initrd-2.4.20-gentoo-r7
root = /dev/sdb3
label = Gentoo
read-only
append "root=/dev/sdb3 init=/linuxrc"

/etc/fstab

# /etc/fstab: static file system information.
# $Header: /home/cvsroot/gentoo-src/rc-scripts/etc/fstab,v 1.13 2003/07/17 19:55:18 azarah Exp $

# <fs> <mountpoint> <type> <opts> <dump/pass>

/dev/sdb3 /boot reiserfs noauto,noatime,notail 1 1
/dev/sdb1 / ext3 noatime 0 0
/dev/sdb2 none swap sw 0 0
/dev/cdroms/cdrom0 /mnt/cdrom iso9660 noauto,ro 0 0
/dev/floppy/fd0 /mnt/floppy fat noauto 0 0

proc /proc proc defaults 0 0


none /dev/shm tmpfs defaults 0 0



Partition Info on my 4 Hard Drives: 2 ide and 2 scsi on a AIC7899 controller.

#for some reason it doesn't detect this drive correctly...its a Maxtor 60gb with one partition with NTFS filesystem that takes the whole drive. I know it works, cause I use it in Windows, in fact I am using it right now.

Disk /dev/hda: 520 MB, 520783872 bytes
255 heads, 63 sectors/track, 63 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes



Disk /dev/hdb: 40.9 GB, 40981118976 bytes
255 heads, 63 sectors/track, 4982 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/hdb1 1 2611 20972826 c Win95 FAT32 (LBA)
/dev/hdb2 2612 4982 19045057+ c Win95 FAT32 (LBA)



#This disk is my primary windows Disk. sda1 has my OS on it and sda2 has all my programs on it.
Disk /dev/sda: 18.3 GB, 18389272576 bytes
255 heads, 63 sectors/track, 2235 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sda1 * 1 653 5245191 7 HPFS/NTFS
/dev/sda2 654 2235 12707415 7 HPFS/NTFS


#My linux hardrive.
Disk /dev/sdb: 18.3 GB, 18389272576 bytes
255 heads, 63 sectors/track, 2235 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

Device Boot Start End Blocks Id System
/dev/sdb1 * 1 13 104391 83 Linux
/dev/sdb2 14 107 755055 82 Linux swap
/dev/sdb3 108 2235 17093160 83 Linux


My Rig Specs:
MSI Master K7-S
Athlon XP 2000+
(2x) Maxtor Atlas III 10k 18.6gb U160 Scsi Drives
(1x) Maxtor 60gb ATA100
(1x) Maxtor 40gb ATA100
Lite-On dvd-rom and cd-rw
Radeon 8500DV
Onboard AC'97 Sound
Linksys LNE100tx v4 Network Card

My current Bootloader for windows is installed on sda, my first SCSI drive. (I believe....is there any way to check)

I want to get LILO working for both of my operating systems...what do I need to change in my lilo.conf file, if anything to get this to work and where should I install LILO too? This is my biggest concern, I have yet to still completely understand MBR and bootloaders enough to be comfortable doing this manually.

Another problem...but less severe has to do with fstab. In RH9 I had fstab mount my two FAT32 partitions in /mnt/files /mnt/files2 accordingly...except that only root had read write and execute permissions on them. I tried doing chmod -R a=wrx /mnt/files and the same for ../files2 but it wouldnt let me..is there any way to specify who has permissions on the mounts through fstab?


Anyone that has the time and patience to read through this, I appreciate it greatly, and any help would be gladly accepted.

Thank you very much in advance!
:beer:

 

[Barnaby W. Füi]

Can't help you with the lilo issue - but just wanted to chime in with this since apparently I'm on a roll today.

Don't waste your time worrying about optimizations in gentoo. It is obvious that gentoo developers and users just love to quote big numbers instead of actually enjoying benefits of faster software. The optimizations commonly used are almost never faster enough to warrant paying attention to customizing them - and VERY often they are slower. Gentoo seems to have a legion of newbies running around thinking that these "optimizations" are giving them some high performance system - while the truth is, the difference is mostly trivial, and often it's for the worse. Don't fall for it.

 

[drag]

Importat parts of your lilo config:


boot = /dev/sda <----------where the bootloader is installed. This indicates that it is installed in the MBR of the first SCSI disk.

image = /boot/kernel-2.4.20-gentoo-r7 <---------------------------- your kernel.


initrd = /boot/initrd-2.4.20-gentoo-r7 <------------------- initrd a kernel "extra" that allows you to load modules at boot time. Most people end up not having one if they compile custom kernels. Usually not needed, but is important if you need special modules loaded at boot time. Such as SCSI controler drivers for disk access.

root = /dev/sdb3 <------------------ Were you tell the boot loader the root partiton is.
label = Gentoo <------ the label of the menu entry at boot time.
read-only <---- little extra thing.
append "root=/dev/sdb3 init=/linuxrc" <---------------- These are used to modify the behavior of the kernel drivers at boot time. "root=/dev/sbd3" may be a bit redundant since you already told it what root was, but it's not a big deal. A big example that people must have sometimes is: "acpi=off", which turns off apci power managment for buggy hardware and drivers. (would look like "root=/dev/sdb3 init=/linuxrc acpi=off")



To dual boot with windows is pretty easy. Just another entry in the lilo.conf. Here is what it could look like with a little rearangement to make it easier to read.


lba32
boot = /dev/sda (this will install lilo over the MBR on that disk!!!)
map = /boot/.map
install = /boot/boot-menu.b
menu-scheme=Wb
prompt
timeout=150
delay = 50
vga = normal


#Linux part
image = /boot/kernel-2.4.20-gentoo-r7
initrd = /boot/initrd-2.4.20-gentoo-r7
root = /dev/sdb3
read-only
append "root=/dev/sdb3 init=/linuxrc"
label = Gentoo

# Windows part
other=/dev/hda1
table=/dev/hda
loader=/boot/any_d.b
label=W2k




You may want to double check it instead of coping it. I am pretty worn out right now (a VERY busy day) and am having a hard time thinking straight. 🙂 You may have to rearange your /dev/hda sda stuff to make it work correctly. Then re-run lilo.

Check this out

Just subsitute windows2000 for windowsnt.

There are also other lilo howto's at www.tldp.org and I beleive in Gentoo's installation guide they have a example for a bootloader with a entry to boot up into windows.

Don't forget that you can boot up with the Gentoo disk and chroot to you linux partition and re-edit lilo.conf and then re-run lilo to make up for any mistakes. so if it can't boot up properly you can always fix it. (although I would be sure to make a boot disk or prepare a rescue for windows "just to be safe")

 

[drag]

Originally posted by: BingBongWongFooey
Can't help you with the lilo issue - but just wanted to chime in with this since apparently I'm on a roll today.

Don't waste your time worrying about optimizations in gentoo. It is obvious that gentoo developers and users just love to quote big numbers instead of actually enjoying benefits of faster software. The optimizations commonly used are almost never faster enough to warrant paying attention to customizing them - and VERY often they are slower. Gentoo seems to have a legion of newbies running around thinking that these "optimizations" are giving them some high performance system - while the truth is, the difference is mostly trivial, and often it's for the worse. Don't fall for it.

Yes, the optimization is quite a bit overblown.

However there are plenty of good reasons to use Gentoo in spite of this. 🙂 (I beleive that Gentoo's style of compiling from source is going to be the future choice for installs for linux. For reasons other then optimizations.)

 

[Crusty]

Originally posted by: drag

Originally posted by: BingBongWongFooey
Can't help you with the lilo issue - but just wanted to chime in with this since apparently I'm on a roll today.

Don't waste your time worrying about optimizations in gentoo. It is obvious that gentoo developers and users just love to quote big numbers instead of actually enjoying benefits of faster software. The optimizations commonly used are almost never faster enough to warrant paying attention to customizing them - and VERY often they are slower. Gentoo seems to have a legion of newbies running around thinking that these "optimizations" are giving them some high performance system - while the truth is, the difference is mostly trivial, and often it's for the worse. Don't fall for it.

Yes, the optimization is quite a bit overblown.

However there are plenty of good reasons to use Gentoo in spite of this. 🙂 (I beleive that Gentoo's style of compiling from source is going to be the future choice for installs for linux. For reasons other then optimizations.)

I agree with you on this on Draq. I was drawn to it for the optimizations...but once I actually got into the install I realized that I could install only what I wanted, and ONLY what I wanted. Not all the extra stuff that other distros install as well...although I will end up installing some of them anyways.

 

[Barnaby W. Füi]

Originally posted by: MCrusty

Originally posted by: drag

Originally posted by: BingBongWongFooey
Can't help you with the lilo issue - but just wanted to chime in with this since apparently I'm on a roll today.

Don't waste your time worrying about optimizations in gentoo. It is obvious that gentoo developers and users just love to quote big numbers instead of actually enjoying benefits of faster software. The optimizations commonly used are almost never faster enough to warrant paying attention to customizing them - and VERY often they are slower. Gentoo seems to have a legion of newbies running around thinking that these "optimizations" are giving them some high performance system - while the truth is, the difference is mostly trivial, and often it's for the worse. Don't fall for it.

Yes, the optimization is quite a bit overblown.

However there are plenty of good reasons to use Gentoo in spite of this. 🙂 (I beleive that Gentoo's style of compiling from source is going to be the future choice for installs for linux. For reasons other then optimizations.)

I agree with you on this on Draq. I was drawn to it for the optimizations...but once I actually got into the install I realized that I could install only what I wanted, and ONLY what I wanted. Not all the extra stuff that other distros install as well...although I will end up installing some of them anyways.

If having unneeded stuff installed really bothers you - gentoo generally installs development stuff along with the regular packages (most source-based package systems do, in my experience). That's not ONLY what you need. 😉 Although it's kinda an egg vs. chicken type of thing - with a source based package system, you actually need the dev stuff installed, if you want to install other stuff that needs it.

 

[drag]

Heres the stuff I think installing from source has on it's side, and why it's the "future".

1. Much cheaper to maintain (potentially) a mirror. Instead of having 5-6 binary versions of the same piece of software you simply supply the patches and the package creation directions for each platform.

2. Less bandwidth required for updates. Instead of (as in Debian's case,) having to supply binaries each and every time, you simply have to supply diff files and creation directions. The person if they have the package installed they already have the original source code. only have to upload the new diff/discription files. Mirrors require less time to update diff files then entire packages.

3. Work arounds for liscensing limitations. For instance the GPL requires that you only supply the source code for free, and even then you can charge for access/delivery to cover costs of distributing it. It's doesn't require that you give whole compiled and ready to install operating systems for free.

Also in the case of software like qmail were the original source code is closed, but still allows free access to it and then people have improved it by adding patches and diff files, distributing source code is ideal for that.

4. Portage was written using python. 😛

All in all it makes it nicer for maintaining a "living" distribution that continously updates itself instead of thru traditionally horrific means like version number upgrades and/or service packs.


Downsides:

1. long time to compile everything. This is going to be less and less of a issue as computers go faster. A 400 mhz may take 2 days for a complete and usable X window enviroment built from scratch, however a 3GHZ will do the same in a few hours. You could reduce it further by doing simitanious downloads in the background while you compile a package. Parrallelize the proccess. (portage doesn't do this.)

2. Quality control. Can't be sure what sort of packages will react to different circumstanses that the authors never considured, especially if they use flags like:
-j23 -08 +fast -sse=deomp +fast +superfast +++supermegafast OSOMA--ASga#$Qqkasdf

Of course this could be fixed simply by restricting options and compiling and testing just like traditional quality control for people that want a assurance, then also have a more free-wheeling options for those hardcore people among us.

 

[Barnaby W. Füi]

Originally posted by: drag
4. Portage was written using python. 😛

From what I've read, Portage was designed really horribly. Basically one big Python script, instead of making it modular and OO and whatnot.

I don't really see either as the "winner" in the future, both methods have been around for a long time, and both are very successful.

 

[Barnaby W. Füi]

ugh, forum reboot messed me up

 

[Nothinman]

1. Much cheaper to maintain (potentially) a mirror. Instead of having 5-6 binary versions of the same piece of software you simply supply the patches and the package creation directions for each platform.

That also makes it difficult to test on non-x86 architectures because not everyone has them. If you have a system like Debian with an automated build system on each architecture you can find out easily what builds and what doesn't without waiting for someone to post a bug.

Also in the case of software like qmail were the original source code is closed, but still allows free access to it and then people have improved it by adding patches and diff files, distributing source code is ideal for that.

Packages like that are why the Debian package is just a script that downloads the source and compiles a package from that. In a few extreme cases that's used but most of the time there's a more free alternative available that people would rather use.

All in all it makes it nicer for maintaining a "living" distribution that continously updates itself instead of thru traditionally horrific means like version number upgrades and/or service packs.

Version numbers aren't horrific, how else are you supposed to know if the latest OpenSSL hole affects you?

1. long time to compile everything. This is going to be less and less of a issue as computers go faster. A 400 mhz may take 2 days for a complete and usable X window enviroment built from scratch, however a 3GHZ will do the same in a few hours. You could reduce it further by doing simitanious downloads in the background while you compile a package. Parrallelize the proccess. (portage doesn't do this.)

Not everyone has a new machine for everything, it takes a good 4 hours or so (can't remember exactly, it's been a while) to compile X on my 600Mhz Alpha, I'd really hate to have to do that every time a patch for X comes out.

2. Quality control. Can't be sure what sort of packages will react to different circumstanses that the authors never considured,

And just in general things aren't tested well before they're put up for download. If Gentoo hopes to ever support more than x86 fully they'll need atleast 1 machine per architecture and an auto-build system. And if they plan on supporting anything but the latest release they'll need to do something like compiling in a chroot environment, again like Debian does.

 

[drag]

Originally posted by: Nothinman

1. Much cheaper to maintain (potentially) a mirror. Instead of having 5-6 binary versions of the same piece of software you simply supply the patches and the package creation directions for each platform.

That also makes it difficult to test on non-x86 architectures because not everyone has them. If you have a system like Debian with an automated build system on each architecture you can find out easily what builds and what doesn't without waiting for someone to post a bug.

The people who have the archatectures are the ones who develope packages for it. For instance in PowerPC-land Gentoo has a strong following and therefore has strong support.

Also in the case of software like qmail were the original source code is closed, but still allows free access to it and then people have improved it by adding patches and diff files, distributing source code is ideal for that.

Packages like that are why the Debian package is just a script that downloads the source and compiles a package from that. In a few extreme cases that's used but most of the time there's a more free alternative available that people would rather use.

All in all it makes it nicer for maintaining a "living" distribution that continously updates itself instead of thru traditionally horrific means like version number upgrades and/or service packs.

Version numbers aren't horrific, how else are you supposed to know if the latest OpenSSL hole affects you?

No I mean upgrading by a entire step for entire OSes. Like for instance going from Redhat 7 to Redhat 8 to Redhat 9 over time. In situations like that it is very risky. Debian does a very good job of doing this, but I think distributing by source code lends itself naturaly to this. Each package will still have it's own version numbers, of course. 🙂

1. long time to compile everything. This is going to be less and less of a issue as computers go faster. A 400 mhz may take 2 days for a complete and usable X window enviroment built from scratch, however a 3GHZ will do the same in a few hours. You could reduce it further by doing simitanious downloads in the background while you compile a package. Parrallelize the proccess. (portage doesn't do this.)

Not everyone has a new machine for everything, it takes a good 4 hours or so (can't remember exactly, it's been a while) to compile X on my 600Mhz Alpha, I'd really hate to have to do that every time a patch for X comes out.

Well what about in 2 years? In 3 years? 4-5 years? I'd like to think(hope?) that software isn't growing in bloat allong with the increase in machines. How long will it take to compile X when 3ghz is considured a slow machine?

For unfortunate people who are still stuck with a old 1Mb/s cable line, it will probably take as much time to download the package as it is to compile it. 😉

Plus in Gentoo's case they have tested packages aviable thru the GRP stuff.

2. Quality control. Can't be sure what sort of packages will react to different circumstanses that the authors never considured,

And just in general things aren't tested well before they're put up for download. If Gentoo hopes to ever support more than x86 fully they'll need atleast 1 machine per architecture and an auto-build system. And if they plan on supporting anything but the latest release they'll need to do something like compiling in a chroot environment, again like Debian does.

Gentoo in general has a lot of things going wrong with it, but if someone was to combine the positive qualities of Apt and Portage then we would have the distros to end all distros.

A couple things I realy like about Gentoo is that the packages discriptions aren't in binary form. You can go into the /usr/portage folder and have access to all the packages. You can go and read the package discriptions and manually modify packages if you need too have a special setup. Plus you can several versions of the same package, incase one is broken you can easiely use a older one, or a more experamental one.

Also portage itself isn't written in C. It may be badly designed in itself(I don't know this or not, personally), but writting in python is a BIG step in the right direction. Who cares about the actual speed of the package managment? What's .5 of a second vs 2 seconds to accomplish a task. It's much more valuable to make it easy for the end-user to view how the package managment works. If you don't understand stuff or want to learn you just vi /usr/bin/emerge and then you can get a good idea how it works and it makes it easy to do developement.

 

[Nothinman]

The people who have the archatectures are the ones who develope packages for it. For instance in PowerPC-land Gentoo has a strong following and therefore has strong support.

Then you split the developers for no good reason, there's no reason that apps like Gentoo (the filemanager that had the name first) needs more than one maintainer per distribution.

No I mean upgrading by a entire step for entire OSes. Like for instance going from Redhat 7 to Redhat 8 to Redhat 9 over time. In situations like that it is very risky. Debian does a very good job of doing this, but I think distributing by source code lends itself naturaly to this.

It also lends itself to needing 3x as much disk space for no good reason. The only thing distributing source gains you is free time as you wait for things to compile.

Well what about in 2 years? In 3 years? 4-5 years? I'd like to think(hope?) that software isn't growing in bloat allong with the increase in machines

Just like it hasn't so far, right? Imagine running KDE 3 on a machine 3 years ago, it wouldn't be pretty. And frankly I'll probably still have the same Alpha unless the hardware died, I don't want to have to run 5 year old software because everyone thinks compiling from source is the only way to distribute things.

Plus in Gentoo's case they have tested packages aviable thru the GRP stuff.

But not anywhere near as many as Debian, and unless they revamp their infrastructure and way of doing certain things they won't be able to.

Gentoo in general has a lot of things going wrong with it, but if someone was to combine the positive qualities of Apt and Portage then we would have the distros to end all distros.

Portage already does what the main thing apt does, resolve dependencies automatically. But it's the infrastructure behind it that allows apt to scale and work well.

Who cares about the actual speed of the package managment? What's .5 of a second vs 2 seconds to accomplish a task.

Those of us running older machines, on my Ultra1 167mhz it would probably be more of a 2 second vs 7 second difference and 7s is annoyingly long when you're waiting to type the next command.

It's much more valuable to make it easy for the end-user to view how the package managment works. If you don't understand stuff or want to learn you just vi /usr/bin/emerge and then you can get a good idea how it works and it makes it easy to do developement.

If you're confused how things work and you start by reading the code in /usr/bin/emerge you're not much of an end user, you're closer to a developer already. End users need regular documentation.

Does portage have something like apt-listbugs or apt-listchanges?

 

[drag]

Then you split the developers for no good reason, there's no reason that apps like Gentoo (the filemanager that had the name first) needs more than one maintainer per distribution.

nobody said that you couldn't have one guy in charge of a program, but it's nice to have a user go: "here i made this package for the new release today, you want to look at it?".

edit: well, at least "trusted" user! 😛

It also lends itself to needing 3x as much disk space for no good reason. The only thing distributing source gains you is free time as you wait for things to compile.

The good reason is so that don't have to redownload the entire package for each upgrade or patch. It just downloads the diff file and then applys it and compiles it. As far as free time, when I use Gentoo (debian on my main machine, gentoo on another) I generally don't sit and stare at it as compiles. The cpu time being used prevents me from playing quake, but I still browse the web and get other work done. The extra time spent recompiling patches doesn't affect me. Lot's of times I would be speading more time waiting on binary downloads from busy mirrors then applying new patches and recompiling from source code I already have downloaded.

Plus it makes it much cheaper to operate mirrors if all you have to do is distribute the code. Less disk space and patches use up much less bandwidth then having to resync entire new packages. Mirrors generally have a copy of the code anyways. Plus any mirror can serve any archatecture supported by the OS easier. No need to quadruple the diskspace to support PowerPC, x86-64, alpha, and x86 vs just supporting x86.

Of course if it's a new revision of the program instead of just a patch, then it is kinda pointless to save the source, but you can still clean out the distfile directory of old crap every once and a while

Those of us running older machines, on my Ultra1 167mhz it would probably be more of a 2 second vs 7 second difference and 7s is annoyingly long when you're waiting to type the next command.

Ya, but your not going to be compiling Gentoo on it, are you? There are plenty of reasons to use a scripted language like python over C, openess is the big one. I am sure that the sh init scripts ran like dogs on VAX hardware, but it doesn't mean we should rewrite them all in C.

If you're confused how things work and you start by reading the code in /usr/bin/emerge you're not much of an end user, you're closer to a developer already. End users need regular documentation.

I didn't mean it as a replacement for good documentation, but well designed code (not saying that Gentoo uses well designed/commented code, I am just saying in general) is self-documenting by nature. And there is nothing wrong with blurring the lines between developer and end user, just as long as a end-user doesn't have to mess around with that sort of stuff if they don't want to.

Does portage have something like apt-listbugs or apt-listchanges?

Hell, I didn't know debian had that stuff! 🙂

 

[Crusty]

Debating in my thread eh?
shame shame....hahaha
This is actually very informative, keep it goin!

 

[drag]

Originally posted by: MCrusty
Debating in my thread eh?
shame shame....hahaha
This is actually very informative, keep it goin!

figure out lilo yet?

 

[Crusty]

Originally posted by: drag

Originally posted by: MCrusty
Debating in my thread eh?
shame shame....hahaha
This is actually very informative, keep it goin!

figure out lilo yet?

Been studying for some midterms..gonna try it again Friday morning...after my last Midterm...at 8am...in Logic......

 

[Nothinman]

The good reason is so that don't have to redownload the entire package for each upgrade or patch. It just downloads the diff file and then applys it and compiles it

If someone really wanted to they could do binary patches, I guess it's just not very high priority.

Plus it makes it much cheaper to operate mirrors if all you have to do is distribute the code. Less disk space and patches use up much less bandwidth then having to resync entire new packages. Mirrors generally have a copy of the code anyways. Plus any mirror can serve any archatecture supported by the OS easier. No need to quadruple the diskspace to support PowerPC, x86-64, alpha, and x86 vs just supporting x86.

Disk space is cheap =)

Ya, but your not going to be compiling Gentoo on it, are you? There are plenty of reasons to use a scripted language like python over C, openess is the big one. I am sure that the sh init scripts ran like dogs on VAX hardware, but it doesn't mean we should rewrite them all in C.

Not now, it's doing it's job. I did have OpenBSD on it though and compiling things on it sucked. There is no openness difference in C vs Python, the accessibility is a little better with Python as there's no need to download the source seperately but either gives you the same access as long as the license is right. And VAX machines runs VMS, I'm not sure there's too many sh scripts on VMS =)

 

[drag]

And VAX machines runs VMS, I'm not sure there's too many sh scripts on VMS =)

doh! 🙂

 

[drag]

Disk space is cheap =)

Sure it is, but bandwidth isn't. Maybe I am being silly though, but say you have a openssl vunerability you just patched and need to deploy it out to all your mirrors. Could be a difference between a few diff files transmitted twenty, thirty times to each server vs 4-5 versions of each binary file transmitted twenty or thirty time.

My thinking is along the same lines as the reasoning that debian uses for not maintaining ISO install disk sets.

 

[Nothinman]

Bandwidth for me is cheap because I have a flat rate, it may not be for people who pay per M or G or whatever but they've managed to get by so far, and the time required to patch and recompile the source is almost always longer than the time required to download and install a package. Projects like Debian are lucky, they get a lot of things donated to them because they're a non-profit organization and that covers a huge portion of their would be operating costs.

And for Debian ISOs are a little redundant with the availability of netinstall disks and jigdo.

 

[drag]

You got a pretty fast connection, then, eh? 🙂

Not everybody can live off of handouts like debian can. Gentoo is a for-profit orginization (I think the gentoo.org itself isn't, but other aspects of it are.) If they can reduce the costs of distrubution by going the source distrubution angle vs a binary based distrubution it's to their advantage to do so.

If ya go to debian's website they state in a faq somewhere that the reason they don't distribute ISO is to reduce the load and costs of their servers and mirrors. Not that I am complaining or anything. I usually prefer netinstalls over CD installs if I have a choice in the matter.

 

[Barnaby W. Füi]

We go from lilo to compiler optimizations to package systems to install methods. I blame drag. 😉

Anyways, here's some food for thought: http://zdnet.com.com/2100-1107_2-5057755.html - written by Ian Murdock, debian founder. I actually talked to the guy on irc for a couple hours during the debian 10 yr. deal. 🙂 Really nice guy, unusually nice actually. Kinda funny considering the reputation that debian people have for being harsh and elitist. 🙂

 

[Nothinman]

You got a pretty fast connection, then, eh?

It used to be faster when it was @Home, but AT&T capped the downstream and Comcast kept that policy.

Not everybody can live off of handouts like debian can

No, but Debian's the important one =)

Gentoo is a for-profit orginization (I think the gentoo.org itself isn't, but other aspects of it are.)

And it's already caused them to fork once.

If they can reduce the costs of distrubution by going the source distrubution angle vs a binary based distrubution it's to their advantage to do so.

They've also saved money buy skipping the whole installer deal but how mahy distributions would you recommend do that?

If ya go to debian's website they state in a faq somewhere that the reason they don't distribute ISO is to reduce the load and costs of their servers and mirrors

Yes, because if you think about it. The installs usually go like this 1) install base Debian 2) update system from server 3) maybe upgrade to testing or unstable and that usually has you download atleast 2 CDs more than you need. It's better for everyone if you just get a netinstall CD and install direct from the current packages on the server.

 

[drag]

They've also saved money buy skipping the whole installer deal but how mahy distributions would you recommend do that?

That's kinda what I find ironic about Gentoo. Out of all the installations I've done, it's about the most trouble free.(this and openbsd) It's never just "not worked" like some others. Of course this is because I have to do everything pretty much manually, but it works.

I mean look at this guy that started this thread for instance, he's a fairly new at linux, so much so that he is unfamilar with lilo, but he was still able to follow the directions and pretty much manually install a OS that does something as complicated as downloading and compiling itself from scratch. That's pretty good stuff in my book. He learns, gain confidance in his ability and learns about one the major benifits of a OS like Linux over windows is the ability to get down deep into the OS itself.

 

[Nothinman]

It doesn't guarantee learning, infact all it shows is that the person can read and follow directions.