Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Operating Systems Software Businesses Red Hat Software Linux

New Community-Run RPM-based Distribution 71

Posted by timothy from the whacking-at-a-gift-horse's-teeth dept.
KainX writes "As an alternative to the Red Hat-controlled Fedora project, the community-led cAos Foundation decided to create a fully community-built, community-controlled, RPM-based distribution whose foundation would be a self-hosting, self-sufficient core with a 3-5 year support lifetime. The first stable, production-worthy core has now been officially released! Download an ISO from a mirror and try it out."
This discussion has been archived. No new comments can be posted.

New Community-Run RPM-based Distribution More

New Community-Run RPM-based Distribution

Comments Filter:

  • I wonder how it will compare to... (Score:1, Interesting)

    by Anonymous Coward
    Fedora Core 4 which should be coming out soon.

  • 3-5 year lifecycle? (Score:2, Interesting)

    by mlynx ( 812210 )
    What does the lifecycle determine? It sounds like the distro is built to be constantly maintained, similar to Gentoo. Or does it mean that in 3-5 years it will be so outdated, that you'll be thrilled to upgrade?
    • The lifecycle statement is actually very important when comparing this project to Fedora. For instance, Fedora is basically impossiable to standardize an infrastructure on because it is constantly changing. There is not always a clean upgrade path (which is by design).

      By stating that cAos actually has a life longer then 6 months, we are commiting to its long term viability as a solution.

  • And the point of this is? (Score:3, Insightful)

    by m50d ( 797211 ) on Monday May 16, 2005 @03:25PM (#12546373) Homepage Journal
    No problem if they're trying to scratch their itch, but seriously, why is this needed? There are plenty of alternatives to redhat and more than enough community-based distributions - debian and most of its derivatives for starters. Why would they choose to go with rpm?
    • Because RPM already won [freestandards.org]. It is the Linux standard. Period. Until that changes, arguing over package formats is simply political/religious and accomplishes nothing.
      • It won because a few big distros stacked the standards comittee. And LSB distros only need to provide a way to install RPMs, not use it as the primary package managment for the actual system. (RTFFootnote on the link you give)
        • It won because a few big distros stacked the standards comittee.

          We could argue all day about why it won, but it wouldn't change the fact that it won.

          And LSB distros only need to provide a way to install RPMs, not use it as the primary package managment for the actual system. (RTFFootnote on the link you give)

          I'm quite aware of that. But there is little, if any, reason for a modern distribution to choose a different package format and have to manage a compatibility layer for LSB compliance.

          RPM has a
  • Honestly, what good comes from another distribution broken by RPM's poor package management, when .debs just work?
    • One, stop trolling. Two, somebody needs to mod this troll down.

      Three, read this: http://linux.slashdot.org/comments.pl?sid=149694&c id=12547628 [slashdot.org]

      Four, what makes DEB's "just work" is policy, not technology. An RPM-based distribution with as anal a policy as Debian's would "just work" too.
      • Four, what makes DEB's "just work" is policy, not technology. An RPM-based distribution with as anal a policy as Debian's would "just work" too.

        Riiight. Go have fun installing a Red Hat RPM on Mandrake or vice-versa. Or just dependency hell Red Hat puts you in with it's own packages. The package system shouldn't allow per-file dependencies, it just causes dependency hell.

        Other Debian-based distros are generally fairly anal about staying compatible with Debian. There isn't a lot in any Debian-based

        • It can get pretty hard installing Debian debs on Ubuntu. You get vague errors like "X depends on Y which will not be installed". If it has all the right versions of all the packages it needs, then why not? And why did I have to study the apt source to find out? I've installed RPM's on on a DEB based system with less trouble. The main reason packages don't work across distributions often has little to do with the package format. Often their dependencies demand higher version numbers than are really needed, o
        • Riiight. Go have fun installing a Red Hat RPM on Mandrake or vice-versa.

          I have, quite often. Your lack of packaging experience is showing here.

          The problem with installing Mandrake RPM's on a RedHat system is twofold: One, they use different versions of glibc, gcc, binutils, etc. So even if you *could* install those RPM's, they would not run. You'd get runtime failures from the dynamic loader. Two, distributions don't always name their packages (and thus, their dependencies) the same. But this is a

  • Crap! (Score:5, Insightful)

    by MoogMan ( 442253 ) on Monday May 16, 2005 @03:36PM (#12546476)
    Its stupid. I'm all for diversity, but all we hear about is "XYZ Linux has been released. It is based on ABC, which is in turn based on foobarfish." Its absolute crap. I'm sorry, but It's got to the point where the diversity is leading to a smattering of good developers being on each distribution, rather than have 5 or 6 *really good* distributions, with a load of awesome developers helping it get better.

    Sort it out!

    • Re:Crap! (Score:4, Insightful)

      by tacocat ( 527354 ) <tallison1&twmi,rr,com> on Monday May 16, 2005 @03:43PM (#12546551)

      Mod this up.

      These distros are the fragmentation of Linux that mirrors the fragmentation of Unix in the 1900's.

      Sure, variety is good. It's essential. But resources can get spread pretty thin too. It's a trade off that we have to manage.

      • These distros are the fragmentation of Linux that mirrors the fragmentation of Unix in the 1900's.

        The fragmentation of UNIX in the 1900's? Gosh, the history of UNIX is longer and more fascinating than I'd ever imagined! We're not in Kansas anymore.

    • Sort it out!

      Pay us. Otherwise, I'll keep working on the distro I like best, thanks.

    • Given that we're not based on anything, I fail to see the relevance of your comment WRT our distribution.

  • OMG, get a new name (Score:5, Insightful)

    by bill_mcgonigle ( 4333 ) * on Monday May 16, 2005 @03:41PM (#12546529) Homepage Journal
    Yeah, it's neat and Hacker-cool, but don't make me write a proposal recommending the installation of a distro pronounced "Chaos". Even if I really wanted to use it, I just couldn't.

    Does it suck that middle managers make decisions around these things without strong rationale? Yes.

    Is that the way things work? Yes.

  • I'm pretty amazed... (Score:5, Interesting)

    by wolf31o2 ( 778801 ) on Monday May 16, 2005 @03:41PM (#12546532)

    They're claiming that they're going to support a 3-5 year support lifecycle. That is unheard of for a community-based distribution! I would love to see these guys do well, and hope they really can stick to their support lifecycle.

    I always enjoy hearing about new community-based distributions. It will be a bit strange having an RPM-based distribution out there, but now we have YUM that provides the required functionality that RPM lacks, such as automatic dependency resolution, ala portage or apt.

    • It will be a bit strange having an RPM-based distribution out there, but now we have YUM that provides the required functionality that RPM lacks, such as automatic dependency resolution, ala portage or apt.

      I think you are missing the point.

      The question a lot of the initial posts are centered on is, "Why would you start yet another distro based on an already proven sub-standard packaging system?". It doesn't make any sense unless you plan on using the Chewbakka Defense.

      I would be a heck of a lot more

      • I'm actually in agreement with you. The current packaging systems out there all have their issues. Being most familiar with portage (obviously), I see lots of places where its design could be improved.

        I was mostly commenting on how RPM will be used, along with a very long support cycle. Most of the community distributions are Debian-based in some form or another, with the major exception of Gentoo. A universal packaging system would definitely improve Linux' market share and would open Linux up to a w

        • My experiences with portage have been poor. They have a not-so-user friendly method of resolving new packages, especially the config files. This is my opinion based on comparisons with Debian packages.

          About the only thing that Gentoo is really lacking in, for me, is the superb manner in which Debian manages new configuration options and their configuration scripts. In Debian, you have to make a conscious effort to over write a config file. I did this way too many times with Gentoo entirely by accident.

      • Re:I'm pretty amazed... (Score:5, Insightful)

        by ComputerSlicer23 ( 516509 ) on Monday May 16, 2005 @04:08PM (#12546876)
        What precisely is RPM sub-standard at? I've seen people talk about the beauty of .deb packages. It's my understanding that .deb is fairly isomorphic to RPM. Name something specific, or link to something specific that an RPM can't accomplish that some other packaging file format does so much better. Don't talk about dependency resolution, that's a function of apt-get, yum, or some other program.

        As a general rule the strength or weakness of the distributions packages has less to do with the package file format, and more to do with the tender loving care devoted to each package in terms of specifing all of it'd dependencies, what it obsoletes, what functionality it provides.

        There are some packages that are a pain in the ass in RPM format (RedHat's BIND/named packages jump to mind). Not having used a .deb based distro I long term, I don't know of any historically badly packaged applications from Debian.

        As a general rule, I haven't had any serious problems with RPM's in years. They work just as well as any others. I use almost exclusively from RedHat (I do use a handful from freshrpms and Dag). They work just fine. Especially since I started using yum, it's generally a command line to update my system. So stop using the "Chewbakka Offense", and actually be specific. I've seen you make several posts that just assume that it's mathematically proven that RPM's are incapable of caputing the esscense of package management. I'm unaware of it's deficiencies.

        Kirby

        • In my experiance Debs and rpms are very simmilar functionality wise , the only reason i use debian based distros is because of the maturity of apt-get and dselect , whilst yum and apt for rpm are still fairly new and don't have nearly as many respositorys.

          It would be nice to see a convergence between .deb and .rpm so that they are completly interchangable , Alien works fairly well at converting rpms to .deb and i seldom need to alter things by hand.

          I think the main confusion alot of folks have is confusin

        • As a general rule the strength or weakness of the distributions packages has less to do with the package file format, and more to do with the tender loving care devoted to each package in terms of specifing all of it'd dependencies, what it obsoletes, what functionality it provides.

          I second that. I've been using PLD Linux [pld-linux.org] for a while now. It's RPM-based, but it takes RPM to a whole new level. The package management tool, poldek, is nothing short of amazing: Regexp searches, trivial package installation,

        • It's my understanding that .deb is fairly isomorphic to RPM. Name something specific, or link to something specific that an RPM can't accomplish that some other packaging file format does so much better. Don't talk about dependency resolution, that's a function of apt-get, yum, or some other program.

          There are a few features here and there that one has and the other lacks (e.g., "Suggests" in dpkg and file-based dependencies in RPM), but the end result is analogous. DEB's are just ar archives; RPM's are c
  • I've been FC2 when it got released but I got tired of it so I got RHEL clone, CentOS. I remember back then when CentOS was hosted by the cAos community. By the way cPanel added support for cAos 2 -> cPanel [cpanel.net]?
    • CentOS isn't "better" or "worse" than cAos any more than Fedora is "better" or "worse" than RHEL. They have entirely different goals and are founded on entirely different philosophies. We are not a rebuild, nor do we claim to be. They are not a community-built made-from-scratch distribution, nor do they claim to be.

  • Why RPM Based? (Score:3, Interesting)

    by ZephyrXero ( 750822 ) <zephyrxero@[ ]oo.com ['yah' in gap]> on Monday May 16, 2005 @04:00PM (#12546753) Homepage Journal
    I'd like to see a source based distro that relied on Autopackage for it's application myself... You'd let your libraries, the kernel, userland, X, Gnome/KDE, and low level OS type software be custom compiled ala Gentoo, and then for all your software like Firefox, Gimp, Mplayer, etc you would use Autopackages. It would be quite a challenge to create, but it would be well worth it...Here [usm.edu] are a few further thoughts I've had on it.
    • Autopackage packages are incredibly badly designed [kitenet.net]. It's a bunch of shell script hackery, and there's no way to extract it other than to run all the scripts.
      • I'd rather take the risk of some "hackery" that can install on just about any distro than rely on the very flawed repository system most distros use. Besides, if the local install of autopackage were configured to coexist and work together with the system level package manager it could work very very well. Unfortunately most distros are refusing to attempt this, even though it would be for the greater good of the entire Linux community. And so the only way around this problem is for a hack...
        • The point is people *can't* make autopackage interoperate with the other packaging systems, because of the way autopackage is designed. For instance, there's no way to make Debian's alien utility unpack and install autopackage files, because there aren't any markers or specifications for what it should do to extract the contents from the autopackage. The only option is use autopackage itself, i.e. run the scripts.
  • cAos web site [caosity.org] is running on a non free [gnu.org] CMS called Rife [java.net]. Before [or after] you mod me a troll, look at the number of mature free alternatives CMS stystems out there [cmsmatrix.org].
    • Hi,

      RIFE is not a CMS but a framework to build all kinds of things, in this case a site.
      It's as free as free gets, and it can also be used with open/free JVM's or compiled with GCJ.
  • Do you have an automated installation infrastructue like kickstart (or possibly even just a reimplemented kickstart) ?
    • Nope. Cinch is the installer. I wrote it from scratch because that was easier for me to port and manage then Anaconda (not all Python is easy to maintain).

      With that said, Cinch is just an simple installer. If you require a system provisioning tool (which I think is what you are asking about), I would recommend SystemImager and/or Warewulf (while it is generally a cluster tool, it is very capable of provisioning thousands of systems in parallel). Both come with cAos-2.

      Lastly, Cinch is actually driven by a
  • I've recently looked at Vector Linux SoHo edition based on Slackware. It is good but it just has a modified install with a selection of busniness apps that Slackwere does not include. Would it not be better to offer an 'addin package manager' that just installs and correctly configures the 'missing apps' that was left out?
    I would just love a 'upgrade addon' that properly installs and configures the LAMP enviroment, say; or any number of different types of applicatins (gnuCash, OpenOffice.org with the proper

Slashdot Top Deals

Beware of Programmers who carry screwdrivers. -- Leonard Brandwein

Close