On Tue, 2007-12-18 at 16:35 -0500, Gene Poole wrote: > Hello everyone! Hi > The latest releases (Fedora 7 and 8) have moved away from the older > IDE constructs (up to 15 partitions) to a more SCSI construct (up to > 6(?) partitions). So all older definitions where we learned that one > of the better installations defined specific file systems and mount > points now must move to a more M$ C: drive mentality. No. Drives are platform agnostic with respect to how they are partitioned. The PC bios only supports 4 primary partitions regardless of the type of drive. On PPC macs, you could have I think 15. I believe Sun also allowed 16. It was the PC Bios that limited it to four, and that was the case regardless of the drive interface. It's not a type of drive issue. Typically Linux installs would create 3 primary partitions - /boot, swap, and the third would be chopped up into logical partitions. Sometimes swap was a logical partition within a primary. > If I want to > avoid this I must use LVM so that I can define file systems for the > entire tree. No. I use LVM. I use one primary partition for /boot, one primary partition for swap, and one primary partition for the LVM VG. In the volume group, I have several logical volumes - one for /, and second one for future / (so I can can do a clean install into a fresh root), one for /home, on for /srv, one for /texlive, one for /mp3 What's really cool about LVM - if say I'm running out of room in /mp3 but I still have tons of space left in /home - I can shrink /home and expand /mp3 - all without even rebooting. Try that with the old way of using logical partitions inside a primary partition. It doesn't work. Usually though what I do is leave a bunch of space unused in the Volume Group. When I filesystem starts to get full, I then use the nice graphical volume manager and add some of the unused space to that filesystem, and I don't have to shrink squat. What's really cool - if I'm out of space completely, I can add a second physical drive, add its space to the volume group, and continue to expand the file systems. LVM rocks. > I have no doubt that the RPMs contain all that are needed, except I > can no longer control where it goes. You don't tell me where it's > going to go ahead of time so I can make a file system large enough > and named correctly (more C: drive mentality). That's why you want to use LVM. You can adjust sizes of the file systems as necessary. > And I need to know > this ahead of time so I can do the correct thing while in Disk Druid. > In the FHS, where does it say that Apache HTTPD, Apache Tomcat, > mod_jk, and the Sun Java should go? Mostly in /usr > > Other Points: > /opt and /usr/local are going to be defined regardless if you have > built a separate file system for them or not. They are a part of the > standard file hierarchy. > Yum doesn't know nor should it know about software installed outside > of it's environment. One great piece of software is jedit and there > is no RPM for it - are you saying I shouldn't use it? There are a lot > of good packages out there that aren't packaged in RPM format (jedit > is a java program). The defacto standard for packages is .tar.gz > I've used yum when it was only on the Yellowdog distro (yum = > yellowdog update manager). I started in Linux when there was no RPM. I like to build RPMs myself for most things I use that are not already packaged. For example - I found a cool project called viking (GPS related). No RPM packages. So I wrote a spec file, and then contributed it. Now others who do a svn checkout will have a spec file they can use to make an RPM themselves However, I generally prefer RPMs that other people have written, whenever possible.
