I don't reply too much as I don't consider myself on you guys level and even though I've been involved with the OS for quite a while still consider myself a novice, I agree with what's been said and would like to point out and defiantly agree with Kuecker. And add that the same could be said of hardware also, anyone try to find a driver for some old sound cards or modems lately? The only think that appears constant is change. Rob
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Daniel Kuecker Sent: Saturday, December 13, 2003 10:10 AM To: [EMAIL PROTECTED] Subject: Re: [sclug-generallist] Fedora, was BSD 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 >
