Linux-Development-Sys Digest #306, Volume #6 Tue, 19 Jan 99 17:14:38 EST
Contents:
Re: disheartened gnome developer (Navindra Umanee)
Re: introduction on device driver programming (Keramidas Giorgos)
Re: disheartened gnome developer (USEnet Subsystem)
linux shared libs ("Wai Wu")
Re: disheartened gnome developer ([EMAIL PROTECTED])
Will 2.2.x support removable medias better? ([EMAIL PROTECTED])
Kernel 2.2.0pre6 crashes permanently (Uwe Brandt)
Re: What about "Linux.. the home game"?? (a consumer version) (Marco Al)
Re: 6 questions on disk files ("Bjorn Wesen")
----------------------------------------------------------------------------
From: Navindra Umanee <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: 19 Jan 1999 15:05:24 GMT
[followups set to .advocacy]
Perry Pip <[EMAIL PROTECTED]> wrote:
> Irrelevent to my point. If you support Qt/KDE, you are enhancing the value
> of Qt, a commercial product. You are not an *equal* party in the software
> license contract. If you support Gtk/Gnome, you are supporting the Gnu
> Project, a non-profit organization who's goal is to develop a free OS,
> libraries, applications, etc. It just so happens Redhat is supporting the
Yeah, an organization that insists that you assign copyright of the
code back to the FSF before said code gets integrated back into
something like, say, Emacs. An organization that refuses GPL'ed code
copyrighted by Sun so that we end up with XEmacs. FSF ain't so cool
either, if you ask me.
[That being said, GCC, Emacs,... rock. As does Qt.]
> Redhat has put out more lines of code under GPL/LGPL than Troll Tech has
> put out total. AFIAC, Troll Tech is cheesey.
What a ridiculous statement. Oh btw, if you use Mozilla you are
enhancing the value of Netscape. But I'm sure you're using a GPL'ed
browser like Lynx as all good little boys should.
>>> And I can't help but notice that on freshmeat I see so many
>>
>>[asimov] [/home/navindra] host -t any freshmeat.net
>>freshmeat.net NS NS.REDHAT.COM
>>freshmeat.net NS SPEEDY.REDHAT.COM
I just couldn't help "notice" this fact either. Didn't even comment it.
[undeniably, there are many GTK apps]
Oh, I wonder if the FSF will ask that the Gimp ToolKit be renamed to
the GNU ToolKit.
-N. (talk about FUDing)
--
"These download files are in Microsoft Word 6.0 format. After unzipping,
these files can be viewed in any text editor, including all versions of
Microsoft Word, WordPad, and Microsoft Word Viewer." [Microsoft website]
< http://www.cs.mcgill.ca/~navindra/editors/ >
------------------------------
From: Keramidas Giorgos <[EMAIL PROTECTED]>
Subject: Re: introduction on device driver programming
Date: Tue, 19 Jan 1999 19:22:27 +0200
Joerg Schueler wrote:
>
> Hi folks,
>
> does anybody know a good web page or paper on device driver programming
> ? I just need an introduction on the basics in that.
>
> Thanks
> Joerg
Allessandro Rubini't book "Linux Device Drivers" from O'Reilly
seems to be the next best thing you can get your hands on
now---the linux kernel sources being THE absolute documentation
on the subject, of course.
The edition I got of the book is one of January 1998, but most
of the stuff applies to 2.1.x kernels too, to some reasonable
extent. For 2.2.0pre? info, well...
The Source is Out There
--
Georgios E. Keramidas <[EMAIL PROTECTED]>
"What we have to learn to do, we learn by doing."
(Aristotle : Ethica Nicomachia)
------------------------------
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
From: [EMAIL PROTECTED] (USEnet Subsystem)
Subject: Re: disheartened gnome developer
Date: Tue, 19 Jan 1999 14:53:58 GMT
<77tkbh$5i9$[EMAIL PROTECTED]>
From: [EMAIL PROTECTED] (Houben S.H.M.J.)
In <77tkbh$5i9$[EMAIL PROTECTED]> [EMAIL PROTECTED] writes:
> Gnome
>just happens to be the easiest path to a toolkit binding for their language.
Gnome is the desktop environment, the toolkit is GTK.
(This might seem a nitpick, but it is essential, because Gnome is
beta, whereas GTK isn't.)
>And that's exactly what the Gnome developers wanted. But since Gnome is not
>complete, it follows that the bindings are even less complete.
Gnome is not complete. But GTK (the toolkit) has a stable 1.0 release.
>I have seen some GTK apps in Perl, Python, and C++. But even those binding
>are incomplete at this time, so it's only natural the majority of GTK apps at
>this time are in C.
While this may be true, it is not caused by the incompleteness of GTK itself.
Moreover, if the process of creating the bindings is pretty straightforward,
the incompleteness of the bindings is less of an issue, since the programmer
can easily wrap up that little extra functionality (s)he needs.
> But I don't think we will see less apps in C,
Well, no, unless some apps get lost due to bad back-up media ;-)
(OK, you mean *new* apps...)
OK, here is my 0.05 Euro. ;-)
One of the cool things of GTK is that it is rather easy to make a
language wrapper. This is *partially* due to the fact that GTK is
written in C. If you take your random obscure programming language,
you will note that it probably has some interface with C, but not
directly with C++. Of course, C++ is kind of a superset of C, but if
the library in question (the toolkit) contains lots of C++-specific
things, you will have to wrap this stuff up in the C subset of the
language.
Moreover, and I think that this is an even more important reason
why the author of the language wrapper would prefer GTK over QT,
a C compiler is a pretty standard part of any *nix distribution,
while a C++ compiler is something that, in general, only C++
programmers have installed. So if I want to enrich the language
foobar with a toolkit, I would prefer a C toolkit (foobar
programmers probably already have a C compiler, and anyway, they
need one because it forms the back end of foobar's compilation
process) over a C++ toolkit (which requires a big C++ compiler
they don't need for anything else). Since neither C or C++ will be
used to do the bulk of the programming (most will be done in
foobar), the possibly clearer syntax of the C++ toolkit is
hardly an issue.
So what was the point of all this? Well, basically why someone
would prefer a C library over a C++ library with equivalent
functionality, and more specifically, why someone might prefer
GTK over QT. Mind you, there are some people in the world who
think that both C and C++ stink^H^H^H^H^H are suboptimal for
application-programming tasks, and would prefer foobar for
that kind of job.
Greetings,
Stephan Houben
--
S.H.M.J. Houben
Philips Research Laboratories
Building WAY, Prof. Holstlaan 4, 5656 AA Eindhoven, The Netherlands
------------------------------
From: "Wai Wu" <[EMAIL PROTECTED]>
Subject: linux shared libs
Date: 19 Jan 1999 19:42:02 GMT
Hi,
Does any one know if a shared lib gets loaded by two different processes,
how many copys of it (e.g. code) are actually loaded into memory?
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.advocacy,comp.os.linux.development.apps,comp.os.linux.x
Subject: Re: disheartened gnome developer
Date: Tue, 19 Jan 1999 15:31:04 GMT
In article <5WRo2.13962$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] wrote:
> On Mon, 18 Jan 1999 15:39:04 GMT, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
> >In article <[EMAIL PROTECTED]>,
> > [EMAIL PROTECTED] wrote:
> >> On Fri, 15 Jan 1999 16:55:09 GMT, [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> >> posted:
> >> >In article <77h02o$bg6$[EMAIL PROTECTED]>,
> >> > [EMAIL PROTECTED] wrote:
> >> >> On Sat, 09 Jan 1999 14:48:45 GMT, [EMAIL PROTECTED]
> >> >> <[EMAIL PROTECTED]> wrote:
> >> >> >Red Hat does own the code they create, just like Troll Tech and
Microsoft.
> >> >> >That you have a copy of it under the GPL doesn't mean they can't later
> >> >> >re-release it under a proprietary license.
> >> >>
> >> >> Technically, that's true.
> >> >>
> >> >> Unfortunately for such a release, they cannot "de-release" the software
> >> >> already released under the GPL, which means that the software that they
> >> >> have written will continue to be freely available (barring *bizarre*
> >> >> events) and could be maintained, moving forward by others.
> >> >
> >> >Sure. Technically :-)
> >> >Then again, usually when a program with a low "cool factor" like, say,
> >> >a Tk front end to network configuration gets fropped it often just stays
> >> >dropped. Even high profile projects like the GIMP had a rough season
> >> >after the original maintainers dropped it (things a re better now,
> >thankfully)
> >>
> >> Indeed. If nobody cares about the software, if some "catastrophe" strikes,
> >> no one will notice.
> >
> >It is very possible that many people care and notice, and still they can't
> >take it over. Like in the GIMP example. People who use it are mostly not
> >programmers.
>
> If they care a whole lot, they can hire a programmer to fix/update the
> software. There may be substantial cost to that, but it is at least:
> a) Permissible, and
> b) Does not require obtaining a license from a third party.
As you said in another post: it's extremely unlikely that such a thing
(hiring a programmer) will ever happen, so we can treat it as impossible.
And having permission to do impossible things is not very useful ;-)
> >> Red Hat "dropped" some Python/Tk configuration tools, in favor of
> >> supporting Linuxconf; that happened with barely a whimper, as nobody
> >> really cared very much, or was terribly inconvenienced by the "loss."
> >> I have a hard time caring, myself. There are better things to expend
> >> emotional energy on.
> >
> >Sure. But that's not dropping, it's replacing.
> >We were discussing things like "Red Hat goes propietary". In that case,
> >you don't get linuxconf, you get the old Python/Tk tools and no maintainer.
>
> I wasn't aware that Linuxconf was a proprietary product of Red Hat
> Software any more than the former Tk/Python tools were.
I think we have some communication troubles (maybe I am on one of my cryptic
phases), but the "old Python/Tk tools" are not linuxconf.
You of course still can have linuxconf from Jacques Gelinas as you have been
able to get it for a long time.
Then again, having linuxconf doesn't improve the abandoned old tools.
> The last time I
> visited the Linuxconf web site, the main developers weren't even in the
> same *country* as Red Hat Software.
Sure.
> I don't have license handy, but I thought that Linuxconf was also either
> GPLed or LGPLed, thus meaning that if Red Hat "goes proprietary,"
> Linuxconf is something that you *do* "get." If I'm wrong, feel free to
> quote from the license.
Ahem, I will just say that I was meaning something completely different,
and attribute it to my lack of communication skills.
I'll try again: if Red Hat (or anyone) stops developing the free version of
a particular piece of software, that has no shining "cool value" or that
is of no use for hackers, or that is a very complex thing, it is likely
that such a piece of software will just linger for ever.
Case: Trinket. Trinket was a cool TCL-less python/Tk binding.
Way faster and cooler than the standard Tkinter. Maintainer dropped it,
development died. Instantly.
> >> >> Troll Tech has a legal arrangement whereby if "disaster strikes," a
> >> >> scenario similar to the above is invoked. Red Hat has already invoked
> >> >> the "disaster clause."
> >> >
> >> >Not exactly, since the result of that "disaster clause" is not the
> >> >release under the GPL of the software in Troll tech's case.
> >>
> >> A *precise* parallel? No.
> >>
> >> Relatively similar? I'd think so. The GPL and BSDL have different
> >> sorts of restrictiveness; both are commonly regarded as representing
> >> "free" software. Albeit with some noisy dissenters.
> >
> >The GPL is "free with strings attached" BSDL is free.
> >Some people don't care about the strings, some people like the strings, but
> >there are strings :-)
>
> BSDL has a different set of strings. If we're talking about the
> "formal" BSDL, there is a requirement of authorship disclosure that is a
> string. RMS has flamed the BSDL for this reason.
Well, that is not the license that would get applied to Qt.
Feel free to read the right one from www.troll.no (no adv. clause).
> And there's the "string" that someone can take BSDL code and produce
> entirely proprietary results, which some people apparently object to.
That is no string, that is unexistence of a particular string :-)
> <tone tongue="in cheek"> That "free" code can be captured and "enslaved"
> by evil corporate folk to horrible proprietary purpose... </tone>
>
> And there are those that dissent in both directions, as I said.
Sure.
--
Roberto Alsina (KDE developer, MFCH)
============= Posted via Deja News, The Discussion Network ============
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
From: [EMAIL PROTECTED]
Subject: Will 2.2.x support removable medias better?
Date: Tue, 19 Jan 1999 07:22:54 +0100
With 2.0.x and removable medias you have to care about mount/umount or
use mtools if the media has a FAT fs.
supermount addresses this issue in older kernels. Now I wonder how 2.2.x will
care for removable media?
Ideally, I would want to be able to flip in a media (Floppy, CD, ZIP,
whatever) and use it right away without mount or umount. It should be allowed
to remove the media whenever the activity light is off.
supermount is rather old, anyone knows why it didn't find a way into the
official kernel?
--
Olav "Mac" W�lfelschneider [EMAIL PROTECTED]
PGP fingerprint = 06 5F 66 B3 2A AD 7D 2D B7 19 67 3C 95 A7 9D AF
Things which try to look like things often look more like things than things.
------------------------------
From: Uwe Brandt <[EMAIL PROTECTED]>
Subject: Kernel 2.2.0pre6 crashes permanently
Date: Tue, 19 Jan 1999 21:49:29 +0100
Reply-To: [EMAIL PROTECTED]
My System is a:
Dual-Pentium 233MHz
Board: GA-586DX Rev 3b BIOS v.3.43
RAM 96MB
Mytrox Mystique 220 4MB
AIC-7880 UW-SCSI
Hauppauge Win/TV
PCI NE2000 Clone
SoundBlaster 32 AWE
OS: SuSE Linux 6.0
My Problem:
I�ve tried Kernel 2.1.127 to 2.2.0pre6 and they all
crashed after 5 - 10 min. The error-message I get is:
"unknown Interrupt"
"stuck on TLB IPI wait CPU#0"
I�ve found this message in /usr/src/linux/arch/i386/kernel/smp.c
in line 1520 (Kernel 2.2.0pre7) but I�m not an Kernel Hacker.
Whats wrong with my system????
--
[EMAIL PROTECTED]
------------------------------
From: Marco Al <[EMAIL PROTECTED]>
Subject: Re: What about "Linux.. the home game"?? (a consumer version)
Date: Tue, 19 Jan 1999 18:50:27 +0100
"David T. Blake" wrote:
> Have you seen what a VAR box installed with KDE and xdm (run level 5)
> looks like ?
Well since this is about making something attractive to the average
(windows) user, Ill reply... Thats me, just installed debian couple of
days ago because I want to do some stuff. To get out of the unfamiliar
text only surroundings I installed XFree86&KDE (1.0) as quickly as
possible. (wich turned out to be not as quick as hoped, because the
relevant X server files were spread out over a vast amount of different
packages wich were without prior knowledge pretty hard to find, also
nice of them to hide the graphical X setup program in the VGA16 X server
package) So after getting X to run I start up KDE... ah hey windows I
think now all will be good :)
So I open the file manager click on a text file I wanted to read, and
apart from the hideously slow build up of windows (compared to win98 on
the same system) I am immediately greated with a bug, it first opens 2
windows telling me I am trying to open a directory for wich I have to
click OK buttons to get rid of and one window with the text file... Oh
great.
The KDE terminal app was a good example of the plain inconstency of KDE
apps, I couldnt find a straight forward way to paste to it for one.
Anyway aside from the buggy and slow and inconsistent impression KDE
managed to make on me in half an hour worth of usage the other most
important thing wich irratated me as a windows user was the
aesthetics... OMG the fonts in X are UGLY... How do you guys stand
reading webpages with that crap?
Now Im sure I can get KDE to go a little faster by using a better window
manager besides from their's. And the font quality can be a little
better if I change the priorities for the fonts in my X config a bit,
although nothing short of hacking my own X server will get me my beloved
font AA back, fact remains.... It aint there yet by a long shot.
> The issue is that this product already exists and can be had pretty
> easily.
I agree with you on the multi-user/single-user issue, and also with the
GUI/text config... but what exists probably exposes less than 5% of the
entire system config via GUI. Thats not what he was talking about. I
think the linux phase 2 posted earlier today in this news group
describes rather well everything whats still left to be done.
yes a GUI version of Linux somewhat exists, but its certainly far from
ready for the mainstream and it still misses most of the important
features to make a full GUI Linux.
Marco
------------------------------
From: "Bjorn Wesen" <[EMAIL PROTECTED]>
Subject: Re: 6 questions on disk files
Date: Tue, 19 Jan 1999 22:12:52 +0100
James Youngman wrote in message ...
>[EMAIL PROTECTED] writes:
>> 2) When data is moved from the disk buffer into RAM through a DMA/ SCSI
>> controller, how many times is it moved from one buffer to the next before
it
>> finally finds its way into user-space?
>
>I don't know.
The Triton UDMA/IDE and some SCSI drivers use scatter-gather DMA to read HD
blocks into the page cache directly. Then the filesystem copies from the
page cache into the user-memory. The details vary between different
filesystems, but there is no reason why any more buffer copying than the one
from the cache to user-space is required.
It is possible to write a device driver which DMA's directly into user-land,
but since this won't be cached, it is sub-optimal for almost all disk
purposes except very specialised performance applications.
>> 3) I'd like "allocate contiguous uninitialized space" on disk. That is, I
>> want to create a few very large (a few hundred MB) files and "fill" them
with
>> data at a later time.
>
>I don't think the kernel provides for this. If files don't do this
>fast enough for you, try writing on blank partitions. Otherwise, go
>for RAID.
Yes, separate partitions would be very easy to use for this. You just open
/dev/hda2 for example and r/w blocks.
>> requests in that order, A, B, C and D. Suppose, however, that the chunks
lie
>> on the track in REVERSE order, first D, then C, then B, then A. Does the
>> device driver or the controller manage to collect them in just one
>> revolution, or does it need four (actually from three and a little bit to
>> four)? Does the answer change with an UDMA disk/disk controller?
Well OS'es in general tend to sort block requests with an elevator
algorithm, so as long as you give the B, C and D requests before the A
request already started fetching, it will fetch D first. Of course since you
don't actually know the drives geometry this is not faultproof, but a HD
manufacturer would be awfully stupid not to know that OS'es do this, so the
drive maker should map linear block numbers to the most optimal sequential
geometric access pattern.
This mechanism happens before the SCSI and IDE controllers. However with
SCSI you have the additional feature of asynchronous re-selection, which
means that the drive can accept more than one request at a time and signal
when each one is ready - which would benefit for the case that the elevator
algorithm in the OS missed out on something that the drive knows better, or
if you have more than one drive on the same physical bus.
>> already available before the read phase begins. Is it possible to have
the
>> disk read the contents of a track, then IMMEDIATELY update that track
before
>> moving the head to the next one
>
>As far as I know, no disks will write to and read from a sector at the
>same time. Hence, if a sector must be read *and* written, I assume an
>extra disk rotation is required, unless the data is kept in the disk's
>write cache instead (or unless the data to be read was in the cache,
>and so only the write was in fact required).
The original question was probably rather if all blocks are first read from
the file and then all blocks written, requireing two scans of the HD head
over the same area.
In Linux, the reads will use sector read-ahead into the page cache. The
(from user-space) interleaved updates, will change the in-memory pages. They
won't be written out to disk until relatively much later, unless you're
really short of memory. This is much more advanced than this of course, but
this is the normal way an OS handles it.
So unless this read/writing is the only thing the CPU ever will do
continously in this machine, you won't really notice the "dual-scan" of that
drive head.
This won't change even if you r/w direction into a partition, since it's
buffered I/O for those devices.
/Bjorn Wesen
------------------------------
** 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
******************************
