I enjoyed your point of view. Thank you for sharing it.
Matthew Lee [EMAIL PROTECTED] -----Original Message----- From: D. Joe Anderson [mailto:[EMAIL PROTECTED] Sent: Saturday, December 13, 2003 9:52 AM To: [EMAIL PROTECTED] 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
