I aree on the mandrake thing, but you could say that about any OS, even theoreticaly M$ (but we know that wouldn't happen) . buying/using any software could change hands down the road and support could be lost. ----- Original Message ----- From: "D. Joe Anderson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Saturday, December 13, 2003 9:52 AM Subject: [sclug-generallist] Fedora, was BSD
> On Thu, Dec 11, 2003 at 02:29:14PM -0600, Mike Schieuer wrote: > > > > Has anyone gotten any hard facts on Fedorra? I just downloaded the iso's and > > am planning on putting it into production. I know Ted stated that he'd read > > a few things. But a ton of people look to be jumping off the Red Hat boat > > because of change... I guess I have a hard time believing that it's that > > unstable. Most of the actual functions of the OS aren't Red Hat specific. > > So are people saying that some of the GNU code is unstable in the OS??? From > > a business stand point we've been down the road of commercial unix and > > hopefully that's not a road I have to see again for a REALLY long time. Any > > vendor supported linux might as well be a SCO or Digital or HP. In responses > > to Jason's post, all distros are supported... Maybe not by one company with > > a 24x7 tech support line. But all the distros seem to keep current. If your > > looking for that 800 number to call on a Friday night at 7:30 a commercially > > boxed OS is going to be your only solution from a business perspective. And > > when you look at that pricing and support packages, I'd be willing to bet the > > ol Red Hat doesn't look to bad. And that doesn't even get into the hardware > > aspect of commercial unix. > > > > I guess I'm looking for more facts about what is wrong with Fedorra. > > The problem with Fedora is that it's neither fish nor fowl. > > http://userlinux.com/white_paper.html > > Earlier versions mentioned Fedora by name, but Perens probably > doesn't want to antagonize Redhat so much as rally the big > Gnu/Linux business community towards this effort (an effort > I've begun thinking of as "Debian Plus" or "Debian Enterprise"). > > We have Fedora ISOs on the Ames Free Unix Group ftp server, > reportedly. I plan, one of these days, to download it and give > it a try perhaps for use in those instances where we have RHL > installed. But I'm very leery. It is intended specifically NOT > to be a release-quality distribution, it's intended to be a > development branch for trying out and debugging new stuff. > Folks at ISU who are using proprietary software atop Redhat now > will probably have no choice but to switch to RHEL. > > In this discussion, it helps to acknowledge that software isn't > a static thing. All software passes through a period of > uncertain stability. Patches and new releases come out all the > time, for various reasons: To fix security or usability bugs, to > support current features on newer hardware, to introduce new > features. This process can introduce instability because an > operating system has many interlocking pieces, the code for each > of which develops at different rates, depending on external > factors like hardware development or business needs or > techniques for launching network-based attacks. In other words, > it's not a product that you buy and are done with, but a process > that you commit to participating in whenever you install the > software. > > It's all the time you and your co-workers invest in installing > and configuring and learning that you protect when you seek out > the software freedom. The purchase and maintenance price > typically pales in comparison to that. Zigzags in a company's > strategy, often due to reasons of their own, threaten that > investment. With free software, not only do you have much > greater choice in what to deploy, and when and how to deploy, > but the open development process (which might seem unappealingly > messy) actually gives you much more of a head's up in terms of > the direction things are heading, to allow you to smooth out > whatever adjustments you and your co-workers need to make. > > Free software development often is focused on releasing new code > to address things in that order--make it safe and stable first, > make it cool and shiny with what's left over. This is an > overgeneralization, but for the projects that are free from > commercial pressure, it tends to work that way more often. > Proprietary software business models have generally been built > on reversing that: Make it cool and shiny first so they can sell > new units, clean up the bugs with whatever they have left over. > This is probably why XP shipped with lots of nice new eye candy, > but also with nasty RPC bugs. Or, proprietary software > provideres offer a "maintenance" contract, where you pay them a > subscription fee in exchange for getting updates which are not > to be shared with other users. This latter is the approach > Redhat is taking with RHEL. > > One release might be perfectly OK. But going forward what > matters is the timeliness of updates, and how easy those updates > can be integrated into productions systems without breaking > them. > > Fedora is clearly modelled on the Debian unstable/testing > branch. As such, the idea is to get people to install the newer > pieces prior to release of the production version and try it > out. Then, if the bugs show themselves, the idea is for these > early adopters to find, describe, and if they can, fix them, and > communicate all this to the mothership for incorporation into > the production system. > > There is NO intention for either Fedora or Debian > unstable/testing to be suitable for production systems, although > it may indeed incidentally be the case that the combination of > software that is available at any one time might be free of > *known* security flaws or deal-breaker usability bugs. What > differentiates the Debian approach from the Redhat approach here > is that Debian's production system and the support system around > it is completely open. It remains to be seen how open RHEL will > be beyond what is stricty required by the GPL (which, > incidentally, only requires that one distribute code to your > customers, not to anyone who asks). > > It's interesting to contrast how, in the past, third-parties > have been able to distribute free software operating systems: > Both Debian and Redhat put some conditions on third-party > redistribution. In Debian's case you can distribute Debian if > you want, you can even sell it (and many people do) but if you > distribute ISOs, in order to call it "Debian" you are supposed > to distribute only the official ISO images. This is mostly a > quality control, truth-in-advertising type issue. In Redhat's > case, you can take any of the GPL'd code from it you want and do > whatever you want with it, but whatever you do, you can't call > it Redhat. Here, it's a trademark and branding issue, not just > for quality control, but to protect Redhat's place in the > market. And you know, that's fine--good luck to them. But > *I'm* not interested in being an upaid worker on behalf of > Redhat's interests. > > In Mandrake's case, the question in the not too distant past has > been whether the company would survive at all or not. If it > goes out of business, who provides your updates then? What > happens if someone buys Mandrake out, and takes it in a > different direction? That kind of question used to be a bit > more theoretical, but now that we've seen what happened with > Caldera when it became SCO, the issue is perhaps a bit more > concrete for people. > > There are several commercial distributions that are built atop > Debian. If you don't need any Redhat-specific proprietary > software, and you need professional support that you can't > provide yourself, that's the direction I would look. Perens > mentions several of them in the link. > > > --Joe >
