Linux-Development-Sys Digest #884, Volume #7 Sat, 20 May 00 17:13:21 EDT
Contents:
Re: serial port RTS control ? (Grant Edwards)
Re: serial port RTS control ? (Grant Edwards)
Re: Need ideas for university funded project for linux (Matthias Warkus)
Re: Need ideas for university funded project for linux (Matthias Warkus)
Re: inline-limit might be fun to try (Eric Taylor)
Re: Need ideas for university funded project for linux (Leslie Mikesell)
RH6.1/gcc2.91: #include system search (Shaun Arral)
Re: Linux Driver Development (Jonathan Buzzard)
Re: Need ideas for university funded project for linux (Leslie Mikesell)
Re: Need ideas for university funded project for linux (Leslie Mikesell)
Re: Need ideas for university funded project for linux ([EMAIL PROTECTED])
Re: Need ideas for university funded project for linux (JEDIDIAH)
Re: Need ideas for university funded project for linux (JEDIDIAH)
Re: Need ideas for university funded project for linux (JEDIDIAH)
Re: Need ideas for university funded project for linux (JEDIDIAH)
Is OpenGL hardware accelerated? (Andreas Rottmann)
Re: Need ideas for university funded project for linux (David Steuber)
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: serial port RTS control ?
Date: Sat, 20 May 2000 17:28:31 GMT
In article <[EMAIL PROTECTED]>, Mario Klebsch wrote:
>>And what's happen if I use CRTSCTS (hardware flow control) mask in ioctl ?
>
>Althoug CRTSCTS does have RTS in its name, RTS is not affected by
>CRTSCTS.
Yes it is. When its input buffer is full, the host driver will assert RTS
to tell the other end to stop transmitting.
>Its function simply is to stop the data transmitter, when
>CTS is not active.
Right, but it's bi-directional CTS is used in one direction and RTS in the
other.
--
Grant Edwards grante Yow! Oh, I get it!! "The
at BEACH goes on", huh,
visi.com SONNY??
------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: serial port RTS control ?
Date: Sat, 20 May 2000 17:33:09 GMT
In article <[EMAIL PROTECTED]>, Mario Klebsch wrote:
>>> OTOH, you cannot just use sleep, since very often, those systems do
>>> not have anything like carrier or collision detection.
>
>>Except that I am the only master on this line... so perhaps can I do a
>>sleep() though
>
>I would doubt this. If you were the only master, then there would be
>no need to control RTS at all. Perhaps you are calling the other
>participants slave, bat at the moment, they activate their line
>driver, they are masters on the bus.
In the protocols commonly used on RS-485 lines "master" refers to a device
that is allowed to decides when it wants to transmit. A "slave" only
transmits when commanded to by a "master". It's like a PCI bus: a DRAM
controller may have drivers that transmit data onto the bus, but it's still
not called a bus "master" because it's passive. It only puts data onto the
bus when somebody else (a bus "master") tells it to.
Most of the protocols I've used on RS-485 busses were single-master systems:
Modbus, HART (later modified to allow 2-3 masters), and some other
home-baked ones.
--
Grant Edwards grante Yow! Am I SHOPLIFTING?
at
visi.com
------------------------------
From: [EMAIL PROTECTED] (Matthias Warkus)
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
Date: Sat, 20 May 2000 02:27:41 +0200
Reply-To: [EMAIL PROTECTED]
It was the Fri, 19 May 2000 03:41:59 GMT...
...and [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > : 4. A GUI interface to the most common configuration files.
>
> > Never, never, never let user who doesn't understand things tweak the
> > config files. For such users remote sysadmin service via SSH should be
> > provided.
>
> Huh?
>
> Are you suggesting we start up a Centralized Linux Administration
> Bureau or something? And remember that not all computers are on a
> network, and very few of them are on one all the time.
Eazel are constructing a framework to do exactly this kind of remote
administration for regular dialup machines.
> > : 3. A DirectX-like platform for hardware-accelerated devices, not
> > : necessarily at the kernel level;
>
> > Whats wrong with OpenGL?
>
> The fact that it's not hardware-accelerated?
Of course it is hardware accelerated. The entire idea of OpenGL is
wrapping hardware acceleration. Everything in the OpenGL API is
centred around making effective hardware accelerated implementations
possible.
> > No, if apache is not killer app, you'll have to invent totally new way
> > of using computers.
>
> Apache isn't a killer app. The reason is that only webmasters use web
> servers.
Help systems use Web servers. Webmin uses a Web server. Heck, even
SIAG Office serves Web pages.
> A killer app is something that most computer users will find
> useful.
Of course Apache is a killer app.
mawa
--
Der Speicherplatz in unseren Gehirnen ist begrenzt.
Mechanisches und tabellarisches Wissen hat in einem Gehirn m�glichst
wenig zu suchen. Je mehr des Raumes f�r Wissen ausgenutzt wird, das
uns zu besseren Menschen machen kann, desto besser. -- mawa
------------------------------
From: [EMAIL PROTECTED] (Matthias Warkus)
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
Date: Sat, 20 May 2000 02:23:45 +0200
Reply-To: [EMAIL PROTECTED]
It was the Fri, 19 May 2000 07:00:00 GMT...
...and David Steuber <[EMAIL PROTECTED]> wrote:
> I don't consider GTK-- to be a class library. It is just a wrapper
> for GTK. Not the same thing really now, is it? Not that GTK is a bad
> thing. After all, there is a port of GIMP for Windows.
Have you used GTK-- or even only read the description? Of course it
wraps GTK+ in its core. But it's got everything you can expect from a
C++ class library: namespaces, inheritance, easy construction of new
widgets, stuff like that, and a real neat wrapper around GTK+ signals
that's supposed to be conceptually clean without requiring a kluge
such as MOC.
mawa
--
Radlertrinker!
Binnensegler!
Blasenteetrinker!
Blockfl�tenlehrer!
------------------------------
From: Eric Taylor <[EMAIL PROTECTED]>
Subject: Re: inline-limit might be fun to try
Date: Sat, 20 May 2000 10:56:10 -0700
Graham Stoney wrote:
>
> In article <[EMAIL PROTECTED]>,
> Eric Taylor <[EMAIL PROTECTED]> wrote:
> >For example, I have to use bzImage for my kernel as zImage is too large.
> >There could be uses for this other than just speed tradeoffs.
>
> If you're interested in minimizing your kernel size, compile with "-Os" instead
> of "-O2" and check out the patches at:
> http://members.xoom.com/greyhams/linux/patches/2.2
I see you are interested in embedded systems. That too is
a use for a smaller kernel I had not thought of. Probably
speed is of lesser concern as well.
I tried your suggestion of the -Os and was rather
disapointed. It shrunk my kernel by only 8192 bytes.
(a suspicious number?? maybe its not actually doing
what we would expect).
The normal size, before compression is 1.8 megs for my config.
I also tried -fno-inline and this fails to link properly.
I noticed that there is a discussion in Stallmans Gcc book
about using inline and extern together. He suggests that
to use this, one puts the definitions in both a header file
with inline and extern, and another copy w/o inline and
extern in a library file. This technique might provide
a way to easily turn on/off various inlining. However, I
don't have the time to experiment further.
eric
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
Date: 20 May 2000 12:59:01 -0500
In article <[EMAIL PROTECTED]>,
Full Name <[EMAIL PROTECTED]> wrote:
>>
>>: 1. A streamlined, easy install process;
>>
>>Disagree. System should be installed by competent techinicans in
>>computer shops. Windows is not any more easy to install than say
>>Mandrake 7.0, only user do it much more frequently, so get used to it.
>>
>
>What can someone say to such a stupid statement.
Try it and see. On hardware that it can auto-detect (most PCI
stuff), Mandrake is just about full-auto. If you have a DCHP
server on the network you don't even need to know network
addresses.
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: Shaun Arral <[EMAIL PROTECTED]>
Subject: RH6.1/gcc2.91: #include system search
Date: Sat, 20 May 2000 11:26:25 -0700
I wanted to look at <sys/errno.h> and noticed quite a few of them.
Now I'm wondering what should be my #include search path be setup as
(including X) in my IDE??
Or where do i find this i man'd: gcc,make, looked through HOWTO's.
Thank You
/usr/lib/bcc/include/arch/errno.h
/usr/lib/bcc/include/bsd/errno.h
/usr/lib/bcc/include/errno.h
/usr/lib/bcc/include/generic/errno.h
/usr/lib/bcc/include/linux/errno.h
/usr/lib/bcc/include/linuxmt/errno.h
/usr/lib/bcc/include/msdos/errno.h
/usr/lib/bcc/include/sys/errno.h
/usr/include/bits/errno.h
/usr/include/errno.h
/usr/src/linux-2.2.12/include/asm-i386/errno.h
/usr/src/linux-2.2.12/include/linux/errno.h
/usr/i386-glibc20-linux/include/asm/errno.h
/usr/i386-glibc20-linux/include/errno.h
/usr/i386-glibc20-linux/include/linux/errno.h
+2 that just contained #include <errno.h>
------------------------------
From: [EMAIL PROTECTED] (Jonathan Buzzard)
Subject: Re: Linux Driver Development
Date: Sat, 20 May 2000 14:48:01 +0100
In article <[EMAIL PROTECTED]>,
Scott Sweeting <[EMAIL PROTECTED]> writes:
> On Tue, 16 May 2000, Arnaud Westenberg wrote:
>
>> Ben Lull wrote:
>>
>> > I have recently been getting interested in developping drivers for some
>> > scanners which I've obtained. I'm not sure where to start. I don't see
>> > much on the web for driver development. It would be appreciated if
>> > someone could either post a tutorial on developing linux drivers in C or
>> > some links where I can get information on developing drivers..
>>
>> Hi Ben,
>>
>> As someone noted in an earlier thread, the scanner drivers can be found
>> through the SANE (Scanner Access Now Easy) project, however SANE itself
>> isn't a driver. http://panda.mostang.com/sane/
>
> AFAIK, SANE does not support parallel scanners. SCSI(2, I think) defines a
> certain command set in order to support a generic scanner. Parallel, on
> the other hand, makes no shuch provisions. It relies completely on the
> vendor to provide a driver, usually with their own whacked-out command
> set. I was very disappointed to find all this out. Needless to say, my
> next system will be SCSI.
>
This is simply not true. Firstly some parallel port scanners are simple
SCSI ones with a parallel to SCSI chip on board. Secondly SANE does
infact support a number of parallel scanners as well as growing number
of USB ones.
Secondly the SCSI-2 generic scanner specification is inadequate for a
real scanner and secondly every scanner manufacturer has made different
extensions to the standard, such that each SCSI scanner still needs a
backend writing specificaly for it (exception for scanners from a
given manufacture which all use the same manufacture command set, for
example HP and Epson).
JAB.
--
Jonathan A. Buzzard Email: [EMAIL PROTECTED]
Northumberland, United Kingdom. Tel: +44(0)1661-832195
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
Date: 20 May 2000 14:54:26 -0500
In article <[EMAIL PROTECTED]>,
David Steuber <[EMAIL PROTECTED]> wrote:
>
>' And as a result of SuSE predating RedHat, SuSE rpms are incompatible
>' with RedHat ones :-( I wish they'd switch to dpkg, but I bet there would
>' be incompatibilities with Debian there too - for the same reasons -
>' maintaining backwards compatibility breaks sidewards compatibility :-(
>
>It is the RPM BS that has caused me to abandon that format whenever
>possible. Instead, I prefere to install software from source.
>Packages that conform to the ./configure, make, make install mantra
>are easy to build and put where you want them.
You left out the dozen obligatory arguments to ./configure that
are different for every package to make it interoperate with
the rest of your setup. Even then it is impossible to use
this method alone to set things up so the next update from
the stock distribution (that by now has the fixes you added plus
more) will correctly replace your intermediate fix.
>You don't have to
>worry about dependencies because ./configure should discover if
>required libraries can not be found.
>
>Granted, this is not the way most users want to operate. But until
>all the distros adhere to the FHS strongly enough and stop adding
>their own hacks (patches) to the code, this is the most reliable way
>to go.
You do understand that source rpms do exactly those steps if
you rebuild them, don't you? It takes 3 rpm commands. One
to install the source rpm, one to rebuild the binary, and
one to install the binary, doing whatever it needs to do to
update an existing setup or install from scratch. You can
then copy the binary around and install on any other machines
that need it. The *.spec file actually specifies how to unpack
standard distribution tars, patch them with any distribution-specific
modifications, run configure with the distribution-specific
arguments (which are very handy to see even if you are not going
this route), compile, and do anything else necessary.
>I've even updated GCC and libc this way. That took a while on my
>hardware.
With rpms, chances are pretty good that someone has already done
what you need, so you can grab it and install. If not, and a
patch exists against the last distribution that was built as
an rpm, you can take the older source rpm, add the new patch
to the spec file and rebuild it. I do wish there were a simple
guide to doing this somewhere covering just these steps. I'm
just starting to do it this way myself. My main complaint
about rpm is that it has everything including the kitchen sink
in one command so it is difficult to figure out which options
you need for which step. As you mentioned, 'configure/make'
aren't hard and without a simple guide rpm looks more difficult.
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
Date: 20 May 2000 15:08:21 -0500
In article <[EMAIL PROTECTED]>,
Ray <[EMAIL PROTECTED]> wrote:
>>>On Debian that would be:
>>>
>>>"dpkg --get-selections > packages.dpkg" on master machine
>>>"dpkg --set-selections < packages.dpkg" on new machine
>>
>>How graceful is it about hardware differences?
>
>The above shouldn't change your hardware config. at all. In Debian hardware
>configuration is pretty much a manual affair anyway.
That's a problem - I'm looking for a full-auto system administrator
(to the extent possible, anyway). RedHat uses something called
kudzu to deal with hardware setup, and it handles things like
plugging in new hard drives, scsi tape drives, etc. I'm not
sure if it will catch video card changes on i386 machines but
I suspect it will. I've installed RH on a sparc 5, then swapped
the disk into an IPX and kudzu noticed that the video and sound
disk devices were different, asked if I wanted to deactivate the
old ones and then activate the new ones, and then continued to
boot up. I was impressed.
>> And is there
>>a way to do a subsequent update (including adding/removing as
>>well as updating packages) on the master so the copies can
>>track along?
>
>I imagine you could repeate the above any time you wanted to sync the client
>machines' packages but I can't say I've ever tried it. Most people just use
>"apt-get update" "apt-get upgrade" to keep their packages up to date. If
>you have several machines that you really want to stay identical then you
>might be better nfs mounting the / dir from the server or maybe using rsync.
Rsync doesn't know about any of the config changes that go along with
changed files. We need something that knows how to delete an
existing package that the maintainer no longer wants (example: he
switches from sendmail to postfix).
>> What if source changes are done and things
>>recompiled? Can the package be rebuilt and loaded from
>>an alternate location on the copies?
>
>You can have lines in your /etc/apt/sources.list like:
>
>deb ftp://USER:[EMAIL PROTECTED]/my_custom_debs/local
>
>and then put any custom built packages on your ftp server.
That sounds reasonable.
Les Mikesell
[EMAIL PROTECTED]
------------------------------
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
From: [EMAIL PROTECTED]
Date: Sat, 20 May 2000 20:12:48 GMT
[EMAIL PROTECTED] (Matthias Warkus) writes:
> > > : 3. A DirectX-like platform for hardware-accelerated devices, not
> > > : necessarily at the kernel level;
> > > Whats wrong with OpenGL?
> > The fact that it's not hardware-accelerated?
> Of course it is hardware accelerated.
No. It isn't.
It may have the potential to be accelerated at some point in the
future, but, as of this writing, it is not. NVIDIA has flatly stated
that they will not be doing hardware-accelerated OpenGL until XF86
4.0. As XF86 4.0 is not the official XF86 at this point, there is
not, officially, any hardware-accelerated OpenGL at this point.
> The entire idea of OpenGL is wrapping hardware
> acceleration. Everything in the OpenGL API is centred around making
> effective hardware accelerated implementations possible.
Actually, I think the entire idea of OpenGL is making available a
high-level 3D API to the user.
It seems to me that if they were more interested in wrapping hardware
acceleration, OpenGL would look more like Direct3D (which is
considerably more minimalist).
> > > No, if apache is not killer app, you'll have to invent totally new way
> > > of using computers.
> > Apache isn't a killer app. The reason is that only webmasters use web
> > servers.
> Help systems use Web servers. Webmin uses a Web server. Heck, even
> SIAG Office serves Web pages.
My opinions on the overuse of Web servers aside, none of this changes
the fact that your average shmoe does not use one. Bear in mind that
"your average shmoe" refers to the average of all computer users, no
matter what OS they have. So, tell me, does the average Win98 user
have a webserver installed?
> > A killer app is something that most computer users will find
> > useful.
> Of course Apache is a killer app.
Of course it is not.
--
Eric P. McCoy ([EMAIL PROTECTED])
non-combatant, n. A dead Quaker.
- Ambrose Bierce, _The Devil's Dictionary_
------------------------------
From: [EMAIL PROTECTED] (JEDIDIAH)
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
Date: Sat, 20 May 2000 20:30:58 GMT
On Sat, 20 May 2000 05:00:02 GMT, David Steuber <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (brian moore) writes:
>
>' The QPL requires software be free (as in free beer). It also requires
>' you to submit any software you link with QT to them, even if it is not
>' distributed and from the wording it seems that they want you to give
>' them unlimited rights to even your own personal (again, non
>' distributed) programs that you link to Qt.
>
>It requires your software to be GPL, if you use the Qt Free Edition.
>Naturally, if you don't like that, don't use Qt.
This alone makes the QPL more restrictive than the LGPL.
>
>Perhaps the project idea requested should be a free C++ library that
>does what Qt does. It should probably be a clone that you can build
>KDE against. Otherwise, no one may want it.
[deletia]
--
In what language does 'open' mean 'execute the evil contents of' |||
a document? --Les Mikesell / | \
Need sane PPP docs? Try penguin.lvcm.com.
------------------------------
From: [EMAIL PROTECTED] (JEDIDIAH)
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
Date: Sat, 20 May 2000 20:33:22 GMT
On 20 May 2000 14:54:26 -0500, Leslie Mikesell <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>David Steuber <[EMAIL PROTECTED]> wrote:
>>
>>' And as a result of SuSE predating RedHat, SuSE rpms are incompatible
>>' with RedHat ones :-( I wish they'd switch to dpkg, but I bet there would
>>' be incompatibilities with Debian there too - for the same reasons -
>>' maintaining backwards compatibility breaks sidewards compatibility :-(
>>
>>It is the RPM BS that has caused me to abandon that format whenever
>>possible. Instead, I prefere to install software from source.
>>Packages that conform to the ./configure, make, make install mantra
>>are easy to build and put where you want them.
>
>You left out the dozen obligatory arguments to ./configure that
>are different for every package to make it interoperate with
I dunno about you, but I rarely if ever actually need to
use any of those options...
[deletia]
The point of automation is to avoid such manual futzing.
--
In what language does 'open' mean 'execute the evil contents of' |||
a document? --Les Mikesell / | \
Need sane PPP docs? Try penguin.lvcm.com.
------------------------------
From: [EMAIL PROTECTED] (JEDIDIAH)
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
Date: Sat, 20 May 2000 20:36:57 GMT
On Sat, 20 May 2000 13:05:15 GMT, Full Name <[EMAIL PROTECTED]> wrote:
>On 18 May 2000 09:50:55 +0400, [EMAIL PROTECTED] (Victor Wagner)
>wrote:
>
>>
>>: 1. A streamlined, easy install process;
>>
>>Disagree. System should be installed by competent techinicans in
>>computer shops. Windows is not any more easy to install than say
>>Mandrake 7.0, only user do it much more frequently, so get used to it.
>>
>
>What can someone say to such a stupid statement.
That you are a moron.
Windows and DOS are where they are today because most people
don't have to deal with installing them. Any little quirk in
your setup and any WinDOS, Solaris, BeOS or Linux install can
quickly become nasty.
This is a side effect of the PC being a random collection of
spare parts. That adds a level of complexity to the whole
situation that is very difficult to just 'program around'.
--
In what language does 'open' mean 'execute the evil contents of' |||
a document? --Les Mikesell / | \
Need sane PPP docs? Try penguin.lvcm.com.
------------------------------
From: [EMAIL PROTECTED] (JEDIDIAH)
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
Date: Sat, 20 May 2000 20:42:21 GMT
On Sat, 20 May 2000 20:12:48 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (Matthias Warkus) writes:
>
>> > > : 3. A DirectX-like platform for hardware-accelerated devices, not
>> > > : necessarily at the kernel level;
>
>> > > Whats wrong with OpenGL?
>
>> > The fact that it's not hardware-accelerated?
>
>> Of course it is hardware accelerated.
>
>No. It isn't.
>
>It may have the potential to be accelerated at some point in the
>future, but, as of this writing, it is not. NVIDIA has flatly stated
>that they will not be doing hardware-accelerated OpenGL until XF86
>4.0. As XF86 4.0 is not the official XF86 at this point, there is
Says who? There's already at least one distro that's shipping it.
>not, officially, any hardware-accelerated OpenGL at this point.
>
>> The entire idea of OpenGL is wrapping hardware
>> acceleration. Everything in the OpenGL API is centred around making
>> effective hardware accelerated implementations possible.
>
>Actually, I think the entire idea of OpenGL is making available a
>high-level 3D API to the user.
NO, the point of OpenGL is to also expose hardware acceleration
to the programmer.
>
>It seems to me that if they were more interested in wrapping hardware
>acceleration, OpenGL would look more like Direct3D (which is
>considerably more minimalist).
No, OpenGL merely represents different programming objectives
and different reference hardware. GL grew up as a visualization
API rather than a way to code Quake clones.
[deletia]
>> > A killer app is something that most computer users will find
>> > useful.
>
>> Of course Apache is a killer app.
>
>Of course it is not.
Netcraft and the hype in general about the Web would tend
to flatly contradict you.
--
In what language does 'open' mean 'execute the evil contents of' |||
a document? --Les Mikesell / | \
Need sane PPP docs? Try penguin.lvcm.com.
------------------------------
From: Andreas Rottmann <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Is OpenGL hardware accelerated?
Date: 20 May 2000 22:44:42 +0200
[EMAIL PROTECTED] writes:
> [EMAIL PROTECTED] (Matthias Warkus) writes:
>
> > > > : 3. A DirectX-like platform for hardware-accelerated devices, not
> > > > : necessarily at the kernel level;
>
> > > > Whats wrong with OpenGL?
>
> > > The fact that it's not hardware-accelerated?
>
> > Of course it is hardware accelerated.
>
> No. It isn't.
>
> It may have the potential to be accelerated at some point in the
> future, but, as of this writing, it is not. NVIDIA has flatly stated
> that they will not be doing hardware-accelerated OpenGL until XF86
> 4.0. As XF86 4.0 is not the official XF86 at this point, there is
> not, officially, any hardware-accelerated OpenGL at this point.
>
What about Mesa-Glide?
> > The entire idea of OpenGL is wrapping hardware
> > acceleration. Everything in the OpenGL API is centred around making
> > effective hardware accelerated implementations possible.
>
> Actually, I think the entire idea of OpenGL is making available a
> high-level 3D API to the user.
>
But some part of OpenGL can be delegated to 3D hardware.
Andy
--
Andreas Rottmann (Dru@ICQ, 54523380@ICQ)
Pfeilgasse 4-6/725, A-1080 Wien, Austria, Europe
http://www.penguinpowered.com/~andy/
mailto:[EMAIL PROTECTED]
[one of 78,35% Austrians who didn�t vote for Haider!]
------------------------------
Crossposted-To:
comp.os.linux,comp.os.linux.development,comp.os.linux.development.apps,comp.os.linux.misc,comp.os.linux.setup,comp.os.linux.advocacy
Subject: Re: Need ideas for university funded project for linux
From: David Steuber <[EMAIL PROTECTED]>
Date: Sat, 20 May 2000 20:59:58 GMT
[EMAIL PROTECTED] (Matthias Warkus) writes:
' > A killer app is something that most computer users will find
' > useful.
'
' Of course Apache is a killer app.
As is KDE ;-)
--
David Steuber | Hi! My name is David Steuber, and I am
NRA Member | a hoploholic.
All bits are significant. Some bits are more significant than others.
-- Charles Babbage Orwell
------------------------------
** 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
******************************
