Linux-Development-Sys Digest #885, Volume #7 Sat, 20 May 00 23:13:12 EDT
Contents:
Re: Need ideas for university funded project for linux (David Steuber)
Re: Determining amount of physical RAM from a driver? (Rick Ellis)
Re: serial port RTS control ? ("Fred")
Re: Need ideas for university funded project for linux (Leslie Mikesell)
Re: Need ideas for university funded project for linux (JEDIDIAH)
Re: Need ideas for university funded project for linux ([EMAIL PROTECTED])
Re: Need ideas for university funded project for linux (Leslie Mikesell)
Re: Why no defrag? (Juergen Heinzl)
Re: linux kernel not C++ friendly? (Juergen Heinzl)
Re: Can compile with c++ but not with gcc (Nix)
Re: Why no defrag? (Andreas Rottmann)
Re: Need ideas for university funded project for linux (David Steuber)
Re: Need ideas for university funded project for linux (JEDIDIAH)
Re: Need ideas for university funded project for linux (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
From: David Steuber <[EMAIL PROTECTED]>
Date: Sat, 20 May 2000 20:59:59 GMT
[EMAIL PROTECTED] (Matthias Warkus) writes:
' 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.
I looked at it a while back. Perhaps it was too long ago to be a fair
comparison. I'll look at it again. If it can do all the Qt things
just as well, perhaps I will switch.
There is a limit to the number of class libraries I can learn. I only
plan to use one for application development in an X environment.
--
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
------------------------------
From: [EMAIL PROTECTED] (Rick Ellis)
Subject: Re: Determining amount of physical RAM from a driver?
Date: 20 May 2000 21:14:35 GMT
In article <8fcimq$vis$[EMAIL PROTECTED]>,
Timur Tabi <[EMAIL PROTECTED]> wrote:
>What happens if the user installs or removes memory after the driver is
>installed?
Most hardware won't let you do that.
--
http://www.fnet.net/~ellis/photo/linux.html
------------------------------
From: "Fred" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.setup
Subject: Re: serial port RTS control ?
Date: Sun, 21 May 2000 00:10:02 +0200
Reply-To: "Fred" <[EMAIL PROTECTED]>
> Yes it is. When its input buffer is full, the host driver will assert RTS
> to tell the other end to stop transmitting.
Really ? I'm not sure !
RTS means "Request To Send" so it must be activate *before* sending data and
wait for "Clear To Send", isn't it ?
> >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.
IMHO, the timing diagram is something like that :
(Please view in a fixed-width font such as Courier)
RTS (out)---+ +-----
| |
+-------------------------+
CTS (in)-----+ +-----+ +----
| | | |
+-----------+ +------+
+----------+ +---+
| | | |
TxD (out)------+ +------+ +------
A A A
| | |
Transmit Receiver Transmit
BEGIN Buffer full END
Fred
(France)
------------------------------
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 17:37:50 -0500
In article <[EMAIL PROTECTED]>,
JEDIDIAH <[EMAIL PROTECTED]> wrote:
>>>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...
You need them IF you have installed a modern distribution that
already includes the thing you are updating, and you want
it all to work the same after you apply your fix.
>[deletia]
>
> The point of automation is to avoid such manual futzing.
You do avoid it if you wait till someone else does it and
then just install the packaged version. If you have some
reason to need a fix the day a patch is out or need some
local changes until the next release, you need the futzing
but with the rpm scheme even most of the futzing is automated.
Les Mikesell
[EMAIL PROTECTED]
------------------------------
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 22:46:43 GMT
On 20 May 2000 17:37:50 -0500, Leslie Mikesell <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>JEDIDIAH <[EMAIL PROTECTED]> wrote:
>
>>>>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...
>
>You need them IF you have installed a modern distribution that
>already includes the thing you are updating, and you want
Who said anything about 'updating'. I'm talking about the
'new' stuff I compile. I typically don't bother with source
for more stable projects.
>it all to work the same after you apply your fix.
>
>>[deletia]
>>
>> The point of automation is to avoid such manual futzing.
>
>You do avoid it if you wait till someone else does it and
>then just install the packaged version. If you have some
Is this supposed to be describing binary packages or
makefiles, as I've always thought of reasonably
complete source packages as serving this purpose.
>reason to need a fix the day a patch is out or need some
>local changes until the next release, you need the futzing
>but with the rpm scheme even most of the futzing is automated.
Where I've found rpm most useful are those projects that
seem to be made of a million or so parts and doing a
'build World' is a manual process.
--
In what language does 'open' mean 'execute the evil contents of' |||
a document? --Les Mikesell / | \
Need sane PPP docs? Try penguin.lvcm.com.
------------------------------
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 22:59:29 GMT
[EMAIL PROTECTED] (JEDIDIAH) writes:
[is OpenGL 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.
Sorry. I was operating under outdated information.
You're right; it is the official XF86. (I must've checked its status
the day before it was released...)
> >> > 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.
I really don't see what's so hard to understand here.
Here are some requirements for a killer app:
1. Lots of people have to use it.
2. Lots of people have to know about it.
Obviously, then, to be a potential killer app, a program must appeal
to lots of people.
Does Apache appeal to lots of people?
No. I'm sorry, but this is bloody obvious, and I really don't
understand how anyone can argue with it. The vast - *VAST* - majority
of computer users have not installed Apache, and never *will* install
Apache, no matter that it's the best thing since sliced bread.
There's just no purpose to it.
Having lots of people use Apache in the sense of getting Web pages
through it (like, over the 'net) does not qualify it as a killer app.
The only people who count, numbers-wise, are the ones who administer
it, and that's never going to hit anywhere near a large enough figure
for Apache to be a killer app.
You may make the claim that a killer app only has to draw lots of
people, relative to the audience an OS (or arch, or whatever)
currently enjoys, and that's fine. But Apache is never going to draw
people to Linux, since it's available in stable and up-to-date form on
many other OSes.
--
Eric P. McCoy ([EMAIL PROTECTED])
non-combatant, n. A dead Quaker.
- Ambrose Bierce, _The Devil's Dictionary_
------------------------------
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 18:07:12 -0500
In article <[EMAIL PROTECTED]>,
JEDIDIAH <[EMAIL PROTECTED]> wrote:
>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.
Of course. GPL advocates were the ones who pushed for this
change and they don't like the LGPL much.
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why no defrag?
Date: Sat, 20 May 2000 23:39:03 GMT
In article <[EMAIL PROTECTED]>, Christian Winter wrote:
>In comp.os.linux.development.system schrob Mark Tranchant <[EMAIL PROTECTED]>:
>> The consciencious user would defrag all filesystems regularly,
>> and feel "clean" after doing so!
>
>Nice aspect. Maybe one problem for Linux in getting more popular
>is that it does all those things automatically?
[...]
It does not and fragmentation, still, occurs as it has got nothing
to do with the OS itself.
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Subject: Re: linux kernel not C++ friendly?
Date: Sat, 20 May 2000 23:39:04 GMT
In article <[EMAIL PROTECTED]>, Kaz Kylheku wrote:
>On Fri, 19 May 2000 00:41:33 +0200, Stefaan A Eeckels <[EMAIL PROTECTED]>
>wrote:
>>In article <[EMAIL PROTECTED]>,
>> Travis Hein <[EMAIL PROTECTED]> writes:
>>> I am very new to this linux world, and the art of building kernel modules.
>>> I noticed when i ran the c++ compiler on even the most trivial of kernel
>>> modules, some kernel include files make use of c++ predefined operators, like
>>> new, class, etc.
>>>
>>> Thus leading me to wonder, if a kernel module could not be developed using C++
>>> classes and structures?
>>Short answer: No.
>>
>>Medium sized answer: You could, but you'd have to provide all the
>>run time support usually provided by C++'s support libraries, and
>>libc. You don't want to do this.
>
>I just wrote a module in C++ and it loaded just nicely into 2.2.12.
>
>Here is the module:
>
> #include <stddef.h>
> #include <linux/config.h>
> #include <linux/module.h>
> #include <linux/kernel.h>
>
> void *operator new (size_t) {
> }
[...]
Why ?
>
> void operator delete (void *ptr) {
> }
[...]
Why ?
>
> class myclass {
> public:
> myclass() { printk(KERN_INFO "myclass::myclass\n"); }
> ~myclass() { printk(KERN_INFO "myclass::~myclass\n"); }
> };
>
> extern "C" int init_module()
> {
> myclass dummy;
> printk(KERN_INFO "foo_init\n");
> return 0;
> }
>
> extern "C" void cleanup_module()
> {
> myclass dummy;
> printk(KERN_INFO "foo_cleanup\n");
> }
>
>I compiled this with g++ -fno-exceptions -D__KERNEL__ -DMODULE test.cc -c
>
>When I insert it into the kernel, it produces trace messages indicating
>that the dummy objects are being constructed and destroyed.
>
>What library features am I missing? Are you saying I need things like
><iostream> or the STL in order to use C++? That's not true any more than
>that I need strftime(), qsort(), frexp() or wcstombs() in order to do kernel
>programming in C.
[...]
No, it is not true but as C++ is about generic programming, no idea where
all that OO waffle is coming from, it is also more a proof of concept.
For instance one could use templates to benefit from the compilers'
ability to generate code. At the same time mostly useless if one does
not have the need to develope a whole set of modules.
Hiding things within classes is not that much of a big win either and
usually a kernel module is not of the size of the kernel itself, but
C++ shines most if it comes to large scale projects.
Minor and moot point .. GNU g++ is not a C++ compiler anyway as it
does not implement the current standard, so the source for a module
might quite well not compile given a, more or less, older version
of the compiler on someone else' machine.
At the end of the day ask yourself what you want to achieve as the
proof using C++ for kernel modules is possible is ... yawn ...
Cheers,
Juergen
--
\ Real name : J�rgen Heinzl \ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
------------------------------
From: Nix <$}xinix{[email protected]>
Subject: Re: Can compile with c++ but not with gcc
Date: 20 May 2000 23:27:33 +0100
David Kirkpatrick <[EMAIL PROTECTED]> writes:
> gcc ist the frontend of the C-Compiler. So it doesn't link the C++
> standard library ( which contains cout) automatically and you will
> need to add a -lstdc++ to link with that library.
The `c++' or `g++' frontends do this automatically.
--
`Q: Why did they deprecate a.out support in linux?
A: Because a nasty coff is bad for your elf.' --- James Simmons
------------------------------
From: Andreas Rottmann <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why no defrag?
Date: 21 May 2000 02:09:22 +0200
[EMAIL PROTECTED] (Juergen Heinzl) writes:
> In article <[EMAIL PROTECTED]>, Christian Winter wrote:
> >In comp.os.linux.development.system schrob Mark Tranchant <[EMAIL PROTECTED]>:
> >> The consciencious user would defrag all filesystems regularly,
> >> and feel "clean" after doing so!
> >
> >Nice aspect. Maybe one problem for Linux in getting more popular
> >is that it does all those things automatically?
> [...]
>
> It does not and fragmentation, still, occurs as it has got nothing
> to do with the OS itself.
>
It does shurely not defragment automagically, but it is more clever in
not fragmenting files than FAT-based systems. And yes, fragmentation
still happens, but it is so little that its not critical to
performance.
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: Sun, 21 May 2000 03:00:00 GMT
[EMAIL PROTECTED] writes:
' > 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.
This is a function of your video hardware as well as the drivers and
what systems the drivers are available for. The GLINT chips that are
on many video cards are hardware accelerators for OpenGL. I'm sure
SGI boxes have hardware accelerated OpenGL.
OpenGL has, what, ten primatives? It _was_ designed for hardware
acceleration.
' 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).
Direct3D is a rip off of OpenGL soley for the purpose of tying people
into the Microsoft architecture. It is a direct result of The
Microsoft Method (do a deja search on that).
--
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
------------------------------
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: Sun, 21 May 2000 03:00:51 GMT
On Sat, 20 May 2000 22:59:29 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>[EMAIL PROTECTED] (JEDIDIAH) writes:
>
>[is OpenGL hardware-accelerated?]
SGI's has been hardware-accelerated for longer than Direct3D has
existed. Mesa has been hardware-accelerated for a couple years now.
XiG's GL implementation just became hardware-accelerated and the new
SGI workstations with the Nvidia Quadros will be hardware-accelerated
under OpenGL under Linux.
>
>> >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.
>
>Sorry. I was operating under outdated information.
>
>You're right; it is the official XF86. (I must've checked its status
>the day before it was released...)
>
>> >> > 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.
>
>I really don't see what's so hard to understand here.
>
>Here are some requirements for a killer app:
>
>1. Lots of people have to use it.
60% marketshare of the server part of THE current
killer microcomputer app.
>2. Lots of people have to know about it.
>
>Obviously, then, to be a potential killer app, a program must appeal
>to lots of people.
>
>Does Apache appeal to lots of people?
With a 60%, I would imagine it does.
>
>No. I'm sorry, but this is bloody obvious, and I really don't
>understand how anyone can argue with it. The vast - *VAST* - majority
No, your obstinance is not 'bloody obvious'.
>of computer users have not installed Apache, and never *will* install
>Apache, no matter that it's the best thing since sliced bread.
True, however the VAST MAJORITY of computer users USE
Apache on a daily basis.
[deletia]
Your position is just as aburd as claiming that OSS 'hasn't
delivered' while ignoring sendmail, bind and BSD sockets.
--
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: Sun, 21 May 2000 03:01:17 GMT
On 20 May 2000 18:07:12 -0500, Leslie Mikesell <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>JEDIDIAH <[EMAIL PROTECTED]> wrote:
>>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.
>
>Of course. GPL advocates were the ones who pushed for this
>change and they don't like the LGPL much.
Bullshit.
--
In what language does 'open' mean 'execute the evil contents of' |||
a document? --Les Mikesell / | \
Need sane PPP docs? Try penguin.lvcm.com.
------------------------------
** 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
******************************
