Hi Domingos and Brad, [...] > So, it could be considered an enterprise linux distro (without > commercial support, that is), updating packages and fixing stuff only > when RedHat does the same on RHEL. This means that all policies > regarding this distro (packaging, updating, bug fixes and security bug > fixes) takes in account that the product is targeted to an "enterprise > client" (thats the most important phrase in my message). > > For a long time, "enterprise clients" asked for an enterprise linux > (and there where none). RedHat was the first to fix this issue, building > an enterprise version of its Linux (called RHEL). By enterprise, they Well, that is simply not true. I know that many people think Linux = Red Hat (or Debian) and do not know much about other distributions. SUSE Linux Enterprise Server 7, released in October 2001, has been the first enterprise Linux on the market. Red Hat Enterprise Linux 2.1 came out in March 2002. I just want to mention that, so no flame wars please. :-) > meant an operational system which was stable, scalable, well supported > and with a distant EOL date. So, the paradigm for this kind of distro is > way different from the ones end users and small companies use. We can > sum the basic changes in a few lines: > > - The life cicle of an enterprise distro is way longer then a normal > distro. To get the picture, just compare the EOL date of any Fedora Core > version, with any version of Solaris, or even better, Windows. For the > matter, Windows 98 finally ended its "cicle of life" (EOL) this month. > RHEL usually have a EOL date of 5 years from the date it was launched > (and even more, if the marked asks for it). > > - The enterprise distro is not meant to be bleeding edge. Alas, no > software is upgraded to the latest version. In truth, developers do the > most they can to stay using the same version of any package or lib for > the lifecycle of the product. We can break this statement in two parts: > > - package updates are made only when security bug fixed are found. > Also, the package is not updated to a newer version, but instead, the > fix is backported to the current version. If you take a look at RHEL > 4.x, you'll see that it contains thousands of packages. To stay "feature > freeze", you must guarantee that all packages are 100% compatible betwen > updates (try to do an automatic update of squid 2.5-stable6 to squid > 2.6-stable1, and see if works at all). > > - developers take much more care about updates, and usually, stay away > from "functionality" fixes (unless the bug makes the software useless). > So, the number of package updates ir far greater on end user distros, > when comparing to enterprise distros. Also, those updates are usually > delivered in batches (think of Microsoft service packs. RedHat does the > same with RHEL). I just can second all your other statements. At the end, it's simply a question of man power and money. The vendors have to decide what exactly they can support and maintain. So they (normally) concentrate only on one version of an application like Squid. So, if you rely on support for an application from the vendor of your enterprise Linux, you should stay with the version they provide. They won't support any other version of the software. If you want the latest (stable) technology, compile it yourself, create an RPM package, install it and get your support either from the community or an independent Linux company around the corner. Regards, Peter -- Peter Albrecht, Novell Training Services, peter.albrecht@xxxxxxxxxx
