Linux-Development-Sys Digest #937, Volume #6      Wed, 7 Jul 99 08:14:17 EDT

Contents:
  msql memory...36M...why? ("dudesong")
  Re: C++ templates:  More than Turing Complete? (Nathan Myers)
  Re: egcs idiocy (Nathan Myers)
  Re: Why we are still holding on to MS Windows (George MacDonald)
  Re: How to get involved in driver development? (Mark Evans Jeffcoat)
  Re: Serious Trouble with AHA-2940 and new AIC Driver (David J. MacKenzie)
  Re: Why we are still holding on to X Windows (George MacDonald)
  rebuilding kernel on RedHat 5.0 (Jared Stein)
  Module: Export Symbols?!? ("Michael Knigge")
  Re: libstdc++ 2.8.1 errors? ("Thomas Steffen")
  Please don't feed the trolls (was: egcs idiocy) ("Thomas Steffen")
  Re: msql memory...36M...why? ([EMAIL PROTECTED])
  Re: Callbacks ("overflow")
  Re: Determining drive usage from C (Josef =?iso-8859-1?Q?M=F6llers?=)
  Re: Why not C++ (david parsons)
  Re: Why not C++ (david parsons)

----------------------------------------------------------------------------

From: "dudesong" <[EMAIL PROTECTED]>
Subject: msql memory...36M...why?
Date: Wed, 7 Jul 1999 11:00:40 +0900

I have used msql(Mini sql) in Linux 5.1 (Redhat)...
At recent, The memory msql have, is almost 36M.
I can't understand it.

Answer me ..please.




------------------------------

From: [EMAIL PROTECTED] (Nathan Myers)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: C++ templates:  More than Turing Complete?
Date: 6 Jul 1999 19:31:33 -0700

Davin McCall <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Nathan Myers) wrote:
>>No, that wasn't the issue I brought up.
>
>Well, that issue came up somehow. You were the one who made statements
>to the effect that it wasn't possible [to understand the principles...
>etc]. ...  And yet you claim this wasn't the issue you brought up. 
>In the context of my response, I rather think it *was*.

This discussion is getting farther and farther from the topic
originally raised, and also from the topic of any newsgroup it's
posted in, and also from anything I'm interested in. 

-- 
Nathan Myers
[EMAIL PROTECTED]  http://www.cantrip.org/


------------------------------

From: [EMAIL PROTECTED] (Nathan Myers)
Subject: Re: egcs idiocy
Date: 6 Jul 1999 19:33:58 -0700

SV <[EMAIL PROTECTED]> wrote:
>just had a wonderfull experience compiling 2.2.8 kernel with
>gcc-2.7.2.3 and then with egcs-1.1.2.
> [spew omitted]
>I feel like the whole linux is becoming just a heap
>of bugfixes piled up by a bunch of non-professional bafoons [sic]

Troll, troll.

-- 
Nathan Myers
[EMAIL PROTECTED]  http://www.cantrip.org/


------------------------------

From: George MacDonald <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why we are still holding on to MS Windows
Date: Wed, 07 Jul 1999 03:57:32 GMT

Mario Klebsch wrote:
> 
> [EMAIL PROTECTED] (John Stevens) writes:
> 
> >>As I say, there is no real standard except X11,
> 
> >And you're wrong.  This is either inadvertent FUDL, or deliberate.
> 
> >There are indeed GUI standards.  Try reading the Motif style guide, for
> >starters.
> 
> I read it, and I try to write my applications that way. But far to much
> applications are not inspired by it. I hardly can call this standard.

Hmm, isn't that why it's called a "Guide"?

Implementing a GUI as a standard is problematic because a lot of it
is subjective. It's also difficult when one considers all the issues
involved, i.e. handling monochrome/8/16/24/32 bit color, variable
resolution, different amounts of connectedness. When you look at
all the issues involved in designing X and Motif(as well as other
toolkits),
you realize that they were exceptionally well designed and implemented.

MS Windows and MacOS are obviously different because they
are implemented on stand alone "real time" OS's! They use this fact
to provide some obvious "user friendly" features based on it. When
you understand these different design approaches the resulting
solutions and the differneces become easier to grasp.


> And Motif is missing in most Linux installations...

LessTif is getting very close to completion and can be used if needed.

But this does not answer your real point. Yes X11 is a standard, and
because of it you have a tremendous ability to internetwork
applications.
It is NOT a desktop, it is NOT a toolkit and it is NOT a GUI standard.

There is Motif which was/is a very good toolkit, window manager and
GUI guide. It was a colaborative effort organized by OSF and is very
widely used and supported. Remeber it was designed over 10 years ago!
Motif is NOT a "desktop", there are no folders or objects lying
on the "desktop" ... You can add a desktop environment and then
use motif apps, there have actually been quite a few of these.

Of late there is CDE(Common Desktop Environment) which provides a
"standard" desktop agreed to by many workstation vendors. If you
get the latest Solaris, UnixWare, HPUX, ... then you get this
standard. CDE is well documented, has the usual guides and also has
levels of compliance. I first used CDE over 7 years ago and at
it's introduction it was the best desktop I had seen(especially
on a powerful workstation). If you are producing code for the
Unix workstation platforms these days, then CDE is the way to go.
Like most of the software for Unix, it is not free and must be
purchased. A version has been available for Linux for some time.
If you have not tried it, I would recommend you make the effort.
It's a very nice interface, however it now has feeware competition.

As you probably know Linux is now typically shipped with either
GNOME or KDE as the default desktop. If you have used CDE you will 
immediately notice many of the concepts(screen panels, launchers, ...).
It's actually incorrect to call these just desktops as they are
really much more, i.e. component/object based GUI
frameworks/environments.
The desktop is just one part of them(the largest part). You
might be tempted to say that there should be just one that
we can standerdize on, but attempting this is a bad idea,
here is why:

What we tend to have are interfaces that are built to the hardware
abilities of the current(or past) timeframes. These become
dated as hardware evolves. Good designs that last are highly
abstracted with good consideration for performance adjustments.
They also allow for new capabilities to be layered on without
being required. The X Window system was designed this way and
is an exceptional piece of design work.

Anyhow, the interfaces of today will look dated in 5-10 years time,
rectangles will give way to curved shapes, 2d will migrate
to 3d, static graphics will be replaced by animation, sound will
be more subtly integrated ...

So trying to adopt one GUI standard is fruitless, GUI's are simply too
subjective and too dynamic. What's important is a constant
migration to more intuative and productive interfaces that
are natural and forgiving to use. Style and personalization
will continue to grow in importance. A base level of usability 
has mostly been achieved and is now becoming mundane. So interface
designers today and in the future will have a much harder time
garnering the attention and excitement of users. Not very
conducive to creating standards eh?

Anyhow, X11 will be with us for a long time, just like rs232,
vt100(ANSI...), 802.3 .... They provide good utility value
and that's not going to change. Whatever "replaces" it is
going to have to be a quantum leap in functionality, perhaps
a networked VR mechanism... Even then you will likely find
X11 portals hanging on your VR walls...

The more interesting question is how long will MS windows last
before collapsing. It's inevitable, from what I hear MS 2000 is 
breaking a lot of MS apps. Supporting legacy code/apps must
be really stifling inovation @MS, I bet it's driving them nuts
to watch all the cool stuff happing on Linux.

-- 
We stand on the shoulders of those giants who coded before.
Build a good layer, stand strong, and prepare for the next wave.
Guide those who come after you, give them your shoulder, lend them your
code.
Code well and live!   - [EMAIL PROTECTED] (7th Coding Battalion)

------------------------------

From: [EMAIL PROTECTED] (Mark Evans Jeffcoat)
Subject: Re: How to get involved in driver development?
Date: 7 Jul 1999 03:10:34 GMT

Mike Warner ([EMAIL PROTECTED]) wrote:
: particular, I would like to develop a device driver for scsi DVD-RAM if
: one is not currently available or under development.
: 
For a (Panasonic DVD-RAM) driver currently in development, check out 
        http://mpeg.openprojects.net/panasonic.html
There's not much to it, really; the scsi driver itself does most
of the work.

Mark Jeffcoat

------------------------------

From: [EMAIL PROTECTED] (David J. MacKenzie)
Subject: Re: Serious Trouble with AHA-2940 and new AIC Driver
Date: 06 Jul 1999 23:35:24 -0400

[EMAIL PROTECTED] (Harald Grabow) writes:

> Although this would make this Mail redundant, I deeply hope this is a  
> known Problem.

Problem known, solution not clear :-( I have a 2940U; fine with Win95/98,
constant SCSI bus resets with RedHat 6.0/kernel 2.2.5.  Suse 5.3/kernel 2.0.35
came with 3 different versions of the driver, only the newest of which worked.

> The Problem persists with all Kernel versions *HIGHER* 2.0.34 and the AHA- 
> 2940 FAST-SCSI Adapter w/ NVRAM, BIOS Version 1.21 (the only one I have)
> To me it looks like the almost-complete-rewrite made since then has broken  
> something in the Area of the Sequencer.
> 
> While reading this i realize it sounds like a SCSI-Newbie-Insufficent- 
> Termination-Or-Something-Problem, I may assure you it is *not*.

All the suggestions I've seen are "use active termination on external
SCSI devices".  So if that's not your problem, no one's posted any relevant
help that I've seen.

> I would be very pleased if this Problem could be dealt with, and would  
> like to know if other people are experiencing the same trouble with their  
> 2940, and how they got around it.

I got around it by getting a Symbios SCSI adapter.

------------------------------

From: George MacDonald <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
Date: Wed, 07 Jul 1999 04:13:57 GMT

Mario Klebsch wrote:
> 
> [EMAIL PROTECTED] (Mike McDonald) writes:
> 
> >  Second, X isn't suppose to have a "style guide".
> 
> It does not matter, wether X is supposed to have a style guide. a GUI
> does need a stype guide, especially if it is spread around several
> distinct programs.
> 
> Well, one could argue, wether a user interface violating a style guide
> is not graphical, but it is one of the most important benefits of common
> graphical user interfaces, that the user can have knowledge from appli-
> cation A to use application B.
> 
You are being to literal in your interpretation of this "guideline".
What is more important is that a program performs a desired function
and is consistent in the way it does it. Some key things are of
course important and should always be the same(i.e. I press a
key and the same character is generated ...). But just like a car,
there are many knobs/dials/buttons that are non standard, yet
they are still intuative and useful.

Human beings are modal and context sensitive, but not overly so.
Predictability is a big thing in user interfaces thus being able
to bring along tools that users are familier with is important.
That said new users should not have to deal with older tools,
so newer upto date tools should also be provided. One sees this
with GNOME/KDE, as the both have newer icon editors, yet the
older "bitmap" program is still available. So Gnome and KDE
should and do have style guides.


> >  You're real problem is not that there isn't one written done for Unix/X11
> >but that there are too many. A completely different problem.
> 
> You call it too many standards, I call it absence of standard. How do
> you call something standard, if it is not agreed upon?

If you are looking for "one" universal interface, you will have a long
search. Even with complete control MS can't achieve this, look at
the changes between 3.1, 95, 98, NT3.5, NT4.0, CE ... Unix and Linux
in particular are much more open. This is a *good* thing as it allows
for progress at the speed of innovation and *not* at the slower speed
of business.

-- 
We stand on the shoulders of those giants who coded before.
Build a good layer, stand strong, and prepare for the next wave.
Guide those who come after you, give them your shoulder, lend them your
code.
Code well and live!   - [EMAIL PROTECTED] (7th Coding Battalion)

------------------------------

From: Jared Stein <[EMAIL PROTECTED]>
Subject: rebuilding kernel on RedHat 5.0
Date: 7 Jul 1999 05:55:15 GMT

I have RedHat 5.0 and I want to recompile the kernel.  I've tried all the 
commands that the books I have list, but nothing works.  Please let me 
know what packages I need and where I can get them.  Also, the books I 
have list two different methods of rebuilding.  Could someone help me with 
the "proper" method?  I am mainly confused about the make commands 
they are different in each.  The books I have don't explain what all 
those make commands do, they just tell you to type them.  I understand 
why the one says to move the old modules so that you can have a dual 
boot with the old and the new kernel.  I'll list the methods I have below.  
Thanks for your time.  I would prefer any replies by email.

"The Complete Idiot's Guide To Linux" suggests:
make menuconfig
make dep
make clean
make zImage
make modules
cp /usr/src/linux/arch/i386/boot/zImage /boot/vmlinuz-2.0.35-new
mv /lib/modules/2.0.35 /lib/modules/2.0.35-old
make modules_install
mv /lib/modules/2.0.35 /lib/modules/2.0.35-new
mv /lib/modules/2.0.35-old /lib/modules/2.0.35
[edit lilo.conf]
lilo -v
find /lib/modules/2.0.35-new -name "*.o" -print > 
"/etc/modules/2.0.35/$(uname -v).default"
[reboot]

"Linux For Dummies" says:
cd /usr/src/linux
make menuconfig
make dep;make clean
make vmlinux
make modules
make modules_install
[edit lilo.conf]
lilo
[reboot]


I would prefer replies by email.
-- 
====================================
Jared Stein
Precision Computer Services
[EMAIL PROTECTED]
====================================

------------------------------

From: "Michael Knigge" <[EMAIL PROTECTED]>
Subject: Module: Export Symbols?!?
Date: Wed, 7 Jul 1999 09:27:36 +0200

Hi all,

I�ve problems using a Kernel Module. I added the line
"EXPORT_SYMBOL(my_function);" to the source (Module A)

When I load another Module (Module B), that requires the
function of "Module A" (using insmod), I get the Message

unresolved symbol my_function

Why?  I�m running Kernel 2.2.5 (but also tried with 2.2.8,
2.2.9 and 2.2.10) and GCC 2.7.2.3.

Width this commands I build "Module A"
cc -D__KERNEL__ -DMODULE -O -Wall -I/usr/src/linux/include -c mod1.c -o
mod1.o
cc -D__KERNEL__ -DMODULE -O -Wall -I/usr/src/linux/include -c mod2.c -o
mod2.o
cc -D__KERNEL__ -DMODULE -O -Wall -I/usr/src/linux/include -c mod3.c -o
mod3.o
ld -r mod1.o mod2.o mod3.o -o mymodule.o

(BTW, I am Using GNU ld version 2.9.1 (with BFD 2.9.1.0.19)).


My "Module B" (that uses the exp. funcs of "Module A") is a
"single-file-module"
and is compiled with this command:
cc -D__KERNEL__ -DMODULE -O -Wall -I/usr/src/linux/include   -c testmod.c -o
testmod.o

Then I try to load the Modules:

# insmod mymodule
# insmod testmod
/lib/modules/2.2.5/net/testmod.o: unresolved symbol myfunc

Can anybody help me?

Thanx a lot!

bye
  Michael



------------------------------

From: "Thomas Steffen" <[EMAIL PROTECTED]>
Subject: Re: libstdc++ 2.8.1 errors?
Date: 07 Jul 1999 08:57:15 +0200

"Kyle Howell" <[EMAIL PROTECTED]> writes:

> I am having a problem that is apparently originating from libstdc++ 2.8.1.1.
...
> and all of the self-tests pass. I am still running gcc 2.7.2 (or whichever
> version was installed with RH5.2), 

imho you have to use that same version for g++ and libstdc++. this is
because the very tight integration between library and compiler (not
inlined primitives). eg, __ti9exception is defined in 

  /usr/lib/gcc-lib/sparc-sun-solaris2.7/egcs-2.91.60/libgcc.a

you might also succeed rebuilding this library, but this is not
recommended. newer glibc's need egcs. 

-- 
linux, linuctis - f, das beste Betriebssystem ;-) 

------------------------------

From: "Thomas Steffen" <[EMAIL PROTECTED]>
Subject: Please don't feed the trolls (was: egcs idiocy)
Date: 07 Jul 1999 08:31:10 +0200

either we have some arguments, some test cases and some details about
optimisation and result, or this is going to be a very long thread
with very little outcome (yes, i know that the poster has made about a
dozen mistakes).

-- 
linux, linuctis - f, das beste Betriebssystem ;-) 

------------------------------

From: [EMAIL PROTECTED]
Subject: Re: msql memory...36M...why?
Date: Wed, 07 Jul 1999 09:37:31 GMT

On Wed, 7 Jul 1999 11:00:40 +0900, "dudesong" <[EMAIL PROTECTED]> wrote:

> I have used msql(Mini sql) in Linux 5.1 (Redhat)...
> At recent, The memory msql have, is almost 36M.
> I can't understand it.
> 
> Answer me ..please.

You neglected to name the version :

I've tested 2.0.8 fine under RedHat 5.0 to 6.0 fine.

M.

------------------------------

From: "overflow" <[EMAIL PROTECTED]>
Subject: Re: Callbacks
Date: Wed, 7 Jul 1999 12:33:57 +0200


Emile van bergen escribi� en mensaje ...
>On Sun, 4 Jul 1999, overflow wrote:
>
>>I want to do a callback to real mode in order to talk to the BIOS. Does
>>anybody know how to do it in Linux?
>
>It is not done in Linux (yes, interpret this both ways). Luckily. The
>bios is not used at all, except at boot time (before entering protected
>mode) to gather some information about the system, and for some
>PCI-related things (for which protected mode entry points exist). There
>were some rumours about a hack to have the IDE-driver use the bios to
>support some oddball storage media, but that's just what they were,
>rumours and hacks.
>
>If you're writing your own device driver, plan to do so yourself I
>guess, instead of letting the BIOS handle the gory details.
>
>--


The problem is that I have to use the BIOS because I'm writting the
framebuffer driver for generic VESA devices. There are some functions that
can be done through a protected mode entry point, but others do not.

Jaime Medrano
Eurielec Linux




------------------------------

From: Josef =?iso-8859-1?Q?M=F6llers?= <[EMAIL PROTECTED]>
Subject: Re: Determining drive usage from C
Date: Wed, 07 Jul 1999 13:01:40 +0200

Adam the Amazing wrote:
> =

> Is there some C function I can call to determine how much free space is=

> on a particular hard disk partition?

man statfs

> thanks,

You're welcome,

Josef
-- =

PS Die hier dargestellte Meinung ist die persoenliche Meinung des
Autors!
PS This article reflects the autor=B4s personal views only!

------------------------------

From: o r c @ p e l l . p o r t l a n d . o r . u s  (david parsons)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 7 Jul 1999 01:10:19 -0700

In article <7l6ah0$cu1$[EMAIL PROTECTED]>,
Nathan Myers <[EMAIL PROTECTED]> wrote:
>NF Stevens <[EMAIL PROTECTED]> wrote:
>>[EMAIL PROTECTED] (Nathan Myers) wrote:
>>>
>>>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.
>>
>>That was not the point. I was comparing the code generated
>>by instanciation of a template with hand written C++ code.
>>The fact that templates expand to C++ code means that
>>_templates_ cannot improve the efficiency of code.
>
>But C++ templates _don't_ expand (macro-like) to C++ non-template
>code.  They expand to (if you will) RTLs, full of juicy details
>for the optimizer that would be lacking in the otherwise-equivalent
>hand-written C++ (or C) code.

   That is, I hope, a feature of an implementation, not the language;
   even Java, which takes nanny-state handholding to new extremes,
   doesn't dare specify how a compile should proceed as part of the
   language.

                 ____
   david parsons \bi/ Templates are very very sophisticated #defines
                  \/

------------------------------

From: o r c @ p e l l . p o r t l a n d . o r . u s  (david parsons)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 7 Jul 1999 01:14:53 -0700

In article <[EMAIL PROTECTED]>,
John Stevens <[EMAIL PROTECTED]> wrote:
>On 1 Jul 1999 20:47:54 -0700, david parsons <[EMAIL PROTECTED]> wrote:
>>In article <[EMAIL PROTECTED]>,
>>Bruce Hoult <[EMAIL PROTECTED]> wrote:
>>
>>>Dylan is not several hundred percent slower than C as Java is.
>>
>>    Have you benchmarked Java vs C on the same machine?  (No, I don't
>>    mean benchmarking C on a machine vs Java running on a p-machine
>>    on that machine);  there's certainly nothing in the design of
>>    Java that would make it much slower than C on the same machine.
>
>Excuse, but:
>
>Java, even compiled to machine code, will be slower than C or C++.

     I presume you have experimental evidence that supports this claim.
     Care to share it?

>Java requires a run time system (ala Objective-C), making it both more
>dynamic, and slower.

     Care to enumerate exactly how this make it slower?
     Inquiring minds, doncha know.

                   ____
     david parsons \bi/ I can think of one runtime (garbage collection) feature
                    \/      that has the potential of dropping hammers into the
                          work, but there are some pretty clever GC's out there

------------------------------


** 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
******************************

Reply via email to