Linux-Development-Sys Digest #896, Volume #6 Sun, 27 Jun 99 08:13:48 EDT
Contents:
Re: Why we are still holding on to X Windows (Justin Vallon)
Trouble patching kernel 2.2.10 (user)
Re: Framebuffer device why doesn't it work? - again.... ([EMAIL PROTECTED])
Re: Why not C++ (Andi Kleen)
Re: Why not C++ (Nathan Myers)
Re: using C++ for linux device drivers (Nathan Myers)
Re: Why not C++ (Bruce Hoult)
Re: Why not C++ (Nathan Myers)
Re: Why not C++ (Nathan Myers)
Re: Why not C++ (Nathan Myers)
Re: TAO: the ultimate OS (Stefaan A Eeckels)
Re: Why not C++ (Nathan Myers)
Re: Why not C++ (Nathan Myers)
Re: Why not C++ (Nathan Myers)
Re: Why not C++ (Chris Double)
----------------------------------------------------------------------------
From: Justin Vallon <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
Date: 26 Jun 1999 23:26:41 -0400
mlw <[EMAIL PROTECTED]> writes:
> > That was the extent of the capability of sound at the
> > time. We now have far better sound capabilities, so X should continue its
> > sound support and be extended for these new capabilities.
>
> No, a network streaming audio format/protocol should be a separate
> standard.
I'm not sure that the distinction is that clear. In 99.99% of the
cases, an applications sound I/O and graphics I/O go to the same
place: the user. It seems superfluous to create an alternate
protocol.
While the X protocol should most likely not include sound support, it
should provide a mechanism for piggybacking other protocols on top of
the X stream. A hypothetical 'XAudioClient' library could use the same X
display pipe, with an 'XAudioServer' server extension playing the sound.
--
-Justin
[EMAIL PROTECTED]
------------------------------
From: user <[EMAIL PROTECTED]>
Subject: Trouble patching kernel 2.2.10
Date: Sun, 27 Jun 1999 07:47:02 GMT
Did anyone else have trouble applying the kernel patch 2.2.10?
I started with 2.2.5 and appled 2.2.6, 2.2.7, 2.2.8, 2.2.9.
Patch 2.2.10 failed.
Specifically, two patches contain the following line:
\ No newline at end of file
The patches are for these files:
/linux/Documentatino/video4linux/bttv/PROBLEMS
/linux/drivers/net/sk_mca.h
My version of patch is 2.1b.
To fix the problem I just deleted the two lines (1764 and 17450) and patch worked fine.
Please respond via this newsgroup, [EMAIL PROTECTED] is bogus...
--
The only possible interpretation of any research whatever in the
`social sciences' is: some do, some don't.
-- Ernest Rutherford
------------------------------
From: [EMAIL PROTECTED]
Subject: Re: Framebuffer device why doesn't it work? - again....
Date: Sun, 27 Jun 1999 08:38:28 GMT
Craig Graham <[EMAIL PROTECTED]> wrote:
: I've asked this before, and still got nowhere.....anyway.
: How do I get the framebuffer consoles to work (/dev/fb0, etc).
: I have an S3 Virge video card, and I'm running kernal 2.2.9.
: I've tried all the setup's I can think of, mknod'ed the device
: (char major 29, minor 0 for fb0) - still no joy. All I get is
: a device does not exist error.
The Virge fb driver is incomplete, and written for Amigas to boot.
It does not yet work.
There is work underway to make it work on PCs, but that support is not
in the kernel yet.
Jeff
------------------------------
From: Andi Kleen <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 27 Jun 1999 08:42:06 +0200
[EMAIL PROTECTED] (Nathan Myers) writes:
> Andi Kleen <[EMAIL PROTECTED]> wrote:
> >Well, the theory is that:
> > int f(vector<vector<float> > array)
> >is easier than
> > int f(float **array)
> >to handle for a beginner.
[exercise in selective quoting to prove a point deleted]
My point was simply:
In my first tries to use the STL, I had to fight with 10+ lines
really obscure template error messages. I wouldn't wish that to
any poor beginner (given that beginning is usually mostly syntax
error fixing at first)
-Andi
--
This is like TV. I don't like TV.
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 27 Jun 1999 03:38:53 -0700
Johan Kullstam <[EMAIL PROTECTED]> wrote:
>the memory fragmentation problem pretty much precludes seriously using
>C++ for kernel work. look to microsoft for examples of C++ in action.
Nazis eat peanut butter. Therefore peanut butter is bad.
This supposed "memory fragmentation problem" is just more FUD.
Shame on you, Johan.
>after using lisp's macros i don't know whether to laugh or cry when i
>think of C++ templates.
By the first corollary to Godwin's Law (Lisp being mentioned in
a discussion of programming languages), this thread is now over.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Subject: Re: using C++ for linux device drivers
Date: 27 Jun 1999 03:45:25 -0700
Johan Kullstam <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Nathan Myers) writes:
>> Also, the declaration of pointer
>> types above is not C++-like. In good C++ we use "void* p", not
>> "void *p".
>
>how do you declare more than one pointer thing on a line? like
>
> double *xp, *yp;
>
>or is that verboten in good C++?
Twice: In good C++ we declare only one var per line, *and* we
initialize it. Since you declare a variable when you need it,
not at the top of the block, it is very rare even to want to
declare two or more on one line.
How does your example look with initialization?
> double *xp = p, *yp = xp + 10;
Now it looks like you're initializing *xp, not xp.
Bad style.
>of all the things C++ has introduced, the star movement is the
>silliest -- it adds nothing but gratuitous breakage of previous
>convention and risk of confusion. since it's not required, i refuse
>to use it.
Go ahead, write bad code. Reason poorly.
It's your reputation on the line, not mine.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
From: [EMAIL PROTECTED] (Bruce Hoult)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: Sun, 27 Jun 1999 22:54:40 +1200
In article <7l4d4r$4is$[EMAIL PROTECTED]>, [EMAIL PROTECTED]
(Linus Torvalds) wrote:
> In article <[EMAIL PROTECTED]>,
> Bruce Hoult <[EMAIL PROTECTED]> wrote:
> >
> >You may be able to find some particular C++ compiler that produces worse
> >code compiling a C program than some particular C compiler, but that is a
> >function of the compiler, not the language.
>
> In theory, you're right.
OK.
> In practice, C++ is a much more complex language. As such, C++
> compilers are much more complex beasts. And that is why some C++
> compilers do not generate as good code as the equivalent C compilers do.
I'd love to see examples.
Is there any difference between gcc and g++, if both are given the same
source code? (e.g. just change the filename from *.c to *.C). Not as far
as I know. I'd love to see a counter-example.
Is there any difference between Metrowerks Codewarrior in C mode and
CodeWarrior in C++ mode? I've never *seen* one, on either Mac or
Windows. I'd love to see a counter-example.
I'm afraid I basically don't use any other compilers. Which C++ compilers
are bad?
> In effect, what you're saying is "there is no theoretical reason why C++
> would be any slower than C". And you're right.
OK, thanks.
> But what others are saying is "a lot of existing C++ compilers generate
> worse code than a lot of existing C compilers". And they are right too.
Which ones? Specifically?
> Sometimes theory matters. Sometimes it doesn't. The world is not as
> simple as you make it out to be.
I totally agree. In theory, theory and practice are the same. In
practice they are not. So I'd love to see some practical examples.
-- Bruce
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 27 Jun 1999 04:04:48 -0700
NF Stevens <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Nathan Myers) wrote:
>
>>If you don't know C++ templates, you don't know C++ at all. It is
>>templates, for example, that make it possible to write a C++ library
>>that does matrix operations as efficiently as specially-optimizing
>>Fortran on machines specifically designed to run Fortran well. Unlike
>>Fortran, though, C++ templates are not tuned specificially for matrix
>>math, so can be used to accomplish similar wonders in any area.
>
>I have to disagree with this. Templates do not in any way improve
>the efficiency of generated code. They are no faster (and no
>slower) than the equivalent hand written code. Templates only
>improve the efficiency of the programmer since only one (templated)
>version has to be coded rather than individual versions for each
>template class.
C++ cannot of course be faster than the equivalent assembly
code, but the C++ compiler can optimize code better than you
can by hand in C, because it knows more about expressions than
you can tell the C compiler.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 27 Jun 1999 03:55:16 -0700
John E. Davis <[EMAIL PROTECTED]> wrote:
> Jeffrey L Straszheim <[EMAIL PROTECTED]> >wrote:
>>Nathan Myers wrote:
>>> It is possible to declare non-const reference arguments in C++,
>>> but that doesn't mean one finds it unexpectedly, in good code.
>
>Are you (Nathan) saying that you would never find a function like
> int something_silly (int& y)
>in good code? Perhaps a good C++ coder would use:
> int something_silly (int *y)
>which is how it is done in C.
Close:
int something_silly (int* y)
>[in a call to something_silly]
>one cannot assume that the value of `y' cannot be changed, even in
>good code that uses `const' in all the right places. Unless, of
>course, one always uses the `C' form with pointers.
If you are going to start comparing error-prone-ness of C and
C++, you will find C starts at a marked disadvantage. My own
experience is that in good C++ and C code written with equal
competence, the C++ code has an order of magnitude fewer bugs.
Buggy code is profoundly harder to understand than clean code.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 27 Jun 1999 04:00:39 -0700
John E. Davis <[EMAIL PROTECTED]> wrote:
> Nathan Myers <[EMAIL PROTECTED]> wrote:
>>Far more powerful than either are templates.
>
>I believe that these can also be emulated to a certain extent via the
>preprocessor.
No. _None_ of the interesting aspects of C++ templates can be emulated
with the preprocessor. See http://oonumerics.org/blitz/index.html .
>But in all honesty, weren't C++ templates one of the
>things to avoid when using g++ because of its buggy implementation? I
>realise that egcs may have finally overcome this obstacle, but this
>has only come about recently.
They weren't buggy so much as woefully incomplete. That has been
remedied, recently, in Egcs.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
From: [EMAIL PROTECTED] (Stefaan A Eeckels)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 27 Jun 1999 10:28:04 GMT
In article <7l44u9$q0t$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Terry Murphy) writes:
>
> For pipes, they're unidirectional, and you cannot use a program
> out of the box for bidriectional communication (you need to
> reimplement it with pipes).
> Anyways, I was just using those as examples: there are literally
> hundreds of annoyances of Unix which are caused by lack of design
> and foresight which are fixed up by kludges. I have blathered
> about these many times over the years, and don't particularly
> want to bore those again who read my messages back then, but you
> can just search for me on DEJA.
I still fail to see how it follows that such things would not
have happened *if* a formal design process had taken place in
1969 (by formal meaning a UNIX team, with a requirements document,
etc), which is what you asserted. You're trying to push the
discussion in the direction "UNIX isn't perfect", which is so
obvious it doesn't warrant discussion.
The reason why I butted in was the assertion that a formal design
process, and specifically a requirements document *before* the
start of the UNIX "project" by Ken Thompson, would have guaranteed
that UNIX would have been better.
Ironically, you display the same attitude towards UNIX many UNIX-lovers
have vis-a-vis Windows, which is to resent the fact that a system
you [feel|know] to be technically inferior managed to overcome a
system (which I'd guess in your case would be VMS) you [feel|know]
to be superior.
>
>>The first releases of UNIX were internal products with a small number
>>of users. I wasn't there, but I'm quite sure the UNIX people *did* get
>>the requirements from their patent department WRT text processing before
>>they set out to provide both the OS and the formatter. I'm quite sure
>>they *did* unit test both the OS, the formatter, and the macros for
>>conformity with the requirements (or the patent department wouldn't
>>have used the system), and did whatever tests were required to have
>>a satisfactory system.
>
> Do you have any evidence of this? I read Salus's _Quarter Century of
> Unix_ and it did not contain much about unit testing and requirements.
The Patent department used it, no? It did enough of what they wanted,
so by all definitions of "requirements", it met their "requirements".
And Osanna did at least run "roff" once before he released it, I
fancy.
> I'd actually be quite surprised if this was done at Bell Labs: how much
> experience did the organization have with software development at the
> time?
If the question is whether *management* at Bell Labs had a formal
software development method, I can imagine (but since I wasn't there,
I don't know) they might not have one. That does not mean that the
people working on UNIX did not obtain the requirements of the prospective
users, or unit-tested the software they developed.
>
>>What you fail to see is that once UNIX had become a multi-vendor
>>product is was (and is) wholly impossible to impose a strict
>>"by-the-book" approach to its evolution.
>
> I understand it, and I understand that this is the root of
> many of its problems.
>
>>You're forgetting that
>>VMS has essentially died, *because* the development process did not
>>allow the system to be adapted to the requirements of the users.
>
> That is SOME historical revision you're doing. VMS lost market share
> for two reasons:
>
> (a) Pointy haired managers who believed all of the Unix hype of the
> late 80's/early 90's, and converted over. Sun probably has the
> highest marketing:quality ratio in the business, and DEC had the
> lowest, so this was not a diffcult job for Sun. In the 80's Sun
> spread much FUD about DEC.
Amazing how suddenly the PHBs become the reason why VMS lost out,
whereas they are the cornerstone of solid system development as
far as you are concerned.
>
> (b) The VAX was significantly slower than the RISC machines at the
> time. The VAXstation 3100 and DECstation 3100 were announced the
> same day. Both running Ultrix, the performance was as follows
> (in seconds): GNU C (VAXstation: 291, DECstation: 90),
> TeX (VAXstation: 449, DECstation: 95), spice (VAXstation: 352,
> DECstation: 94) (these numbers are from Patterson & Hennessy)
>
> With Alpha, (b) is no longer a problem. (a) is a still problem but this
> time Windows is the enemy, not Unix.
But that should be OK, as Microsoft uses the correct approach to
system design, and produces high-quality, revolutionary products.
They are thus guaranteed to produce a top-quality OS, that will
require no patches, or third-party features such as NTFS defraggers.
;-)
<VMS sales blurb snipped>
> So I ask, what about VMS do you insist is not adaptable? I challenge
> you to name one single solitary Unix flavor which is simultaneously
> used as in workstations, servers, e-commerce, stock exchanges, banks,
> and industrial control (Solaris probably comes the closest, but it
> has all sorts of different versions, and third party patches to make
> it more secure, etc., so it's not really one system).
Ah, but does VMS run Word?
>>But it was done nonetheless. Separate license or not, VMS was modified
>>to support POSIX, and this was not foreseen in the original design,
>>which is what we're talking about.
>
> No, VMS has not modified to support POSIX. It was simply a a library,
> which was not included in the base system, and had to be installed to
> get the functionality. What about this is modification to VMS?
It begot a library. It had to be adapted to cater for something it
had not been designed for. It was a hack. The original design process
hadn't taken this into consideration, even though it was a formally
managed design-by-committee.
>>Again, dear Terry, give me a break. MS engineering has been non-existing,
>>because they've largely bought products and adapted them (more or less
>>successfully). Their 'C' compiler started out as Lattice 'C'. I forget
>>whom they bought Powerpoint from. Excel is also an outside acquisition.
>
> So I guess in your world, Sun invented Unix and did not buy it
> from AT&T.
They did not buy it from AT&T. They used BSD.
> So did SGI. And IBM. And HP. And DEC. And I suppose Torvalds
> never saw anything called Unix in his life, but thought up all of this
> stuff by himself. They just happened to stumble upon this by
> engineering, and the similarities among each other are purely
> coincidental. Please.
But that has *nothing* to do with MS. Buying a product to modify
and sell it doesn't follow the formal design method you've outlined,
and that you claim MS is using to develop their products. You say that the
reason why MS is bringing out such amazingly superior stuff is their
approach to software engineering. Meseems they are not that hot, and
the problems they have getting Windows2000 ready are IMHO indicative
of the fact that they don't have such an efficient development model.
It seems to me that their desire to remain compatible with
design decisions of the past (like "No PC program needs more than
640K", or "Windows NT shall use the incredibly complex Win32 API
and not have a decent command line facility") is making their life
incredibly difficult.
> As for Excel, that started as a DOS based product, which was probably
> written in assembly language and ran in something like 128k. Surely
> you don't believe it has anything at all in common with Excel 2000 (or
> whatever the latest version is) besides the name?
Maybe, maybe not. I have no access to the source code, so I can't tell.
>>They scrambled like mad to get compression into MS-DOS when Stacker
>>turned out to be successful. They scrambled like mad to get TCP/IP into
>>windows when the Internet turned out to be a success.
>
> Scrambling like mad is what you do in this business.
And this proves beyond doubt that no formal process will guarantee
that you've designed the perfect system.
Let's close this debate, because it gets into territory I didn't want
it to go into. Let's agree that formal methods do not *by themselves*
guarantee a good product. Let's agree that UNIX wasn't designed using
formal methods. Let's agree that any successful product needs to
retain compatibility, and that this implies that many design problems
remain forever in the product.
What saddens me most when I look at the OS scene is that Microsoft,
by being so marketing driven, managed to produce an OS they call
"New Technology", that in not one feature is significantly better
than either UNIX or VMS, which each *did* advance the state of
the art in OS development.
Take care, and keep an open mind.
--
Stefaan
--
PGP key available from PGP key servers (http://www.pgp.net/pgpnet/)
___________________________________________________________________
Perfection is reached, not when there is no longer anything to add,
but when there is no longer anything to take away. -- Saint-Exup�ry
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 27 Jun 1999 04:42:31 -0700
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>Bruce Hoult <[EMAIL PROTECTED]> wrote:
>
>But what others are saying is "a lot of existing C++ compilers generate
>worse code than a lot of existing C compilers". And they are right too.
>
>Sometimes theory matters. Sometimes it doesn't. The world is not as
>simple as you make it out to be.
Enough generalities. Take for example Egcs. C and C++, same code
generator, same optimizer. The last time you tried g++ was years
and years ago. It's time to look again.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 27 Jun 1999 04:47:46 -0700
Andi Kleen <[EMAIL PROTECTED]> wrote:
>My point was simply:
>In my first tries to use the STL, I had to fight with 10+ lines
>really obscure template error messages. I wouldn't wish that to
>any poor beginner (given that beginning is usually mostly syntax
>error fixing at first)
True, there is a great deal of work yet to be done on improving
error reporting in Egcs, and similar work in Gdb.
OTOH, once you get code past the compiler, it's far less buggy.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 27 Jun 1999 04:18:29 -0700
Paul Jackson <[EMAIL PROTECTED]> wrote:
>Nathan Myers wrote:
>|> [Those saying] it's slower than (e.g.) C are just spreading FUD.
>
>Put it this way -- if I could actually try ten
>different teams of professional but not superstar
>programmers, using different languages to implement
>a real world (multi-year, requirements changing
>for the life of the project, ...) app, right
>now I'd bet that Python team (a delightful language
>that I just learning) would produce the fastest
>working app (because they'd have time to get the
>architecture and algorithms 'right'), and the C++
>team would produce one of the slower apps, with
>a few key loops going fast, but bogged down in a
>slew of other confusions.
Odd choice of example; Python is written in C++.
I will assert that my team using Python with C++ modules would
produce the fastest result, soonest.
See http://www.cantrip.org/realworld.html .
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
From: Chris Double <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 28 Jun 1999 00:10:06 +1200
[EMAIL PROTECTED] (Bruce Hoult) writes:
> > In practice, C++ is a much more complex language. As such, C++
> > compilers are much more complex beasts. And that is why some C++
> > compilers do not generate as good code as the equivalent C compilers do.
>
> I'd love to see examples.
[...snip...]
>
> I'm afraid I basically don't use any other compilers. Which C++ compilers
> are bad?
In a recent Windows Developer Journal (June 1999) they printed an
article on a Microsoft Visual C++ 6.0 bug. Some code in C++ mode
caused incorrect assembler to be generated resulting in an infinite
loop. The exact same code in C mode compiled and executed as expected.
Chris.
------------------------------
** 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 (and comp.os.linux.development.system) via:
Internet: [EMAIL PROTECTED]
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-Development-System Digest
******************************
