"I tried both versions.. Jedi was by far the best. They fixed the lilo bug."
The LILO "bug" was a UI issue introduced into Jedi. It will probably disappear in the next release, as several others found the LILO config UI confusing. It will be interesting to see what the next release of CollegeLinux is like.
To semi-quote J.J. "These guys aren't idiots, but they are just learning the Linux landscape"
... well, I'm a linux idiot and I had no problem with it.
I won't go so far as to say that I'm not a Linux idiot myself. I just tend to notice little details. I'm a very good nitpicker. I also had the bad luck of having an older CD-ROM. Actually, that was more of an issue of dealing with the PC landscape than the Linux landscape.
By default, the installer would assume that ATAPI devices actually followed the ATAPI standard and thus could handle DMA. Red Hat8, FreeBSD, and probably some of the other "bigger" free Unices left disabled DMA for ATAPI devices, because historically, they have not handled DMA well. Slackware and CollegeLinux, however, do not do this "traditional" workaroung and are bug-incompatible with older ATAPI stuff. This is less of an issue today, but I had the bad luck of having an older ATAPI CD-ROM drive that I cannibalized from another machine to replace a faster, more recent CD-ROM that failed.
As a result of this bug-incompatibility, the CollegeLinux installation flopped badly, leaving me with a botched install that wouldn't boot. It took me several days, a comparision with Slackware and Red Hat installs, and deciphering Slackware's Bourne shell install scripts to figure out what was going on. Yet after tracking down the problem, the CollegeLinux developers reported that they would not introduce the "traditional" DMA workaround into CollegeLinux on the grounds that it would only benefit a minority at the expense of a performance hit to the majority. I thought that was a bad design decision not only on the grounds that the workaround was common practice, but that the workaround helped those who had an older CD-ROM drive -- but did not know about the DMA problem -- to avoid mysterious catastrophic failure of the CollegeLinux install, at the cost of a performance hit that would probably be unnoticed. Spending several days to track down a problem only to have the effort largely wasted did not exactly make be feel all warm and fuzzy.
"I tried both versions.. Jedi was by far the best. They fixed the lilo bug."
The LILO "bug" was a UI issue introduced into Jedi. It will probably disappear in the next release, as several others found the LILO config UI confusing. It will be interesting to see what the next release of CollegeLinux is like.
To semi-quote J.J. "These guys aren't idiots, but they are just learning the Linux landscape"
... well, I'm a linux idiot and I had no problem with it.
I won't go so far as to say that I'm not a Linux idiot myself. I just tend to notice little details. I'm a very good nitpicker. I also had the bad luck of having an older CD-ROM. Actually, that was more of an issue of dealing with the PC landscape than the Linux landscape.
By default, the installer would assume that ATAPI devices actually followed the ATAPI standard and thus could handle DMA. Red Hat8, FreeBSD, and probably some of the other "bigger" free Unices left disabled DMA for ATAPI devices, because historically, they have not handled DMA well. Slackware and CollegeLinux, however, do not do this "traditional" workaroung and are bug-incompatible with older ATAPI stuff. This is less of an issue today, but I had the bad luck of having an older ATAPI CD-ROM drive that I cannibalized from another machine to replace a faster, more recent CD-ROM that failed.
As a result of this bug-incompatibility, the CollegeLinux installation flopped badly, leaving me with a botched install that wouldn't boot. It took me several days, a comparision with Slackware and Red Hat installs, and deciphering Slackware's Bourne shell install scripts to figure out what was going on. Yet after tracking down the problem, the CollegeLinux developers reported that they would not introduce the "traditional" DMA workaround into CollegeLinux on the grounds that it would only benefit a minority at the expense of a performance hit to the majority. I thought that was a bad design decision not only on the grounds that the workaround was common practice, but that the workaround helped those who had an older CD-ROM drive -- but did not know about the DMA problem -- to avoid mysterious catastrophic failure of the CollegeLinux install, at the cost of a performance hit that would probably be unnoticed. Spending several days to track down a problem only to have the effort largely wasted did not exactly make be feel all warm and fuzzy.