[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Mandrake
On Friday 4 May 2001 19:07, Donovan Rebbechi wrote:
> On Fri, 4 May 2001, Darin Lang wrote:
> > I installed the Mandrake intsallation as you suggested, Jean. It was easy
>
> Ditto
>
> > and it worked much better than Slackware. It had a graphical drive
> > farmatter
>
> Ditto
>
> > instead of a prompt which made it much clearer what was going on. It
> > easily configured my printer, my keyboard(Dvorak), X windows and it works
> > excellent for the first time. It installed the dual boot LILO, mysql,
> > apache, php, perl all right off the bat. I found it to be a smooth clear
> > and simple
>
> I had trouble getting printers working. Ended up doing it the old
> fashioned way.
>
> I like the way it lets you pick security levels. Higher levels are
> inconvenient for home users, but useful for critical servers. Home users
> can pick the "regular" level.
>
This one of the things I dislike in Mandrake: it is marketing driven. I think
it is a nice idea to have tunable security levels (but in 7.2 they allowed no
passwords at all and that is IMHO very dangerous since a rogue program could
exploit this), but some of the "securities" like patching the kernel for not
allowing execution in the stack quite simply provide zero protection: they
are there just for the marketing effect.
> > interface, except that there were alot of unneccessary things included I
> > am sure. But I whittled it down as best as I could to just what i needed.
> > All
>
> One of the nice things about the install is that you can tell it to only
> install xx% of the packages and it selects a subset of that available
> based on prioritisation.
That is one of the reasons I want Indy to use the Mandrake installer: we
don't give away RedHat compatibility (most software is not tested against
Mandrake) but we get a far better installer.
>
> > It did not configure the network properly, I have two NIC cards and
> > it hasn't been able to configure either one and I can no longer connect
> > to the internet or intranet.
>
> No problem with me, though I only configured machines with one network
> card.
>
> > I still do not have sound either, and I can't figure out how to
> > configure that either.
>
> Might be hardware compatibility.
>
> > to start with as a base. I wonder what it lacks though that Indy needs to
> > remedy. You know more about that than I, I haven't a clue really, but it
>
> IMO including Redhat's rogue gcc release in 8.0 was a HUGE mistake.
I disagree and while we are at it I will recall the whole story:
The gcc people had decided to go from 2.95 to 3.0 in one stride. RedHat
felt that this would Linux people with an unsatisfactory compiler for far too
much time: gcc 2.95 is not standards compliant for C++ (and that makes
difficult to port code from other platforms), the code it generates is not
so great (better than Microsoft's compiler but other x86 compilers beat it)
and this places Linux developpers at a disadvantage, it does not support
Itanium, on many RISC platforms it quite simply sucks (FP code on Apha is two
or three times slower than code produced by Compaq's compiler).
Since apparently the gcc people didn't want to change their plans RedHat t(or
more exactly their Cygnus subsidiary) took one of the snapshots and went into
bug hunting while the gcc people continued development.
I believe in user 'right of rebellion' when developers don't listen to their
needs so RedHat fork was IMHO legitimate but since this compiler broke binary
compatibility I think t was RedHat duty to try to coordinate with other
distros.
Also RedHat didn't tell they would be using that 2.96 compiler (and why) so
few people really tested it during the pre-7.0 months, many bugs could have
been ironed out if Redhat had told about its plans.
Another blunder on RedHat's part was that when developping glibc 2.2 (largely
a Cygnus work) they used code who could only be compiled by gcc 2.96 and that
means they couldn't go back to egcs or gcc 2.95 if gcc 2.96 was not ready by
7.0 time.
And it wasn't. Calling it Alpha as some people did was certainly unfair (it
was Alpha plus six months of bug hunting) but there was much code around who
made it crash so it should not have been included in 7.0. However reports
of bad code generation have been very rare (older gccs had their share of
known bugs in this area)
There were also other problems: since teh compiler had been labelled Alpha
and RedHat did not even issue a PR to justify their action many people
faulted the compiler when it rejected code who was accepted by other
compilers: in fact gcc 2.96 is more strict (this is the standard) than older
gccs so problem was in the code. It also failed to compile the kernel but
the kernel people told problem was on kernel side (older compilers accepted
cpode who was not entirely correct, Linus position against gcc 2.96 was not
on kernel grounds).
The gcc people also issued a communique telling they didn't want to hear
about gcc 2.96 since it wasn't their own. They also told gcc 3.0 would be
ready by end 2000 and since this was just three months later I simply cannot
believe they were sincere: gcc 3.0 is still not here and by the traffic in
the gcc list I doubt it will be ready before end June, then there will be
holidays so we will be lucky if gcc 3.0 is ready by september that is one
year after their communique not three months.
For gcc 2.96 first of all it passes the testsuite far better than gcc 2.95
(the number of tests it fails is about one tenth of those failed by gcc 2.95
and this after accounting for features who are only supported by gcc 2.96),
it generates faster code (5 to 10% with -O2, more if you use the cpu flas
since it has more CPU tuning, still more if you use optimization flags who
are not available to gcc 2.95). Also the compiler shipped in RedHat 7.1 and
Mandrake 8.0 is NOT the crash-prone one in RH 7.0: it has had six months more
of debugging and there has been months since I have crashed gcc 2.96 last
time).
JFM
One of the things RedHat did while developping 7.0 was