Slashdot Mirror

← Back to Stories (view on slashdot.org)

New Community-Run RPM-based Distribution

Posted by timothy on 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."

71 comments

  1. I wonder how it will compare to... by Anonymous Coward · · Score: 1, Interesting

    Fedora Core 4 which should be coming out soon.

  2. 3-5 year lifecycle? by mlynx · · Score: 2, Interesting

    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?

    1. Re:3-5 year lifecycle? by gmkurtzer · · Score: 1

      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.

  3. Thank God! by Anonymous Coward · · Score: 0

    I mean, just what we need! More distros!

    Move along, nothing to see here.

  4. And the point of this is? by m50d · · Score: 2, Insightful

    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?

    --
    I am trolling
    1. Re:And the point of this is? by KainX · · Score: 1

      Because RPM already won. It is the Linux standard. Period. Until that changes, arguing over package formats is simply political/religious and accomplishes nothing.

      --
      Michael Jennings | HPC Systems Engineer, Lawrence Berkeley National Lab | Author, Eterm (eterm.org)
    2. Re:And the point of this is? by m50d · · Score: 2, Interesting

      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)

      --
      I am trolling
    3. Re:And the point of this is? by KainX · · Score: 1

      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 far wider install base, including more non-Linux usage than any of the other formats; more distributions use it; more people know it; more packages are available in it. Almost any way you slice it, RPM wins.

      --
      Michael Jennings | HPC Systems Engineer, Lawrence Berkeley National Lab | Author, Eterm (eterm.org)
    4. Re:And the point of this is? by Anonymous Coward · · Score: 0

      ummm, yeah, but RPM sucks...

  5. Red Hat and Debian clone race! by ignorant_coward · · Score: 1


    Who will win?

  6. Does the world really need this? by Baloo+Ursidae · · Score: 0, Troll

    Honestly, what good comes from another distribution broken by RPM's poor package management, when .debs just work?

    --
    Help us build a better map!
    1. Re:Does the world really need this? by KainX · · Score: 1

      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

      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.

      --
      Michael Jennings | HPC Systems Engineer, Lawrence Berkeley National Lab | Author, Eterm (eterm.org)
    2. Re:Does the world really need this? by Baloo+Ursidae · · Score: 1
      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 distro that you can't use in any other Debian-based distro. If you get a .deb and you're on a Debian-derived system, odds are that .deb will Just Work(tm). You might have to apt-get a few packages, but at least everybody uses the same package names in the .deb world and can't do per-file dependencies, so it's one extra command instead of an afternoon.

      Your comment falsely assumes RPM-based distros don't think twice about forking the package standard at the drop of a hat and package maintainers don't think it's a good idea to depend on a random obscure file instead of a package, or if it is a package, the same name for the package as what everyone else calls it.

      --
      Help us build a better map!
    3. Re:Does the world really need this? by Baloo+Ursidae · · Score: 1

      Apt and yum and yast don't solve fundamental problems with the way developers treat dependencies in RPM or distros forking the package format or package naming and versioning without rhyme or reason.

      --
      Help us build a better map!
    4. Re:Does the world really need this? by dtfinch · · Score: 1

      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, or they make distribution specific assumptions.

      With both DEB and RPM based distros, I've often found it easier to just install things from the source, if the package management utilities are going to bitch about problems that don't really matter and disobey me even when I tell them to force. As technically superior as DEB's may be to RPM's, they both suck ass in an imperfect world with imperfect packages.

    5. Re:Does the world really need this? by KainX · · Score: 1

      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 matter of POLICY, not packaging, and the exact same thing can happen between two dpkg-based distributions.

      Or just dependency hell Red Hat puts you in with it's own packages.

      Not true at all. CentOS uses yum as its depsolver and has no problem managing RedHat's dependencies. Just because you fail to comprehend a system doesn't mean that system is flawed.

      The package system shouldn't allow per-file dependencies, it just causes dependency hell.

      Again, you are mistaken. When properly managed, file-level dependencies work quite well. Just look at the FreeBSD ports system.

      Other Debian-based distros are generally fairly anal about staying compatible with Debian.

      That is their choice. That does not change the fact that dpkg is vulnerable to the same things. Do not confuse "hasn't happened yet" with "can't happen."

      Your comment falsely assumes RPM-based distros don't think twice about forking the package standard at the drop of a hat

      What package standard?

      and package maintainers don't think it's a good idea to depend on a random obscure file instead of a package, or if it is a package, the same name for the package as what everyone else calls it.

      This has nothing to do with the packaging format. This is simply a red herring.

      --
      Michael Jennings | HPC Systems Engineer, Lawrence Berkeley National Lab | Author, Eterm (eterm.org)
  7. Yet Another RPM Distro by tacocat · · Score: 0, Troll

    Please don't continue to support a packaging system that has fundamental flaws to it.

    Why do you think there are so many DEB based distros out there today? Because Debian is free? So is Fedora, isn't it? Maybe it's the packaging is better than RPM.

    Why are all the RPM based distros shipping with their own cobbled version of apt-get? Maybe it's the packaging concept is better than RPM.

    Why didn't Gentoo use RPM?

    Slackware still isn't RPM based and they are doing well enough thank you.

    I'm getting a little tired of all these distros popping up every two weeks claiming to be the latest and greatest since sliced bread. I don't even thing the facade of community based means a whole lot these days. There's been a few good ones with a fundamental approach that's different, but not a lot.

    1. Re:Yet Another RPM Distro by golgotha007 · · Score: 4, Insightful

      Why do you think there are so many DEB based distros out there today? Because Debian is free? So is Fedora, isn't it? Maybe it's the packaging is better than RPM.

      Why do you think there are so many RPM based distros out there today? Because Fedora is free? So is Debian, isn't it? Maybe it's(sic) the packaging is better than DEB.

      Why are all the RPM based distros shipping with their own cobbled version of apt-get?
      How is RPM based apt-get cobbled? Please explain.

      Why didn't Gentoo use RPM?
      Gentoo didn't use DEB, either. Your point?

      Slackware still isn't RPM based and they are doing well enough thank you.
      Slackware was around long before RPM. Again, your point?

    2. Re:Yet Another RPM Distro by slashkitty · · Score: 3, Interesting

      The reason is simple, because that's where the developers are. Look at some of the most active open source APPS and you'll see that they release their product in 2 or 3 forms... RPM, GZ source and maybe a binary. I'm all for a better package manager... but I think that developers have decided that RPM is better... at least easier to distribute their apps in.

      --
      -- these are only opinions and they might not be mine.
    3. Re:Yet Another RPM Distro by slashkitty · · Score: 1

      I was responding to the question "Why do you think there are so many RPM based distros out there today?" that didn't exist in the original post.

      --
      -- these are only opinions and they might not be mine.
    4. Re:Yet Another RPM Distro by caseih · · Score: 1

      What fundemental flaws are these? Please don't bring up debian. Debian's package manager uses .deb files which are directly equivalent to rpms.

    5. Re:Yet Another RPM Distro by KainX · · Score: 1

      Please don't continue to support a packaging system that has fundamental flaws to it.

      Please don't post ridiculous unfounded statements about technology you don't comprehend. If you want to discuss RPM from a technical point of view, do so, but don't just make untrue statements with neither evidence nor explanation attached.

      Why are all the RPM based distros shipping with their own cobbled version of apt-get? Maybe it's the packaging concept is better than RPM.

      We do not use apt. You really should try to know what you're talking about before you post. You'll look a lot less silly.

      Why didn't Gentoo use RPM?

      For the same reason they didn't use DEB/dpkg: Because they wanted a source-based packaging model similar to FreeBSD's ports system. It has nothing to do with either RPM or DEB except that neither fills that role.

      Slackware still isn't RPM based and they are doing well enough thank you.

      Clearly your definition of "doing well enough" differs quite a bit from mine. :-)

      I'm getting a little tired of all these distros popping up every two weeks claiming to be the latest and greatest since sliced bread.

      We claim nothing of the sort. We fill a specific role: a community-driven, RPM-based distribution that is not controlled by a company with a vested interest in not allowing it to compete with enterprise-class distributions.

      I don't even thing the facade of community based means a whole lot these days.

      If "community-based" means nothing to you, then by all means, use something else. But there are many for whom it has a significant meaning, and we exist for them.

      --
      Michael Jennings | HPC Systems Engineer, Lawrence Berkeley National Lab | Author, Eterm (eterm.org)
    6. Re:Yet Another RPM Distro by gmkurtzer · · Score: 1
      I'm getting a little tired of all these distros popping up every two weeks claiming to be the latest and greatest since sliced bread.

      Claiming what? Actually the cAos Foundation has been very quitely doing their thing for about 2 years now. There is no hype about it, and the mentality is that we are doing this because this is what we need. If someone else can get value from it, then great! Appearantly you have the wrong idea about the developers of the cAos Foundation. I for one can tell you that we are rather modest, and just trying to share our work with the community.

      I don't even thing the facade of community based means a whole lot these days. There's been a few good ones with a fundamental approach that's different, but not a lot.

      I am unclear what you mean the "facade" of community. We have multiple developers and contributors in the project. We welcome members of the community to actually maintain packages in the distro. We are completly open in our build methods and CVS tree... Decisions are made via the package maintainers and core developers themselves. I see it as reality, not a facade.

      If you evaluate our approach, you might see that we are doing somethings that are in fact different. Like the use of RPM in a community maintained distro, also our build system, community involvement ideologies, and segreation of a core static ABI from the extended OS package maintainers.

    7. Re:Yet Another RPM Distro by dodobh · · Score: 1

      Are you saying that RPM is flawed because it doesn't automatically handle dependencies? That is like saying that deb is flawed because it doesn't handle dependencies.

      Apples and Oranges comparison.

      --
      I can throw myself at the ground, and miss.
    8. Re:Yet Another RPM Distro by synotia · · Score: 1

      I used to think that because all devs released their binaries as RPM that RPM distros were the way to go too. I've since learned that they don't bother releasing DEBs because somebody's already maintaining a DEB package for them already, and it's in the Debian/Ubuntu/* repository. Devs only release their RPMs because Redhat won't host them.

    9. Re:Yet Another RPM Distro by KainX · · Score: 1

      I don't bother releasing DEB's because I don't have a system to build them on, nor would I want one. The Debian packager for Eterm is quite competent and very responsive, but even if he weren't, I would not package Eterm for Debian myself under any circumstances. Nor would I package for Gentoo, Slackware, Ubuntu, or any other distribution I don't run.

      Developers don't usually package DEB's not because they're already packaged, but because third-party DEB's are largely useless.

      --
      Michael Jennings | HPC Systems Engineer, Lawrence Berkeley National Lab | Author, Eterm (eterm.org)
    10. Re:Yet Another RPM Distro by Anonymous Coward · · Score: 1, Insightful

      but I think that developers have decided that RPM is better... at least easier to distribute their apps in.

      I don't think it has a damn thing to do with developers deciding "RPM is better". It has a lot more to do with how popular RPM is. More people run Redhat than Debian, or DEB-based distros, and the people who run Debian (mostly) are more likely to figure out how to add an RPM than Redhat users are to add a DEB.

      Millions of Win32 developers around the world aren't developing for Windows because it's better (some are, but most have better perception than that).

    11. Re:Yet Another RPM Distro by dtfinch · · Score: 1

      Caos is made by the folks who maintain the CentOS rebuild of RHEL. If it was anyone else, I'd have to agree with you, but I think their main concern is having a Red Hat-like distro that's both fresh and supported while being a little less dependent on Red Hat than CentOS is.

      You can install apt and synaptic on RPM based distributions, and use them safely so long as the packages are built for that distribution. A lot of Red Hat users go here at some time or another. You can also install RPM's on a DEB based distribution, or use a utility called "alien" to more or less convert most RPM packages into DEB packages.

      RPM's are supposedly more flexible than they used to be. I'm sure they're still inferior to DEB's, but it doesn't matter if they work. Probably their biggest reason for choosing RPM is that they already have a ton of experience working with them.

    12. Re:Yet Another RPM Distro by davegaramond · · Score: 1

      I don't believe RPM has fundamental flaws (compared to DEB). The examples you provided are mostly anecdotal and don't explain exactly why RPM is flawed.

      Debian is more popular compared to Fedora probably more because Fedora is new, while Debian has been around for 10+ years.

    13. Re:Yet Another RPM Distro by tacocat · · Score: 1

      If the .deb packaging was inferior why is this the selection of linspire/lindows, unbuntu? They seem rather successful distros right now.

      Why is RPM picking up a packaging model from .deb? Isn't copying the highest form of flattery?

      Gentoo didn't use DEB. My point isn't a pro-debian packaging system but that the newer distros of the last several years have all been non-RPM based systems.

    14. Re:Yet Another RPM Distro by tacocat · · Score: 1

      Dependency Hell?

      I spent almost a year running SuSE. Trying to get RPM's to install, even from their own website was pretty fucking frustrating. Talking to other friends who have used deb and rpm they agree on the observations.

      It's just not as good. Try it yourself. Here's something I've done a few times over the years, see if you can do that same thing. Take a debian distribution and upgrade it from Stable to Unstable (the whole thing) and then downgrade it back to Stable (the whole thing). Mine still works just fine. Can you take an RPM distribution and upgrade/downgrade it over several years of software versions, including the kernel and libs, and back again.

      Does it still work? Can you do this without running into any dependency resolutions that lock up the process?

    15. Re:Yet Another RPM Distro by tacocat · · Score: 1

      That's a strange comment to make concerning the age of Fedora. RedHat is pretty old...

    16. Re:Yet Another RPM Distro by KainX · · Score: 1

      If the .deb packaging was inferior why is this the selection of linspire/lindows, unbuntu? They seem rather successful distros right now.

      If RPM is inferior, why is it the selection of Fedora and SuSE/Novell? They seem rather successful distros right now.

      Why is RPM picking up a packaging model from .deb? Isn't copying the highest form of flattery?

      They did no such thing. Depsolvers like apt and yum are completely SEPARATE from package managers like rpm and dpkg.

      the newer distros of the last several years have all been non-RPM based systems.

      Not on this planet. You really should get your facts straight. Count the number of new distributions that have popped up over the last 5-7 years. Then count those that use RPM. The number is significantly above 50%.

      --
      Michael Jennings | HPC Systems Engineer, Lawrence Berkeley National Lab | Author, Eterm (eterm.org)
  8. Crap! by MoogMan · · Score: 4, Insightful

    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!

    1. Re:Crap! by tacocat · · Score: 3, Insightful

      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.

    2. Re:Crap! by Nasarius · · Score: 1
      Sort it out!

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

      --
      LOAD "SIG",8,1
    3. Re:Crap! by KainX · · Score: 1

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

      --
      Michael Jennings | HPC Systems Engineer, Lawrence Berkeley National Lab | Author, Eterm (eterm.org)
    4. Re:Crap! by Adelbert · · Score: 1
      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.

  9. OMG, get a new name by bill_mcgonigle · · Score: 4, Insightful

    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.

    --
    My God, it's Full of Source!
    OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
    1. Re:OMG, get a new name by AresXP · · Score: 1

      It's pronounced see-a-o-s :)

      --
      Cheers, AresXP
    2. Re:OMG, get a new name by KainX · · Score: 1

      You can spell it out, or pronounce it however you like. (Some pronounce it as rhyming with Laos, the country.) It doesn't really matter what you call it as long as you use it. ;-)

      --
      Michael Jennings | HPC Systems Engineer, Lawrence Berkeley National Lab | Author, Eterm (eterm.org)
  10. I'm pretty amazed... by wolf31o2 · · Score: 4, Interesting

    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.

    1. Re:I'm pretty amazed... by tacocat · · Score: 2, Interesting
      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 thrilled if someone backed up a square and developed a new and improved packaging system that tries to account for the shortcomings of all the others.

    2. Re:I'm pretty amazed... by wolf31o2 · · Score: 1

      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 whole new world of people that are simply used to double clicking on "setup.exe" then hitting next a few times. I'm not sure if that's a good thing or not, but it is bound to happen one of these days... ;]

    3. Re:I'm pretty amazed... by ComputerSlicer23 · · Score: 4, Insightful
      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

    4. Re:I'm pretty amazed... by FidelCatsro · · Score: 1

      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 confusing .deb as in the packages with apt-get and dselect .

      --
      The only things certain in war are Propaganda and Death. You can never be sure which is which though
    5. Re:I'm pretty amazed... by hotpotato · · Score: 1

      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 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, extreme modularity (programs are broken down into multiple packages), consistent dependences. Best of all, it just works.

    6. Re:I'm pretty amazed... by KainX · · Score: 1

      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 cpio files with custom headers.

      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.

      To that end, all of our core packages are built inside a chroot jail built from only core packages. Thus it is guaranteed to always remain self-hosting and self-sufficient.

      Furthermore, all external packages are built in the same chroot jail and must have the dependencies noted in the spec file to build in our auto-builder. This provides a much cleaner system than other similar distributions to date have had.

      --
      Michael Jennings | HPC Systems Engineer, Lawrence Berkeley National Lab | Author, Eterm (eterm.org)
    7. Re:I'm pretty amazed... by tacocat · · Score: 1

      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. I kind of freaked out when I realized that Gentoo wasted my /etc/fstab. It was my fault, but I was still surprised that it was possible using the tools.

      Despite the ability for me to kill my system, I still think Gentoo is pretty cool. I just can't run it on any of my systems because I can't afford the configuration accidents.

  11. CentOS better then cAos by AresXP · · Score: 1

    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?

    --
    Cheers, AresXP
    1. Re:CentOS better then cAos by KainX · · Score: 1

      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.

      --
      Michael Jennings | HPC Systems Engineer, Lawrence Berkeley National Lab | Author, Eterm (eterm.org)
    2. Re:CentOS better then cAos by AresXP · · Score: 1

      It's a matter of personal opinion. RHEL fits more my needs though. cAos just isn't as mature, yet.

      --
      Cheers, AresXP
  12. Why RPM Based? by ZephyrXero · · Score: 2, Interesting

    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 are a few further thoughts I've had on it.

    --
    "A truly wise man realizes he knows nothing."
    1. Re:Why RPM Based? by Anonymous Coward · · Score: 0

      Are you aware that FreeBSD fits your requirements almost to a tee? It has a clear definition between kernel and userland (clearer now that the "system perl" thing is fixed). It has a "fork" of portage, in the original ports. Ports do not depend on packages, but actual installed files (using ldconfig to find libs, the path to find executables, and so on), and ports always builds packages.

      Frankly though, I wish you best of luck in this "only package the OS and nothing else" approach though. I use packages precisely for the resolution of giant userland environments like gnome and kde where it's important to have the myriad library version dependencies in sync lest nasty stability bugs creep in and bite you days or weeks later. I don't think I'm alone here either.

    2. Re:Why RPM Based? by gmkurtzer · · Score: 1

      I think you are very right. BSD fits very accuratly, and we have based some of our models from the success of that project (as you noticed).

      Our choice to use RPM was a major factor that drove us to build a new distro. Religion aside, people use RPM, and many developers and organizations have standardized on them. Yet there was no RPM based solutions managed by the community itself.

    3. Re:Why RPM Based? by snorklewacker · · Score: 1

      > Yet there was no RPM based solutions managed by the community itself.

      I can't think of any distribution "managed by the community itself". Redhat controls Fedora, the Gentoo devs are the gatekeepers for the portage tree, and Debian has a lengthy sponsorship process for DD's. I expect the configuration management of packages, such as synchronizing upgrades when a core dependency changes incompatibly, to be handled by experts, not foisted off on "the community".

      What exactly do you mean by "managed by the community"?

      --
      I am no longer wasting my time with slashdot
    4. Re:Why RPM Based? by KainX · · Score: 1

      So the Gentoo and Debian developers aren't part of the community? I think they'd take issue with that assertion.

      --
      Michael Jennings | HPC Systems Engineer, Lawrence Berkeley National Lab | Author, Eterm (eterm.org)
    5. Re:Why RPM Based? by snorklewacker · · Score: 1

      > So the Gentoo and Debian developers aren't part of the community? I think they'd take issue with that assertion.

      Hey mister category theory, if I started a distribution that had a thousand users, and I was one of them, but only I had commit access, would it still be a community distribution?

      I know they'd take exception to it, as would probably every single linux distributor. Even SuSE could probably claim being "community based" for simply including third party packages. I'm simply asking for an explanation of "community based", which has otherwise become an empty buzzword.

      --
      I am no longer wasting my time with slashdot
    6. Re:Why RPM Based? by gmkurtzer · · Score: 1
      What exactly do you mean by "managed by the community"?

      I see your point and you bring up a good question. Here is how I (and Webster) define that statement:

      Managed: To have under control and direction; to conduct; to guide; to administer; to treat; to handle.

      Community: Common possession or enjoyment; participation; as, a community of goods. (2) A body of people having common rights, privileges, or interests... (3) Society at large; a commonwealth or state; a body politic; the public, or people in general.

    7. Re:Why RPM Based? by KainX · · Score: 1

      Hey mister category theory

      I'm not sure what that's supposed to mean, but since I *know* you wouldn't resort to ad hominem arguments on a site like Slashdot, I'll take it as a compliment. :-)

      if I started a distribution that had a thousand users, and I was one of them, but only I had commit access, would it still be a community distribution?

      This statement makes it very clear that you know nothing about cAos and have made no effort whatsoever to investigate before prejudging. So I will leave you to your prejudice.

      I'm simply asking for an explanation of "community based"

      See other comments in this thread.

      --
      Michael Jennings | HPC Systems Engineer, Lawrence Berkeley National Lab | Author, Eterm (eterm.org)
    8. Re:Why RPM Based? by snorklewacker · · Score: 1

      > See other comments in this thread.

      Your co-worker threw dictionary definitions at me. Real fabulous communication skills. I was merely skeptical before -- now I'm prejudiced. Good luck and godspeed.

      --
      I am no longer wasting my time with slashdot
  13. Here we go ... by Anonymous Coward · · Score: 0

    Watch that operating system disintegrate into hundreds of half-arsed distributions ...

  14. Site runs on Java by AnuradhaRatnaweera · · Score: 1

    cAos web site is running on a non free CMS called Rife. Before [or after] you mod me a troll, look at the number of mature free alternatives CMS stystems out there.

    1. Re:Site runs on Java by DataDevil · · Score: 1

      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.

      --
      -- signed for your pleasure --
  15. Kickstart ? by drsmithy · · Score: 1

    Do you have an automated installation infrastructue like kickstart (or possibly even just a reimplemented kickstart) ?

    1. Re:Kickstart ? by gmkurtzer · · Score: 1

      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 series of ASH scripts. It is very easy to modify and customize.

  16. Autopackage is an incredibly bad idea by metamatic · · Score: 1

    Autopackage packages are incredibly badly designed. It's a bunch of shell script hackery, and there's no way to extract it other than to run all the scripts.

    --
    GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
    1. Re:Autopackage is an incredibly bad idea by ZephyrXero · · Score: 1

      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...

      --
      "A truly wise man realizes he knows nothing."
    2. Re:Autopackage is an incredibly bad idea by metamatic · · Score: 1

      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.

      --
      GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
  17. Another way? by zenray · · Score: 1

    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 Java runtime). Slackware could then be cut back even more of its default install and get back to one CD and let the end user select 'the rest of the confiuration package' that would truely make for a unique configuration.

    --
    zenray