| |||||||||||||
|
| |||||||||||||
I am moving to Gentoo...I am moving to Gentoo...Posted Feb 28, 2005 19:07 UTC (Mon) by peace (guest, #10016)In reply to: I am moving to Gentoo... by b7j0c Parent article: Gentoo Linux Is Coming into Its Own (eWeek) "well it looks like FC4 will be a five(!!) CD release because heaven forbid we tell some dude in timbuk2 he will actually have to install something from the network. have fun ripping those ISOs!" You only need CD 1 to install Fedora. Then /you/ can yum install to your hearts content :-p. Perhaps the guy in Timbuk2 is in a remote location, has old hardware and serial terminals. Not everyone in the world has broadband or even reliable dialup. Gentoo would not even be an option in some scenarios. Personaly I think it would be a sad day if talk gets delisted. Talk takes up about 20k on my Fedora system once installed. All those old UNIX utilities could probobly fit on a 3.5" disk. Hagling over removing them to "save space" seems like a serious waste of time. There is a lot of goodness in Gentoo, maintanability is not one of it's strong points though. Especially if you don't have a fast network connection and processor. Case in point, I just upgraded my portable, a Gentoo based 800mhz PIII, to KDE 3.3.2. The compile with all the deps took over 48 hours! Also, getting patches generally means upgrading to the latest release, which might not be what you want to do. I know they are working on this but it is no where near what debian or even Fedora offer in this regard. Kind Regards
(Log in to post comments)
I am moving to Gentoo... Posted Feb 28, 2005 19:57 UTC (Mon) by fjf33 (subscriber, #5768) [Link] It depends on what you mean by maintainability. It usually is a _lot_ easier to maintain a Gentoo box up to date. If a new vulnerability is discovered in a given package you can almost always go right ahead and emerge (that is Gentoo for download source code, compile and install) that package and be up an running right away without having to worry about dependencies and other tweaking the principal distros may be doing. The downside is the compiling time but for a larger site, it is not that hard to setup a big machine to do the compiling and then push binaries arround.
I have found Gentoo much easier to maintain from that point of view. Also when you are upgrading things are still running OK. Is your problem that you had to wait 48hr for your new KDE to be up and running? Your computer was running fine meanwhile and you probably got to try the new KDE before some of the other distros and if it doesn't work you can always use the old one without any problems. Try that with a binary distribution. The good thing is that a complete re-install from a binary is probably only 2 hours long. :)
I am moving to Gentoo... Posted Feb 28, 2005 22:42 UTC (Mon) by peace (guest, #10016) [Link] My problem is that I am running Gentoo on my laptop and it is not easy to set aside over 48 hours so it can chew through a KDE upgrade. Now, I must say KDE is the only package set that gives me this trouble. All of Gnome will compile in a few hours. But I like my KDE... :) I would never run nightly updates automaticaly with a Gentoo box like I would with Debian or SuSE. Gentoo needs a lot of handholding or your likely to have some upset users at 9:05am. Kind Regards
I am moving to Gentoo... Posted Mar 1, 2005 0:58 UTC (Tue) by flewellyn (subscriber, #5047) [Link] I think that there are binary packages for a few really big things, like KDE, GNOME, and X11.
I have not had the need to use them (X doesn't update often, and I don't use GNOME or KDE), but they're there.
Gentoo KDE remerge time Posted Mar 1, 2005 3:23 UTC (Tue) by Duncan (guest, #6647) [Link] The way Gentoo handles KDE is changing. KDE 3.4 betas have been availableboth in the monolithic huge category-package builds, and in split-packages. qt and kdelibs are still pretty big packages to emerge, but after they are merged, if desired, one can emerge konqueror, klipper, kmail, "ketc" <g>, and they'll pull in all necessary split-package dependencies as would any normal emerge. The process is still a bit rough around the edges, with some of the dependencies occasionally needing to be tracked down and merged manually, and the usual beta "challenges", but I'm running entirely kde-3.4.0-beta2, now. For those used to the category package method and just having everything from KDE merged and ready for use, there's still metaebuilds (of the form kde-base/kdegraphics-meta), as well as for now, the old huge category-ebuilds. If one chooses to emerge all of KDE, the initial emerge will take somewhat longer with the split packages, altho emerge time can be reduced using configcache (currently available as a portage patch, but already integrated into what will become portage-2.0.52) and unsermake. However, most folks don't use or need all of KDE, and can skip packages that they won't be using if nothing else deps on them. Thus, emerge time can be brought back into line. For those used to the big packages but wanting to go individual split packages, the biggest hassle will be figuring out which individual packages they want, and merging them instead of the big category-ebuilds. The BIG difference, however, will come with updates. Instead of having to emerge all of kdebase for a konqueror security fix, or all of kdegraphics for those kpdf/xpdf vulns that happened recently, all that will be upgraded will be the individual split packages as needed, konqueror instead of kdebase, kpdf instead of kdegraphics. Likewise upgrading within a major version. Most of the KDE source code didn't change between KDE 3.2 and 3.3, even less between 3.3.2 and 3.3.3. Once your initial KDE 3.x split-packages have been merged, upgrading minor versions will only pull in the individual split-packages that have actually been upgraded. Thus, if nothing at all changed in kpat between the version you have (say kde-3.4.0) and the upgrading version (say kde-3.4.2), the kpat version will remain 3.4.0 even when kde-3.4.2 is merged. No upgrade for that package will be necessary. Of course, because major versions denote compatibility breakage, in the case of KDE, at least dependency on a different qt, upgrades from kde-3.x with its dependency on qt3, to kde-4.x with its dependency on qt4, will still require upgrading everything. On the good side, however, the world file will aready contain the individual packages you have chosen to use, so you won't have to go thru and decide what you want, again, altho for the curious, it's always a good idea to do an emerge -p on the metapackages just to see what they'd bring in, as a quick shortcut to seeing what new packages are available, as well as reviewing your choices on old packages you chose /not/ to emerge. As I mentioned, for those still wanting the old monolithic category-packages, they'll remain available thru kde-3.4. With kde-4.0, however, that may no longer be the case, altho the same components will be mergable by emerging the metapackages. As a leading edge type person myself, I've already unmasked and been playing with the kde-3.4.0-beta packages, as mentioned, and have already unmerged my kde-3.3.3 packages, so I've got a head-start on getting the individual packages I want listed in the world file. Those dragging the tail end of stable will of course be able to choose the packages they want, or simply emerge kde to emerge all the metapackages, when it gets to that point, and they decide living in the 90s with their old kde-1.x <g> or whatever, is getting old. Duncan
Gentoo KDE remerge time Posted Mar 1, 2005 3:44 UTC (Tue) by peace (guest, #10016) [Link] Thank you for the detailed reply. This all sounds very good. The Gentoo devs are relentless with improvements to the system, that is for sure! Kind Regards
I am moving to Gentoo... Posted Feb 28, 2005 20:13 UTC (Mon) by b7j0c (subscriber, #27559) [Link] >> Personaly I think it would be a sad day if talk gets delisted. Talk takes up about 20k on my Fedora system once installed
but that is my entire point, there is no discipline to remove more or less unused code because there is always someone who will say no. the size of the binary is not the issue - the issue is to take software out that people do not need to build a complete modern system. i can say with 100% certainty that talk is not required to fulfill this objective.
once again, you are confusing the code being removed from the CD release with the code being deleted from the universe. i still don't understand why seldom-used packages cannot be installed from the network. for packages the size of talk, this is a trivial issue even for someone with the worst connectivity. and frankly i don't think a mainstream distro should be designed with the string/tin-can crowd in mind as a target audience...these people are in a minority at this stage. let them build a "the entire universe on CDs" distro if they want and distribute it to the thousand or so users who would be interested.
I am moving to Gentoo... Posted Mar 1, 2005 14:14 UTC (Tue) by bk (guest, #25617) [Link] I agree with your basic point about talk and similar packages, however I think it would be a mistake to disregard users in less-fortunate economic circumstances ("third world" countries, etc). If only for strategic reasons if you don't care about the morals of it, remember that the most explosive growth in F/OSS is happening outside of the US. It would be foolish to throw that away.
I am moving to Gentoo... Posted Feb 28, 2005 20:15 UTC (Mon) by b7j0c (subscriber, #27559) [Link] >> You only need CD 1 to install Fedora
this is false by the way, there are packages that are actually split over CDs.
I am moving to Gentoo... Posted Feb 28, 2005 22:28 UTC (Mon) by peace (guest, #10016) [Link] No, it's not false. I just did a minimal install yesterday and it only required CD 1. As for your other points, saying you are 100% certain that talk is not needed ignores the fact that at least one person in Timbuk2 seems to /really/ need it. The problem is not the number of CD's in a distro, it's how they are organized. If all of the most popular apps are frontloaded onto the first few CD's, and you can do a minimal install from CD#1 I don't see what it matters how many additional CD's are part of the release. You only need to download as many CD's as you need for a basic install, whatever you consider basic to be. With FC3 that could be as few as 1 or as many as 4. Removing the code from the CD may be like removing it from the Universe for some people who do not have reliable net access, but thats not the point. The point is that the number of CD's in a distro is a non-issue if the CD's are organized in a way that only requires you to have CD#1 to get a system up and running. Kind Regards
I am moving to Gentoo... Posted Mar 1, 2005 6:05 UTC (Tue) by b7j0c (subscriber, #27559) [Link] >> As for your other points, saying you are 100% certain that talk is not needed ignores the fact that at least one person in Timbuk2 seems to /really/ need it.
But taken to its logical conclusion, I can find a die-hard user for almost all code out there. I am sure I can find someone who will just die if mwm is unavailable. You have to understand you are imposing a cost on everyone for the sake of a few users. Its a delicate balance, but remember some of us are downloading ISOs and it is REALLY PAINFUL to do this on a bloated release.
I am more than happy to orphan a few users to let EVERYONE save literally hours ripping ISOs. Also I don't buy this argument that this guy out in Timbuk2 has absolutely no connectivity - he had enough to post a gripe on Fedora-devel.
>> The problem is not the number of CD's in a distro, it's how they are organized.
Agreed, but FC is generally not aligned so that users can be confident of only ripping disc 1. Once again, there are packages that cross the disc boundary.
If the case you present was reality, that the most-used code was completely enclosed in a single ISO, hurrah, but that isn't the case.
|
|
||||||||||||