On Thu, 01 Jun 2000, you wrote:
> Mandrake & Users,
> For the past 4 releases of Mandrake I have installed and used the
> distrobution. I have VERY standard hardware ( P2-450, ASUS P2B, PS2 mouse,
> no USB devices, ISA SB AWE 64, 3COM 905B, ATA/33 Seagate 6gig hard drive,
> TNT2 video ), and never have any hard ware issues with Linux distros in
> general. Every time I've installed a Mandrake distro ( 5.x, 6.0,6.1,7.0 ) I
> always do a full install and try and keep the install as default as
> possible ( to try and avoid "special" unaccounted for situations ). After
> installation I've always within 10 minutes encountered segfaults of utility
> software, or misconfigurations, or endless lists of errors being printed
> out to the console during runtime of a application. This is always kept me
> out of bed with Mandrake and in the arms of other distros like Redhat (
> which I have no troubles with ). HOWEVER, I LOVE the user friendlyness of
> mandrake along with all the kick ass utilities that help make the distro so
> robust.
>
> I got into a discussion with a friend the other day about Mandrake, and he
> as well as the LUG he goes to have an ongoing cliched joke about Mandrake
> and stability. I think that is a horrible, but seemingly at the moment
> deserved description ( minus 7.1 betas, I haven't tried them, but from what
> I hear people have their fair shares of complaints ). One thing that I see
> as the cause to this is the incredibly quick development cycle mandrake
> goes through. 7.1, as far as I've known, is the longest devel cycle I've
> seen mandrake take before releasing, and its encouraging to me and will
> probably have me trying 7.1 when it comes out.
>
> This is not a flame, but more of a request or a plead, however you watn to
> see it. I really want to use mandrake, but the issues noted above keep me
> from it. I really feel a longer devel cycle, EVEN if you are just sitting
> on the product and releasing betas, gives you an incredibly stable product
> just through the process of elimination. I kinda of equate the difference
> of what long cycle of betas can do to the Quake3 release cycle and the
> Ultima 9 release cycle.
>
> Quake3 had 3 ( I think ) "Test" releases before even concocting a demo just
> to make sure the technology was working and compatable on many different
> machines. Ultima9 pushed their product out the door about 4 months early
> due to EA's funding, but that's not the point ) and look where it got
> them. The game was simply unplayable on about 1/2 of its user's machines. I
> urge you to take a look at the early message boards related to Ultima, you
> had people tearing their hair out, flaming Origin, threatening to class
> action suit them AGAIN, etc.
>
> But I digress, it was ugly, and could have been totally avoided. What are
> the developer's thoughts on the shorter devel cycle of Mandrake? Is this by
> choice, or is it out of excitment and want to be "ahead of the curve" that
> the releases are made?
>
> Best wishes,
>
> Riyad Kalla
> Java Programmer
> Game Enthusiast
>
> P.S.> Please do not waste time flaming, but do take time to discuss. I'm
> really not interesting if "Mandrake is the best distro ever and your just a
> #$%@*(ing idiot!", that helps no one.
Hmmm, I am astounded that your chipset and the Seagate allowed you to even
install 6.1 or 7.0. Some chipsets interact strangely with the Seagate (in
particular but also with the WD) under the more stringent requirements for
being near the timing specifications imposed by Pentium Code (as opposed to
386 code).
Dare I venture to guess that one of your problems with 7.0 was a "lost
interrupt"?
Well, that is not really relevant. I wanted to thank you for phrasing this
in a positive and supportive manner. Some of the stability problems we both
see are that hardware manufacturers are building cheap and assuming that
everyone will stay with the timings of 386 code forever, but some are
probably attributable to the aggressive leading/bleeding edge features of
Mandrake and the quick development cycle. What Mandrake needs from us is the
feedback on how their cycle is working out without implying that their
process is invalid or BAD. They are obviously experimenting with process
along with everything else, and that is how you produce quality in the long
run. Those who stay with the "safe and sane" because "it has always been
done that way" are not likely to achieve as much as Mandrakesoft will.
Most software distributors for linux are not changing the SYSTEM that
develops the software so the best they can hope for is what the system will
produce. I haven't seen a distro that is bug-free, by any means. I stay
away from RH and Caldera because I cannot work on them as easily as I can
Mandrake. (And more of the Mandrake bugs are misconfigurations and minor
packaging errors than not, such as default XF86Config settings that are
blatantly aggressive for performance.) Anyway, my point is, if you want a
better or superior product every time, you will have to change the system
that produces it. What you get out of a system is subject to variation, but
it will be in what one could call the "process capability" of the system. If
you want super-stable software for a reasonable investment, find a system
that tends to build it right the first time, because inspection is a very
poor method of quality control. To expect quality software out of the
debugging process is similar to expecting quality binaries out of a closed
source development. Neither system has that capability. Would one ask a cow
to provide wine from her udder?
In fact, those who stay with the "safe and sane" all the time tend to remind
me of the IT managers who buy Microsoft or who bought IBM 20 years ago. No
one ever got fired doing that. But no one who doesn't take risks is not
likely to make a breakthrough either.
And I am not one who believes that the very process by which we develop
software is a sacred cow. Some people can give you a flow chart of the
process. Others will ask, "What's a flow chart?" And some good software
comes out of both. The process Mandrake uses has a number of elements
different from the classic "right" way to do things, and some people are
critical for that reason. I am content to provide feedback on the results
and let them discover what works best for their development model. It
appears that you are doing the same in your own way, but you want to work
more with the system rather than upon it.
Civileme
