Linux-Development-Sys Digest #891, Volume #6 Sat, 26 Jun 99 15:13:55 EDT
Contents:
Re: Why not C++ (Johan Kullstam)
Dreamland (bedlam)
Re: Automating Remote applications running on Unix (Rich)
Re: Why we are still holding on to X Windows (mlw)
Re: X-Shell Development Environment (Michal Jaegermann)
Re: Configuration as Database (was Re: TAO: the ultimate OS) (Christopher Browne)
Re: You can now use Winmodems in Linux!!!!!!! (Zolee)
Re: Why not C++ (Nathan Myers)
Re: TAO: the ultimate OS (Paul Jackson)
Re: Automating Remote applications running on Unix (=?iso-8859-1?Q?Bj=F8rn?= Reese)
Re: using C++ for linux device drivers (Nathan Myers)
----------------------------------------------------------------------------
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
From: Johan Kullstam <[EMAIL PROTECTED]>
Date: 26 Jun 1999 10:54:15 -0400
Justin Vallon <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Greg Comeau) writes:
>
> > In article <7kscsl$s0h$[EMAIL PROTECTED]> [EMAIL PROTECTED]
> > (Nathan Myers) writes:
> > >2. It takes substantial extra effort to code C++ libraries that are
> > > binary-compatible from one release to the next, so library version
> > > problems are incrementally harder.
> >
> > This is definitely a roadblock, but I wonder how many people actually
> > realized this when they started out? I would suspect not to many.
> > Luckily Standard C++ is out and at least for now binary compatible issues
> > are known and can be addressed by compiler implementors as they upgrade.
> > Of course, some compilers have done this more than others. :)
>
> Why would binary compatibility between compiler releases be an issue
> for the kernel? Don't you build the entire kernel under one
> compiler?
yes. and statically linked programs wouldn't need to care about
changing libs either.
> Maybe for modules, but you'd extern "C" those, anyway.
>
> Or, are you speaking in general (libnifty.1, libnifty.2)?
check out my /usr/lib
-rwxr-xr-x 1 root root 1025339 Mar 21 16:41 libstdc++.so.2.7.2.8
-rwxr-xr-x 1 root root 375773 Mar 21 16:41 libstdc++.so.2.8.0
-r-xr-xr-x 1 root root 1184870 Mar 21 16:41 libstdc++-so.2.9.0
a plethora of libstdc's....
--
J o h a n K u l l s t a m
[[EMAIL PROTECTED]]
Don't Fear the Penguin!
------------------------------
From: bedlam <[EMAIL PROTECTED]>
Subject: Dreamland
Date: Sat, 26 Jun 1999 15:36:56 GMT
------------------------------
From: [EMAIL PROTECTED] (Rich)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Automating Remote applications running on Unix
Reply-To: [EMAIL PROTECTED]
Date: Sat, 26 Jun 1999 16:21:57 GMT
On 26 Jun 1999 10:30:37 GMT, Stanley Mathew <[EMAIL PROTECTED]> wrote:
>I would like your help for writing a C or Java application that can
>connect to the remote unix system and capture each screens into a file and
>edit it and run it.
>
Assuming that you can't write some sort of direct interface to the
remote application, by far the easiest way to do this would be
with a Perl program. In particular, you can use the Net::Telnet module
to do precisely this sort of operation without breaking a sweat.
- Rich
------------------------------
From: mlw <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
Date: Sat, 26 Jun 1999 15:06:13 +0000
Cameron Hutchison wrote:
>
> Tristan Wibberley <[EMAIL PROTECTED]> writes:
>
> >Cameron Hutchison wrote:
> >>
> >> X should be thought of as a user I/O service, not just a display service.
>
> >X's full name is The X Window System. It is not a general IO service, it
> >does _Window_System_ stuff.
>
> I never said it was a general IO service. I said it should be a *user* IO
> service. Disk/network IO are not part of X, nor do I think they should be.
You must think of X as a display driver nothing else. You wouldn't want
s3.sll and s3.sys in NT to manage mmSndxxx calls would you? No, because
those are display driver components. X is analogous to a display driver.
>
> That aside, I believe the original X protocol included sound support
> anyway. XBell().
You mean "<ctrl> G" This is not sound.
> That was the extent of the capability of sound at the
> time. We now have far better sound capabilities, so X should continue its
> sound support and be extended for these new capabilities.
No, a network streaming audio format/protocol should be a separate
standard.
>
> As already agreed on this thread, font support for X could be much better.
> It hasn't kept up with the times as anti-aliasing becomes feasible. I say
> XBell() has fallen behind the times and that too needs to be updated. Just
> as adding shades of grey to fonts, we need more shades of tone to be added
> to the *existing* sound support of X.
I think you are trying to make X what it isn't. It is not a GUI, it is
the hardware interface for the GUI. Nothing more, nothing less.
>
> >Sound is not window system stuff, input is
> >(input is redirected around the windows according to window system
> >behaviour).
>
> I can see that sound is just as associated with a window as input is.
> Keyboard input is quite a different thing to graphic output, yet keyboard
> input part of X because it needs to integrate with it. Ditto for sound.
Not so at all. Sound has nothing to do with the graphics primitives.
Sound has to do with system events and hardware peripherals. Your
argument, followed to the logical extremes, would have X managing stuff
like network chat sessions.
Yes, at some level the user interface should manage various components.
X is not that level. X is one of those things that are managed by the
GUI. It is analogous to a display driver. What is so hard to understand
about that?
--
Mohawk Software
Windows 95, Windows NT, UNIX, Linux. Applications, drivers, support.
Visit http://www.mohawksoft.com
------------------------------
From: [EMAIL PROTECTED] (Michal Jaegermann)
Crossposted-To: linux.dev.x11,comp.os.linux.x,comp.os.linux.alpha
Subject: Re: X-Shell Development Environment
Date: 26 Jun 1999 16:35:52 GMT
Reply-To: [EMAIL PROTECTED]
Uwe Schneider ([EMAIL PROTECTED]) wrote:
: Bob Bryla wrote:
: >
: >
: > I'm going to do some rapid application development for X-Servers, and don't
: > have the time (nor the skills) to do a lot of low level C++ calls to
: > X-Libraries.
: Although there are a lot of combinations which meet your requirements, I
: would suggest you using Perl/TK. The reaons are:
: - Perl is an extremely powerful, extendible and extended (e.g.
: MIME::Lite for sending mail) scipting language (much better than Tcl in
: my opinion).
: - TK provides for a high quality user interface. It was born on X/Motif
: but was ported to other GUIs.
Agreed. Just to make life easier for a novice - Tk is not a part of
a standard Perl distribution but an extra module (on steroids :-)
called pTk. Check on CPAN. O'Reilly has a book "Learning Perl/Tk"
by Nancy Walsh and a companion pocket reference for pTk. And the whole
pile of other books on Perl - of course. :-)
: A very good starting point for the whole thing is "Advanced Perl
: Programming" (O'Reilly), which is a must for every script programmer
: anyway.
This is a good book (so called "panther book") but it may be a bit
too advanced when you are just starting. :-)
The other options is Python which also has Tk interface. If you feel
better in Perl or in Python depends heavily on your personal style
of programming.
Of course the original Tk came with Tcl and its presence is most likely
responsible for Tcl acceptance. Tcl is quite manageable for small
things with simple interactions. People wrote big projects in Tcl,
like Tkman - for example, but I would classify them rather as stunts
of the same sort as writing Final State Machine in sed (yes, that
could be done and was done a number of times :-). Besides such
projects like Tkman would not be "big" neither in Perl nor Python.
Michal
------------------------------
From: [EMAIL PROTECTED] (Christopher Browne)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: Configuration as Database (was Re: TAO: the ultimate OS)
Reply-To: [EMAIL PROTECTED]
Date: Sat, 26 Jun 1999 14:24:53 GMT
On 25 Jun 1999 06:18:56 GMT, Terry Murphy <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>Christopher B. Browne <[EMAIL PROTECTED]> wrote:
>
>>Sadly, that means that you gain very little over the text file.
>>
>>--> Fixed size blocks means wasted storage compared to text
>
>Sure. But to be fair, the little text files that Unix creates is
>not optimal space usage either (and what you write at the bottom
>is much worse...unless you do have a plan ;-)
Of course, *reality* these days is that it doesn't matter much. It
doesn't matter if my /etc/hosts consumes 1K or 20K; both are likely to
fit nicely into cache, and won't influence system performance terribly
adversely.
(Did you know that the new AMD "Athlon" CPU can support up to 8MB of L2
cache? That's largely an aside, but is *spectacularly* more than IA-32
has supported to date...)
>>--> No indexes means no benefit from "better than O(n) expected accesss time"
>
>Correct, but performance would be much better over all since there is
>no need to parse, you can just read() everything in.
If there a bunch of little "tables," it doesn't much matter.
>The two advantages I see in the registry are:
>(a) programmatically writable
>(b) uniform tool/file format/routines for all programs
>(c) inherent error checking (by way of types)
>
>I'm not as concerned about performance (I would be if it dipped below
>text files, of course, though)
Given a suitable API and library that sits between the programmer and
the representation, those three properties apply equally well to a
text-based configuration information library.
I will cite libPropList as an example of this; it makes the physical
representation specifically opaque to applications that use the library,
which means that you don't need to know how it's implemented.
Although since you know it's text, RCS, CVS, find, grep, and other text
tools may be brought to bear on "search" and "version management"
issues.
>>The *real* point is that when text is used, one can muster the force of any
>>of UNIX's text manipulation tools, whereas a binary database leaves you
>>limited to whatever tools have been specifically written to manipulate the
>>binary database.
>
>In theory this is true, but in practice which text tool are you going
>to use for these sorts of configuration files? Since these are
>basically read-only except by humans, really the only thing you are
>going to do search, so grep and friends may help you, but remember, the
>registry editor is going to have all of the search (and replace!)
>functions as well. Also the fact that is in one database (file)
>alleviates the need for some of the other tools (e.g. find)
Does a database system include RCS/CVS equivalents?
Versioning tends to be, in DBMSes, a feature that starts taking you into
the world of "advanced stuff that may be flakey or slow," but using RCS
on text config files is quick and easy.
>>I don't see a mandate for everyone to reimplement all the programs they've
>>written just to do that; that approach represents the sort of "fascism" that
>>the UNIX community (and others) rather frown on.
>
>I know it's frowned down upon and that's my whole problem with
>it. ;-)
>
>See, this is the type of thing that would have been solved by having
>thought about this 30 years ago: Unix would have just had a standard
>for it, and most people would have used, but since it came 30 years
>after the fact, even if a lot of new programs decide to adopt it,
>there will always be those written before the fact that won't have the
>support.
>
>>My classic alternative to /etc/fstab is to do the following:
>>
>># mkdir /etc/fstab
>># echo 192.168.1.1 > /etc/fstab/dantzig.brownes.org
>># echo 192.168.1.2 > /etc/fstab/wolfe.brownes.org
>># echo 192.168.1.3 > /etc/fstab/knuth.brownes.org
>># cd /etc/fstab
>># ln dantzig.brownes.org dantzig
>># ln wolfe.brownes.org wolfe
>># ln knuth.brownes.org knuth
>># ln -s dantzig cache
>># ln -s wolfe coda
>
>Of course this is /etc/hosts, not /etc/fstab
Indeed. Comes from writing when tired...
>, but that makes me
>curious as to how would go about implementing /etc/fstab, which
>differs from /etc/hosts in that each record has more than one field.
>Would you make the record into a directory as well, and put each field
>as a separate file, or would you keep it as it is, and put all of the
>fields into one file (and if the latter, how do you tell them apart)?
>(/etc/fstab is also tricky because the primary keys generally contain
>slashes ;-)
Good question. An equivalent to the above for /etc/fstab does have a
couple of extra issues to solve, and it takes a little more thought.
There are two choices for the initial representation:
a) Each FS being represented as a file, probably with a line for each field,
or
b) Each FS being represented as a directory, with a file underneath to
represent each field.
I think I'd rather go with b), where we'd then have:
# mkdir /etc/fstab/[name-for-/usr]
# echo "/dev/hda1" > /etc/fstab/[name-for-/usr]/device
# echo "ext2" > /etc/fstab/[name-for-/usr]/fstype
# touch /etc/fstab/[name-for-/usr]/no-auto
# touch /etc/fstab/[name-for-/usr]/read-only
and have put off the issue of how to encode "/usr" into what I put there
as [name-for-/usr].
An NFS mount might be handled as:
# mkdir /etc/fstab/[name-for-/usr/local/godel]
# echo "nfs" > /etc/fstab/[name-for-/usr/local/godel]/fstype
# echo "godel" > /etc/fstab/[name-for-/usr/local/godel]/nfsserver
# echo "/usr/local/godel" > /etc/fstab/[name-for-/usr/local/godel]/nfsremotedir
# mkdir /etc/fstab/[name-for-/mnt/floppy]
# echo "/dev/fd0" > /etc/fstab/[name-for-/mnt/floppy]/device
# echo "msdos" > /etc/fstab/[name-for-/mnt/floppy]/fstype
# touch /etc/fstab/[name-for-/usr]/no-auto
# touch /etc/fstab/[name-for-/usr]/no-setuid
# touch /etc/fstab/[name-for-/usr]/user-mount
The "how should we encode mount-point names" issue represents a good
question. It needs to be encoded somehow; that is an issue for which I
can't think of a good "knee-jerk" answer.
It should involve using a program to translate input keys into valid
filenames; a good such scheme needs to:
- Handle various metacharacters, particularly "/"
- Not limit size (e.g. - 17 characters *WILL NOT* be acceptable)
- [Thinking Ahead] Permit a regular expression scheme where you'd pass
in a regular expression, and be returned a continuation (in Scheme
terms) that is probably a second regular expression that can be
matched against all the files that can match.
>I've seen you mention this before, and I do think it is beautiful. It
>it the perfect fusion of a database into filesystem semantics,
>especially with the links there. I would like to see how well it scales
>to the other files though. How could /etc/resolv.conf work? Also, how
>is this actually implemented (if it is), are each of the
>records/fields actually individual files (taking up a whole block of
>filesystem), or is there something more intelligent behind the whole
>thing?
These sorts of representations do put a premium on having a filesystem
that can represent small files with reasonable efficiency. ext2 isn't
*greatly* efficient in that regard, although it's certainly not as bad
as MS-DOS, where I expect that modern many-GB-drives mandate that a
files have greatly increasing minimum sizes.
Reiserfs, where *active* design/implementation work is taking place, is
seeing tremendously relevant questions and answers. Based on the 20-odd
emails I saw last night from luminaries like Ted T'so, Linus Torvalds,
Stephen Tweedy, and somewhat less-known folks like Alexander Viro and
Hans Reiser, I think that a "renaissance" of development work on
filesystems is in progress.
The answer, *today* is that the approach, on ext2, is somewhat
inefficient in its use of disk space. Although it is probably still
worthwhile.
The answer, next year, will hopefully be something like:
"You should have /etc mounted via -t reiserfs, which will allow
efficient key access as well as efficient storage."
--
As Will Rogers would have said, "There is no such thing as a free
variable." -- Alan Perlis
[EMAIL PROTECTED] <http://www.hex.net/~cbbrowne/linuxkernel.html>
------------------------------
From: Zolee <[EMAIL PROTECTED]>
Subject: Re: You can now use Winmodems in Linux!!!!!!!
Date: 26 Jun 1999 17:30:41 GMT
Billy Moon wrote:
>
> I am currently working on a application that enables winmodems to
function
> in Linux. Anyone who would like to help test this app please contact me.
>
>
>
Hi
One of my friend want's to use an MWAVE modem under SuSE 6.1
If your Program will be able to handle that, please send him an E-mail ant
send him your application, I am sure he would like to test it!
And please tell him what it does.
His address is: [EMAIL PROTECTED]
thanks and bye!
================== Posted via SearchLinux ==================
http://www.searchlinux.com
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 26 Jun 1999 11:10:23 -0700
John E. Davis <[EMAIL PROTECTED]> wrote:
> In my opinion, the only thing that C++ has over C is
>better support for data encapsulation via classes and, possibly,
>exception handling. Other features such as operator overloading I can
>do without because of the potential for abuse.
Classes are not a very powerful feature; you can emulate them pretty
well in C. Exceptions are quite powerful, though of limited use.
Far more powerful than either are templates.
If you don't know C++ templates, you don't know C++ at all. It is
templates, for example, that make it possible to write a C++ library
that does matrix operations as efficiently as specially-optimizing
Fortran on machines specifically designed to run Fortran well. Unlike
Fortran, though, C++ templates are not tuned specificially for matrix
math, so can be used to accomplish similar wonders in any area.
Of course if you don't care about performance none of this matters.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
From: [EMAIL PROTECTED] (Paul Jackson)
Subject: Re: TAO: the ultimate OS
Date: 26 Jun 1999 18:46:57 GMT
As someone who lives in ...
that "niche" of people that prefer to spend their
nights redesigning the allocation of disk space
between Linux and WinTel.
I can confirm what cbbrowne recommended: Partition Magic suits
me fine for resizing my NT/Win/Linux/DOS/Warp/... partitions.
--
=======================================================================
I won't rest till it's the best ... Software Production Engineer
Paul Jackson ([EMAIL PROTECTED]; [EMAIL PROTECTED]) 3x1373 http://sam.engr.sgi.com/pj
------------------------------
From: =?iso-8859-1?Q?Bj=F8rn?= Reese <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Automating Remote applications running on Unix
Date: Sat, 26 Jun 1999 18:03:34 +0000
Stanley Mathew wrote:
This sound like a job for Expect.
------------------------------
From: [EMAIL PROTECTED] (Nathan Myers)
Subject: Re: using C++ for linux device drivers
Date: 26 Jun 1999 11:38:03 -0700
Mario Klebsch <[EMAIL PROTECTED]> wrote:
>Yes, and how to you tell the compiler to use kmalloc instead of malloc?
>Having ::operator new and ::operator delete seems to be the right tool
>for me.
Not necessarily. You have to consider what happens when kmalloc
fails. You can't just throw an exception, and anyway the examples
that were presented here didn't even do that.
Probably the correct approach would be a separate function to
create each kind of object you need, which calls kmalloc directly,
and uses placement-new to initialize the object iff kmalloc succeeds.
--
Nathan Myers
[EMAIL PROTECTED] http://www.cantrip.org/
------------------------------
** 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
******************************
