Stephen McQuay wrote: >> but in my opinion more stable and reliable. > > Hmm. I'm not sure there is anything more stable than Debian stable. > Like, in the world. I run testing on my desktop and home server since > they're still using like python 2.4 or so in stable.
Don't mistake old packages for stable. And I don't think you can make the case that all the packages in the debian repositories receive a tremendous amount of Q&A. Some do. But I can say that a certain level of Q&A has gone into every package Red Hat ships. The infamous Debian openssl issue a while back highlights the problem with Debian's stability. Also things kind of went downhill when some core debian people left the project. One went to Sun to work on OpenSolaris; I think there were others lost as well. > Yeah, we use blender for things from benchmarking to making 3D shorts > all the time (3D renders are embarrassingly parallel, and provide a > simple test case, useful for debugging distributed cpu management > software). I always build/run from svn, and 2.49 has been rock solid > for quite some time (enough for it to be the default in Debian > testing, ubuntu 9.10 (probably older too), arch, and gentoo). You can use RHEL for this, on a cluster for example, but Blender is being developed too rapidly to be stable enough for inclusion in RHEL core packages. Red Hat cannot make any guarantees concerning Blender. > But let's talk about htop (and friends) again. I have to grab > somedude's rpm for that? I must admit i don't know much about package > signing; are rpms from the two RHEL repos you mentioned signed? Absolutely not. You get them from the EPEL repository. Not "somedude's" repository. EPEL is the _official_ add-on repository, signed by the fedora project, for unstable and bleeding edge stuff for RHEL. Yum install. RPMForge was started by one guy, Dag Wieers, who has a tremendous reputation in the community. It is now maintained by a larger pool of people, though, and a little community Q&A is done (a lot of it upstream). RPMForge is signed of course. >> While it is true that Debian has everything under the sun, a lot of >> packages can't really be vouched for and are likely unmaintained. > > Okay, that's rarely the issue I suffer from: it's modern codes that > go missing from the RHEL/SLES repos. Haven't had that issue. I don't know of any RHEL users that often have that issue either. Now, upgrade from PHP version to version over the lifetime of the server is normally not acceptable in the enterprise either, which is why, for example, RHEL 5 is stuck at PHP version 5.1 and Python at 2.4. > Anyhow, I'll probably give the Fedora a try one of these days: I have > very little against learning something new and comparing it against > what I've currently got. And, it's been about long enough since last > I labored through a RH-based install and struggled against all > things rpm, so maybe they've gotten better. I'm a strange one in that I think if you have something that works for you, why change? I like Ubuntu fine, for example, but I'm running Fedora and it works very well for me. So I don't see what changing to Ubuntu will do for me. On the RPM note, I'm always amused when people talk about RPM's short comings and then go to compare it to apt, which is a silly comparision. RPMs are equivalent to .debs. In fact at that level I can't see any difference. RPMs do have one advantage over .debs. That is that they handle multiple architectures fairly cleanly and smoothly. In other words RPM can deal with the idea that I have two identical packages, one 32-bit and one 64-bit than can both be installed without causing conflicts. This a big deal for me, since all my servers are 64-bit and occasionally I need to deal with a 32-bit binary for whatever reason. And functionally, apt and yum are equivalent as well (speed issues notwithstanding). Yes synaptic is wonderful, but it's a usability nightmare for non-geek users. Finally, dependency hell happens regardless of packing system and resolver. Even on Debian (happened to me). -------------------- BYU Unix Users Group http://uug.byu.edu/ The opinions expressed in this message are the responsibility of their author. They are not endorsed by BYU, the BYU CS Department or BYU-UUG. ___________________________________________________________________ List Info (unsubscribe here): http://uug.byu.edu/mailman/listinfo/uug-list
