Linux-Misc Digest #864, Volume #27 Tue, 15 May 01 09:13:01 EDT
Contents:
Re: System.map and multiple kernel versions. (Dave Uhring)
Re: Y2.0017115K bug (John Hasler)
Re: configuring sound on debian stable ("Peter T. Breuer")
Re: Utility for parsing RPM database? ([EMAIL PROTECTED])
Re: eth0 configuration problem ("Peet Grobler")
Re: Compile GCC 2.95.3 in RedHat 7.0 failed !! (Christian Rose)
SoundForge for Linux (Reiner Griess)
Re: KDE WM: no virtual desktop? ("Peter T. Breuer")
Re: My Linux Experience (Steve)
Re: Y2.0017115K bug (SpacemanSpiff)
Re: System.map and multiple kernel versions. ("Wayne Osborn")
Re: Compile GCC 2.95.3 in RedHat 7.0 failed !! (Christian Rose)
----------------------------------------------------------------------------
From: Dave Uhring <[EMAIL PROTECTED]>
Subject: Re: System.map and multiple kernel versions.
Date: Tue, 15 May 2001 05:11:57 -0500
Wayne Osborn wrote:
> Just curious as to the requirement for /boot/system.map when you have
> multiple kernel versions setup in lilo.
>
> For instance, if I upgrade my 2.2.16 kernel to 2.4.4 and want the option
> to support both with lilo, what system.map should I have in /boot ?
>
> Thanks in advance, and a big thanks to all in this NG and other Linux
> NG's for that matter that have taught me so much.
>
vmlinuz-2.2.16 -> System.map-2.2.16
vmlinuz-2.4.4 -> System.map-2.4.4
------------------------------
From: John Hasler <[EMAIL PROTECTED]>
Subject: Re: Y2.0017115K bug
Date: Tue, 15 May 2001 03:17:46 GMT
I wrote:
> Go back and read the item again, this time for comprehension. Pay
> particular attention to the word "timestamp".
Scott Weber writes:
> And the only place it appears is where it says 'overflow'.
Here is the item in question, copied from your article at the top of the
thread:
>
> I found this in comp.risks. I deleted the author's name, so that
> he won't get any extra spam.
>
> Date: Mon, 07 May 2001 01:46:08 +1200
> Subject: Potential timestamp overflow on 9 Sep 2001
>
> In case no-one else has noticed ...
>
> On 9 Sep 2001, at 1:46:40 UTC, the Unix time_t value (the
> number of seconds since the 1st of January 1970 0:0:0 UTC)
> ticks over from 999999999 to 1000000000, thereby moving from
> being a nine digit decimal number (as it has been since 1973)
> to a ten-digit number.
>
> Anyone storing decimal time_t values into a nine-digit field
> is going to have an interesting problem on that date.
>
> Anyone know of applications that are known or not known to be
> suceptible to this problem?
Scott Weber writes:
> Implying time_t would overflow, not apps.
Note that it clearly says "Potential timestamp overflow".
^^^^^^^^^
> It clearly says it moves from a 9 digit decimal to a 10 digit
> decimal. time_t is not a decimal.
time_t is an integer which will, in its decimal representation, behave as
stated. The author clearly (and, evidently, erronously), thought that he
did not need to spell this out.
> In the next paragraph it tries to clear it up, saying apps which store
> time_t in decimal form may have problems. I don't know wnyone who wold
> do that.
I find it quite plausible that a programmer in need of a timestamp might
take the easy way out and just print time_t.
> Now, try to be a little light hearted about this stuff.
Hey. _Somebody's_ got to be the curmudgeon around here, and you kids are
just too young to handle the job.
--
John Hasler
[EMAIL PROTECTED]
Dancing Horse Hill
Elmwood, Wisconsin
------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Subject: Re: configuring sound on debian stable
Date: Tue, 15 May 2001 12:24:42 +0200
wroot <[EMAIL PROTECTED]> wrote:
> OK, I have only 2 PnP devices. LT Win Modem is not used. This leaves the
Whether it is used or not, it is connected to the machine by wires, and
hence connected to an interrupt. You MUST configure it, or the effects
will be unforseeable and possible disastrous.
> sound card only, so there's no interference with other devices. Can I give
> it any IRQ? Can I give it the same IRQ that I had on Redhat? If yes, then
That is the whole idea of PnP. You have to configure it as you want. or let
random factors decide for you.
> why doesn't it work. In fact, I tried all IRQs allowable by the card. Same
> error.
> I don't know what else to try. pnpdump gives the same output as pnpdump -c.
> I have no idea as to how to interprete its output though.
Why not? It looks perfectly plain to me! Each card has an entry, and
that entry consists of several alternate stanzas, each describing a
configuration of the card. You uncomment the stanza you want and
uncomment the ACT Y at the end of the card entry. Then run isapnp
over the config. Hardly a brainteaser.
> Doing | grep -i cs4232 gives nothing. What is the
> significance of doing isapnp /etc/isapnp.conf and what should that file
man isapnp.
> look like? Should I edit it after pnpdump -c > /etc/isapnp.conf ?
You are making easy things sound difficult. Of course you should edit
it. That's what it's for.
>>>> Indeed - take isapnp detection out of the kernel. Use pnpdump and
>>>> isapnp to configure the isa hardware to the irq and ioport
>>>> you desire.
> Strangely, dmesg didn't change after I took PnP support out of the kernel
> (???) It still says "isapnp: ...."
Then you are probably still loading it as a module, or else you forgot
to change the loader map (using /sbin/lilo).
Peter
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Utility for parsing RPM database?
Date: 15 May 2001 18:42:09 +0800
>>>>> "Chris" == Chris Divine <[EMAIL PROTECTED]> writes:
Chris> This works the way I want! Two simple commands.
Chris> rpm -qa --queryformat '%{NAME}, Version: %{VERSION}-%{RELEASE}\n' >
Chris> rpms.txt sort -o rpms.sorted rpms.txt
Chris> Then I just print "rpms.sorted" and it looks the way I want
Chris> it to.
Chris> Now I just need to learn how to put both commands in one
Chris> "batch file" (sorry, too much old DOS days) that I can run
Chris> by issuing one simple command.
If you're from the old DOS days, you may know that the two commands
can be turned into a one-liner using pipes ('|'):
rpm -qa --queryformat '...' | sort > rpms.sorted
That gets rid of the temp file, and is more efficient both on disk
space and processing time. (Well... DOS did implement pipe using temp
files, but that's because DOS is not clever enough to support multiple
concurrent processes. That's very inefficient. UNIX, however, does
it efficiently with a small memory buffer and concurrent processes.)
To put commands into a "batch file", which is called "shell script",
use an editor to create a text file containing the commands. (Or use
"cat > myfile" which is the same as the DOS idiom "copy con myfile".
For one-liners, "echo 'blah blah blah' > myfile" may be even quicker.)
You can then run it with:
/bin/sh myfile
To make it work like executable files, do a:
chmod +x myfile
And you'll be able to run it like a command:
./myfile
(You an still run in with: /bin/sh myfile)
BTW, UNIX provides many Shell programs for you to choose from. So,
you may write a script using the powerful features of bash (Bourne
Again Shell) and then invoke your script with:
/bin/bash myfile
Now, what happens if you run it with the command: ./myfile ?
Will /bin/sh or /bin/bash be used?
Answer: /bin/sh is the default. However, if the OS finds that the
file starts with a line "#/bin/bash", it will use /bin/bash instead.
Similar for other shells. Even with sh, it is a good practice to
write "#/bin/sh" as the first line of a shell script.
Chris> Then later develop a (maybe
Chris> java) GUI to run it and display the output. My first "idea"
Chris> for an open-source project!
If the GUI is very simple, Tcl/Tk may suit the job better. Tcl/Tk is
cross platform, which may not be a concern for your project. But it's
much easier to issue shell commands and manipulate with the processes
in Tcl/Tk than with Java. However, Tcl is an ugly language IMO, and
Perl/Tk appears to be cleaner.
--
Lee Sau Dan ���u��(Big5) ~{@nJX6X~}(HZ)
.----------------------------------------------------------------------------.
| e-mail: [EMAIL PROTECTED] http://www.csis.hku.hk/~sdlee |
`----------------------------------------------------------------------------'
------------------------------
From: "Peet Grobler" <[EMAIL PROTECTED]>
Subject: Re: eth0 configuration problem
Date: Tue, 15 May 2001 13:04:45 +0200
Depends. If you have a ISA RTL8139, use the ISA NE1000/2000 Module (ne.o).
If PCI, use PCI NE2000 Module (pci_ne2k iirc).
This should work, I've got an RTL8029, and using the ne.o module
successfully.
Karel Claessens wrote in message
<3b00dbca$0$43055$[EMAIL PROTECTED]>...
>Hello,
>
>I guess I will need the help of more experienced LINUX fans...
>
>I'm new to LINUX and had a RedHat 5.2 CD lying around for some time.
>So I went through the install process without problems (Kernel 2.2.14-5.0).
>
>Everything worked, including eth0 which was recognized as a RTL8139 (the
>same as in Windows PnP).
>
>I then did a recompile of a 'new' kernel, not too far away from the
>original since this was just a first try and I didn't want too much
>differences to start with.
>I installed 2.2.16 and my kernel size shrunk by 2/3th of the original size.
>
>Configuring the kernel I noticed that I couldn't select the RTL8139 module.
>In xconfig I saw it was present and I could select the help, but the entry
>was and remained shaded (not selectable).
>I added the entry (CONFIG_RTL8139=y) manually to the .CONFIG and compiled.
>I see the module being processed, but after booting the card isn't found
>anymore.
>
>Maybe I'm missing something, but I don't know what I'm doing wrong...
>I think it is strange that I'm not able to select the entry during the
>config... Why?
>
>
>Thanks for any help,
>Karel Claessens
>([EMAIL PROTECTED])
>
>
------------------------------
From: Christian Rose <[EMAIL PROTECTED]>
Subject: Re: Compile GCC 2.95.3 in RedHat 7.0 failed !!
Date: Tue, 15 May 2001 13:32:05 +0200
"Peter T. Breuer" wrote:
> >> >Not an answer to your real question, but why would you want to replace
> >> >gcc 2.96 with 2.95.3?
> >>
> >> GCC 2.96 was an experimental, not-for-production-use version of the GCC
> >> compiler.
>
> > It was not experimental and it was certainly for production use. I think
>
> It certainly was experimental.
How come? It's a tested and reliable compiler.
> It was a not-for-publication development version.
I think we are talking about different things. I'm talking about the
released gcc 2.96 (or gcc 2.96-rh or whatever you want to call it) and
you are talking about gcc cvs. Those are different things. Only if you
choose to completely ignore the fact that gcc 2.96 was tested and fixed
and made a reliable compiler before being released, those two versions
are equal. Please don't ignore such facts (although you do that all the
time anyway).
> > it would be very stupid otherwise to base a Linux distribution on it.
>
> Took the words out of my mouth :-(. But no, they apparently had their
> reasons. The only technical reason I have heard mentioned is "ia64
> support".
Not only IA-64. Basically every non-x86 platform, like Alpha for
example. And also C++.
> The commercial reasons are never mentioned but seem more obvious to me.
What commercial reasons? Releasing a distro with a compiler that is up
to par with reality, with regards to optimization, non-x86 support and
C++?
> >> RedHat jumped the gun by releasing this compiler into their
> >> distribution (they provide the real 2.95 compiler as 'kgcc' (kernel GCC) IIRC),
> >> and have received lots of bad press about it.
>
> > Umm, no. kgcc is based on egcs 1.1.2, in other words a really old
>
> Really old? I am happily compiling everything in sight with 2.7.3. For
> cheap thrills I use 2.8.1.
What I was saying was that egcs 1.1.2 is really old! Please read what I
wrote.
> > compiler that kernel 2.2 likes to be compiled with. That is its only
>
> Huh! A compiler is a device for producing machine code, nothing more
> and nothing less. If it works it works. In a kernel, errors are far
> more important (not to have) than features, so one doesn't use "new" or
> experimental compilers.
If the kernel is nit-picky when compiling and depend on old compiler
bugs, then it's broken. But it's still an important piece of software,
so what do you do? You include a compiler that it likes to be compiled
with.
If the problem wasn't broken code in kernel 2.2, why has kernel 2.4 been
fixed and works without problem then?
> > purpose. Kernel 2.4 has been fixed to work with modern compilers, so
>
> Oh yea?
Yes. Are you saying it hasn't? Please come with some evidence then,
because kernel 2.4 compiles just nicely with gcc 2.96, while kernel 2.2
doesn't.
> > compiling kernel 2.4 with gcc 2.96 works just fine (I tried 2.4.4 with
> > it last week).
>
> That you can't see the problem doesn't mean that it isn't there! Please
> place your lifework on that machine, throw away the backups, and start
> compiling kernels while running bonnie and cpuburn simultaneously.
This just shows how completely ignorant you are to the actual situation.
When the actual situation differs from your world view, dismiss it with
some invented argument, no matter how blatant lie it is. Well, let me
explain how wrong you are here.
As you said, the compiler is just a tool. If it works, it works.
Secondly, my machine has never run a minute without dnetc burning cpu
cycles, and when I tried compiling the kernel, I was running xmms and
burning a cd too. I do that all the time and have done it lots of times
since. So your invented argument that I wasn't loading the machine goes
nicely out of the window, because that is simply not true.
Third, most linux distributions are made self-hosted. That means that
they are compiled from the sources that are shipped with the
distribution, and compiled with the tools available with the
distribution. Have you ever considered the possibility that the kernel,
as shipped with RH 7.1, is compiled using the perfectly working gcc 2.96
compiler? In that case your argument is also blown away, because then
thousands of people all around the world are already using this
perfectly working configuration!
> > And yes, they have recieved lots of bad press for this, but a lot of
> > unwarranted bad press, IMHO.
>
> Oh, and what is unwarranted about it? Doing a stupid antisocial thing
> sounds like it warrants a lambasting to me!
Please explain what is antisocial about making a working compiler, and
making the patches available.
> >> >that sounds backwards to me. They're both free
> >> >software, and gcc 2.96 is among other things more standards-compliant.
> >>
> >> Nope.
>
> > Uh, what do you mean by "nope"? Could you point out which examples on
> > http://www.bero.org/gcc296.html make gcc 2.96 less standards-compliant?
>
> Presumably the fact that it doesn't produce standard code!
What is "standard code"? Another newly invented term?
This may be new to you, but a compiler does not normally produce code,
it produces machine code. Code should follow standards (as specified by
the rules of the language), the only rules that machine code has to
follow is that imposed by the target machine platform.
> And in what way should anyone care?
Maybe you don't care about standards, but I do. "Standards" as in the
sense "things that are specified to be so and so", as in the proper
definition of the word.
> > I don't know of any, on the contrary! gcc 2.96 *is* more standards-compliant.
>
> Fantastic. If it were so, I wouldn't care.
Then don't, because that's the way it is.
> gcc 2.7.3 compiles ansi C code just fine.
As if Ansi was the latest C standard. It's not. Ever heard of ISO C99
and ISO C++ 98?
Christian
------------------------------
From: [EMAIL PROTECTED] (Reiner Griess)
Subject: SoundForge for Linux
Date: 15 May 2001 11:32:50 GMT
Reply-To: [EMAIL PROTECTED]
Hi there!
There is no really good audio software for Linux,
such as SoundForge, available. Only a few bad
tools.
RIGHT?
reiner
------------------------------
From: "Peter T. Breuer" <[EMAIL PROTECTED]>
Subject: Re: KDE WM: no virtual desktop?
Date: Tue, 15 May 2001 13:11:35 +0200
Grant Edwards <[EMAIL PROTECTED]> wrote:
> I'd bet that the "v" in olvwm stands for "virtual", and I'd be surprised if
> the others you mentioned don't provide virtual desktops as well (except
> perhaps for twm -- I don't remember if it had a virtual desktop).
No it didn't. That was the "v" in tvtwm (or whatever was the twm++ that
came out after it).
Peter
------------------------------
From: [EMAIL PROTECTED] (Steve)
Subject: Re: My Linux Experience
Date: 15 May 2001 11:58:15 GMT
Reply-To: [EMAIL PROTECTED]
On 15 May 2001 03:51:59 GMT, Robert Heller wrote:
>*I* have no problems with the Epson Colour Stylus 600 I bought from my
>mom. Set up a ghostscript filter with the uniprint driver. I in fact
>have two print queues: color (1440x720DpI) and fastcolor (720x720DpI).
>(RH 5.2, GS 5.10 (1998-12-17))
Mine was the 300, on RH6.2.
>I don't use Star Office -- I use LaTeX and things work just fine.
I'll look into LaTeX, I always wanted to learn about it but never
got round ot it, this might just give me the push I need.
--
Cheers
Steve email mailto:[EMAIL PROTECTED]
%HAV-A-NICEDAY Error not enough coffee 0 pps.
web http://www.zeropps.uklinux.net/
or http://start.at/zero-pps
12:04pm up 102 days, 12:51, 2 users, load average: 1.11, 1.09, 1.03
------------------------------
From: [EMAIL PROTECTED] (SpacemanSpiff)
Subject: Re: Y2.0017115K bug
Date: Tue, 15 May 2001 12:11:12 GMT
On Tue, 15 May 2001 03:17:46 GMT, John Hasler <[EMAIL PROTECTED]> wrote:
>> Now, try to be a little light hearted about this stuff.
>
>Hey. _Somebody's_ got to be the curmudgeon around here, and you kids are
>just too young to handle the job.
>--
>John Hasler
>[EMAIL PROTECTED]
>Dancing Horse Hill
>Elmwood, Wisconsin
Daddy, what do those 0's and 1' mean?
HEX???!!! Someone put HEX in the computer???!!!
Now you have to call a priest!!
"Don't worry, base 8 is just like base 10, if your missing
two fingers!"
-Tom Leherer
"...all we had were ones and zeros. Somethimes we didn't even
have ones. I wrote an entire database program using only zeros"
"You had zeros? We had to use the letter 'O' "
-Dilbert
------------------------------
From: "Wayne Osborn" <[EMAIL PROTECTED]>
Subject: Re: System.map and multiple kernel versions.
Date: Tue, 15 May 2001 20:20:12 +0800
In article <[EMAIL PROTECTED]>, "Dave Uhring"
<[EMAIL PROTECTED]> wrote:
> Wayne Osborn wrote:
>
>> Just curious as to the requirement for /boot/system.map when you have
>> multiple kernel versions setup in lilo.
>>
>> For instance, if I upgrade my 2.2.16 kernel to 2.4.4 and want the
>> option to support both with lilo, what system.map should I have in
>> /boot ?
>>
>> Thanks in advance, and a big thanks to all in this NG and other Linux
>> NG's for that matter that have taught me so much.
>>
>>
> vmlinuz-2.2.16 -> System.map-2.2.16
> vmlinuz-2.4.4 -> System.map-2.4.4
>
Alright, so the symbolic link System.map is setup by...???
ie. does System.map always point to the map associated with the running
kernel?
Thanks.
--
Wayne A. Osborn, SCADA Engineer.[dnar AT iinet DOT net DOT au]
Registered Linux User #212818. [2.2.16-22-Win4Lin-686] [i686]
8:10pm up 8:06, 3 users, load average: 2.04, 2.16, 2.26
...Due to lack of disk space, this fortune database has been discontinued.
------------------------------
From: Christian Rose <[EMAIL PROTECTED]>
Subject: Re: Compile GCC 2.95.3 in RedHat 7.0 failed !!
Date: Tue, 15 May 2001 14:29:09 +0200
"Peter T. Breuer" wrote:
> >> > Not an answer to your real question, but why would you want to replace
> >> > gcc 2.96 with 2.95.3? That sounds backwards to me. They're both free
> >> > software, and gcc 2.96 is among other things more standards-compliant.
> >>
> >> And among other things, less standard.
>
> > That's by your definition of standard. Not real standards.
>
> I said "standard".
As in "what many others are using"? Well, if what many others are using
sucks, there is no reason why you shouldn't produce and use something
that doesn't suck. This is vastly different from real standards, where
things are specified and you have to obey to what's specified if you
want to be compliant with the standard.
> >> This is FUD.
>
> > No, I am not discrediting anyone.
>
> You are .. you are slighting everyone who doesn't go with gcc 2.9.6
> by trying to imply that it's "better" (and hence that distros who.
> reightly, won't touch it are "worse").
This is so twisted I can't really believe it. If I say "I speak German
well", am I discrediting everyone else in the world and saying that they
are worse German speakers than I am?
And yes, gcc 2.96 is a better compiler for lots of reasons. That doesn't
mean that there aren't valid reasons to stick with any other compiler.
In this case, I didn't see any evidence of such a reason, so I suggested
to the original poster sticking with kernel 2.96.
I'm not discrediting anyone, other than if one applies your flawed logic
and thinks "he said A is good, so he must be saying that B is bad and
everyone using B are stupid morons".
You are the one discrediting here. You say that everyone that actually
uses gcc 2.96 and knows that it works just fine must be dreaming, thus
calling them liars when that's simply not true.
> >> You know perfectly well why he would want to replace it ... so that he
> >> can use software compiled on other distros,
>
> > Why should he be using software *compiled for other distros*? Name a
>
> Because that's what people should be doing in a single linux universe.
There is not a single Linux universe. If it was, we would have only one
distribution.
> Go build your own pet garden phenotype of object code if that's what
> turns you on.
Use software compiled for your architecture, or compile it yourself.
That's a very simple rule. Maybe one day you will understand it too.
> > piece of software that doesn't exist either as source or as rpm packages
> > for Red Hat.
>
> Too easy (my own for a start, I hope!). Go to some archive like sunsite
> and count the packages that redhat don't have.
I count lots of source packages. LOTS of them. What was your point?
> > Besides, Mandrake now uses gcc 2.96 too.
>
> "now uses"? You mean that they copied redhat's distro again in an
> effort to beat them to their client market. They've done it every time
> so far - and I personally thought that RH's selection of a propriettary
> compiler was an effort to get them off their back.
gcc 2.96 is not proprietary. It's GPL and the source is available. I'm
sorry if this ruined your conspiracy theory.
> >> and so that his software can be used on other distros.
>
> > It can be used on everything else that looks like a computer and has a
> > compiler. Ever heard of source code?
>
> Have many people? Try asking a person in the street. Lot's of them have
> computers.
What is your point?
> >> The problem is gcc 2.96, nothing to do with RH's attempts to fix it
> >> after the fact of their decision to pirate it and the gcc team's prompt
> >> disinheritance of it ...
>
> > How can one "pirate" free software? Please tell me. Else I have
>
> Quite easily. Go to my software site and take a development version of
> my software. Hack it and release it as your own without telling me or
> consulting me. Do that instead of contacting me and asking to work with
> me on moving the software along in a cohesive manner towards a common
> goal. It's a clasic fork manouever.
Forking is not pirating. Even RMS admits to that. If you and I work on a
GPL, free software project together, and I want to release a new version
now and you say "no way, I desperately want features X, Y, X, and
possibly Q in too, I don't want to release in at least a year before we
have all that" and I say "But people desperately need a new version now
with the fixes we have made in the last months" and you and I don't
agree, forking the project may be the only solution.
Forking is not a solution in all cases, but in some cases it's needed.
Like when people have fundamentally different goals for the project, or
fundamentally different needs that are not compatible with each other.
That was the case here. There hadn't been a new gcc release for over a
year, and many important fixes where left unreleased (mostly for non-x86
platforms and C++). People needed those features. Not in a year or two,
but then.
That said, I don't think that these issues won't be resolved when gcc
3.0 is finally out and distributions can use the 3.0 release.
> > misunderstood the GPL and the concept of free software.
>
> You have.
No, I haven't. Forking is needed sometimes, and it's a perfectly valid
option in free software.
> >> > upgrade to Red Hat Linux 7.1 which contains an even newer gcc. I've had
> >>
> >> You mean "even worse gcc".
>
> > No. Why should I mean that?
>
> Because of your desire for truth ...
I don't understand what you mean by that. If there is someone in this
discussion that doesn't like the truth, it appears to be you...
gcc 2.96 is a better compiler in many aspects than gcc 2.95, face it.
Also gcc 2.96 has been improved over time, like any other software
project, and yes, the gcc 2.96 in RH 7.1 is better than that originally
released with RH 7.0.
> > It was better in many areas than gcc 2.95.x. It still is.
>
> Many areas? Which? Is there ANY area of C compilation in which 2.8.1
> is not perfectly satisfactory?
Yes, optimization (especially for different architectures).
> If you have a new peephole optimization, add it to the backend.
That is exactly what people have been doing.
> > I doubt Mandrake would decide to use it for their entire 8.x series if
> > it wasn't.
>
> I do .. I doubt that mandrake do anything except add their own addons
> to RH-whatever.
They don't. Mandrake likes to say that they take the good parts of Red
Hat and add their own stuff to it (like the installer which is
completely different from Red Hat's). In this case, Mandrake appearantly
considered gcc 2.96 a good part.
> >> By all means discuss the merits or otherwise in plain english, but do not
> >> seek to insinuate qualities by your use of loaded words.
>
> > So I should be forced to dissaminate every feature in detail, leaving
> > you to be able to spread the FUD with loaded and false statements like
> > "it's worse" and no details or backup for your statements?
>
> I merely match your "it's better".
It is. If you want to see many of the details,
readhttp://www.bero.org/gcc296.html .
> > If you want the details, go to http://www.bero.org/gcc296.html . Then
>
> Actually, I've read that before. It struck me at the time as a
> ludicrously false piece of apologism.
So what is wrong then? I don't know of anything on that page that
contradicts with my own experiences.
Aside from Bero's fondness of KDE, which I don't share :-)
> I've also commented on that document in the newsgroups before. The only
> piece of technical truth in it that I can find is:
So you're saying that everything is lies? Then please provide some
evidence for that. To me, you're just spouting off FUD without anything
to backup your claims.
> It may not be "standards compliant" as in "what most others are
> shipping", but 2.96 is almost fully ISO C99 and ISO C++ 98 compliant,
> unlike any previous version of gcc.
>
> and iso C99 compliance is of mild interest (although if there is anything
> noncompliant about other compiler versions, the changes will be trivial
> to implement if anybody feels like it). I don't particularly care, since
> I write ansi compliant code.
Ansi is obsoleted.
> But c++ standards are a moving target and not of much interest.
They are. The standards that actually exist are important.
> > come back and we can have a proper discussion based on actual merits and
> > qualities.
>
> I've already been there. The document is not convincing in any way as
> regards C. It doesn't even offer any example of iso C code that 2.9.6
> can deal with and others can't, though I'm willing to believe there are
> some. So what? No compiler in existence manages compliance with
> anything (I recall hp's c89 not compiling the example on its varargs
> manpage because of silent promotion of char to int). What is important
> is it's reliabilty
Reliability agreed.
> and _standardness_,
What is standard about a compiler? That it works according to language
specifications.
> not the number of ticks on the
> I-spy scoresheet of standards violating bugs.
Umm, that certainly is important. If you cant compile code complying
with the standards, the compiler is broken, and it should be fixed.
> Only the other day I
> found that gcc 2.7.2 doesn't correctly initialize labelled fields
> in static structs, yet everyone will tell you that gcc 2.7.2 is
> reliable as the rock you stand on. That's the point .. there are bugs.
I never said there aren't any bugs.
> There always are. If you exercise the corners of a language you find
> more bugs in the compilers.
Very true.
> So programmers, good programmers, don't do
> that. And the newer the compiler, the more bugs it has. The more
> features the compiler has, the more bugs it has. The bigger the
> language that the compiler deals with, the more bugs it has. This
> is inevitable. That redhat chose to bug their distro is strange,
> but not incomprehensible. I still feel that the reasons were purely
> business based.
Yes, having a good compiler is good business. Other than that, I don't
think anything about this was business. It was more than likely just a
technical decision ("we need a good compiler and we need it now"), and
since other distributions are starting to use it, it seems it was a good
technical decision. An interim solution, yes, but a good one.
Christian
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to comp.os.linux.misc.
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Misc Digest
******************************
