Linux-Development-Sys Digest #872, Volume #6 Thu, 24 Jun 99 07:13:52 EDT
Contents:
Re: using C++ for linux device drivers (Justin Vallon)
Re: Is there a virtual floppy device? (Gianni Mariani)
Re: Why not C++ ("Thomas Steffen")
Re: Run in background (Villy Kruse)
Configuration as Database (was Re: TAO: the ultimate OS) (Christopher B. Browne)
Re: Why not C++ (David M. Cook)
Re: Why we are still holding on to X Windows (Peter.vanHelden)
Re: You can now use Winmodems in Linux!!!!!!! (Etienne Lorrain)
Re: TAO: the ultimate OS (Emile van bergen)
Re: TAO: the ultimate OS (Donal K. Fellows)
Trouble starting X ("Jay")
Trouble starting X ("Jay")
Re: Why we are still holding on to X Windows (Aurel Balmosan)
----------------------------------------------------------------------------
From: Justin Vallon <[EMAIL PROTECTED]>
Subject: Re: using C++ for linux device drivers
Date: 24 Jun 1999 01:25:36 -0400
Mario Klebsch <Mario [EMAIL PROTECTED]> writes:
> Hi!
>
> Justin Vallon <[EMAIL PROTECTED]> writes:
>
> >These are not C++-ish. There are completely reasonable
> >implementations of ::operator new and ::operator delete in terms of
> >the C memory allocator. Why do you require anything more complicated?
> >If malloc doesn't do a good job, then malloc should be re-written.
>
> Hey, we are in comp.os.linux.development.system!!!
> ^^^^^^
>
> And we are talking about kernel code. AFAIK, there is no malloc in
> the kernel. So you have to do something yourself.
>From what I understand, it would be to use kmalloc.
--
-Justin
[EMAIL PROTECTED]
------------------------------
From: Gianni Mariani <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: Re: Is there a virtual floppy device?
Date: Wed, 23 Jun 1999 16:13:06 GMT
rtfm
/usr/doc/HOWTO/Bootdisk-HOWTO
on redhat 5.x and 6.x
scottxb wrote:
> I am looking for a device driver that emulates a floppy
> device (especially a 2.88MB floppy device).
>
> I need this driver so that I can use lilo to install a
> boot loader onto a 2.88MB floppy image.
>
> I dont want to have to use a physical 2.88MB
> floppy device.
>
> Any help would be appreciated !!
>
> Regards,
>
> Scott.
>
> [EMAIL PROTECTED]
------------------------------
From: "Thomas Steffen" <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 24 Jun 1999 10:31:18 +0200
[EMAIL PROTECTED] (Nathan Myers) writes:
> Ralph Glebe <[EMAIL PROTECTED]> wrote:
> > Are all the programs in C because: [speculation]
...
> 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 might be the main problem for C++ (libraries). different
compilers don't mix, and neither do different (minor) versions. so if
you develop with libstdc++ v2.8, and the user has 2.9, he'll have to
recompile.
the way C++ is this is going to stay. library version will get more
stable, so it will be less of a problem. but different compilers are
bound to be incompatible.
apart from that, C++ might not be a very elegant language, but it is
fast. at least compared to other OO languages. and still has about
every feature you can expect.
--
linux, linuctis - f, das beste Betriebssystem ;-)
------------------------------
From: [EMAIL PROTECTED] (Villy Kruse)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Run in background
Date: 24 Jun 1999 10:11:45 +0200
In article <7krrps$rm9$[EMAIL PROTECTED]>, ellis <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>Eric George <[EMAIL PROTECTED]> wrote:
>
>>Try following you executable with an '&'
>
>That still leaves the process in the shell's process group.
Try take a look at the setsid command /usr/bin/setsid
SETSID(8) Linux Programmer's Manual SETSID(8)
NAME
setsid - run a program in a new session
SYNOPSIS
setsid program [ arg ... ]
DESCRIPTION
setsid runs a program in a new session.
SEE ALSO
setsid(2)
AUTHOR
Rick Sladkey <[EMAIL PROTECTED]>
Also, if you you fork off a child in your program in order to become
a daemon you need to call the setsid() system call, close stray opened
files including those opened by various getxxbyy functions.
--
Villy
------------------------------
From: [EMAIL PROTECTED] (Christopher B. Browne)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Configuration as Database (was Re: TAO: the ultimate OS)
Reply-To: [EMAIL PROTECTED]
Date: Thu, 24 Jun 1999 06:31:57 GMT
On 24 Jun 1999 01:17:19 GMT, Terry Murphy <[EMAIL PROTECTED]> posted:
>In article <[EMAIL PROTECTED]>,
>Bill Anderson <[EMAIL PROTECTED]> wrote:
>
>[Re: why Database configuration systems are bad]
>
>>A few reasons:
>>o A failure of a proprietary, binary dataset results in total system
>>failure. Solution: reinstall OS.
>
>A database configuration editor can be used to edit a damaged
>databases. There is no reason why a well designed database
>would be more susceptible to damage than a text file. There
>is not much meta-data in fixed-length databases.
"No reason"? I suspect you don't understand the way database systems *or*
filesystems are implemented.
Databases are a big hive of pointers. If built atop of a filesystem, which
is another big hive of pointers, this gives you one big interconnected nest
of pointers. If one block of the FS goes out, your database is corrupt, and
the corruption may extend arbitrarily distantly from the deepest level.
In other words, a DB atop a filesystem is not only vulnerable to corruption
of the file (e.g. - if a buggy program at user level crashes/writes bad
data), it is also further vulnerable to corruption that comes from
filesystem bugs, which are somewhat indistinguishable from corruption
resulting from hardware failures.
In contrast, text files are linear arrays of information atop a single
FS-level "hive of pointers." If a block blows out, this removes a chunk of
that linear array, which is obviously still a bad thing, but not as vastly
corruptive, since there aren't the multifariously-indirected pointers.
Believe as you like, but consider that companies that have been creating
DBMS tools for lo many years such as Sybase and Informix recommend using raw
partitions to store data. Part of this is to have better control over
precisely when data goes onto disk, but part of it is also to get rid of
that extra level of indirection and the resultant potential for DB corruption.
>>o In order to fix it, it needs to have a running system with full a
>>toolsuite.
>
>So VI/EMACS is not a tool? The only tool you need to repair database
>configuration settings is your database configuration editor, just as
>the only tool need for text based configuration is a text editor. You
>need one type of tool for one format, and another type for a different
>format. I don't see what is difficult about this.
>
>Actually, a database configuration editor is a much simpler program
>than a text editor. On the machine I'm at now, REGEDIT.EXE is 71K,
>and VI.EXE is 231K. I'm certain that the difference between SYSGEN
>and EDIT/TPU is even much more noticeable.
And vi includes sorts of functionality that regedit doesn't. A macro
programming system. Regular expression parser.
It would be rather more fair to compare regedit, weighing in at 71K, with
something like t.exe, which weighs in at 1K.
>>o Buggy
>
>Implementation specific.
>
>>o Instable
>
>Implementation specific. Since the configuration database can in
>principle be implemented with any sort of database system, this
>would be like saying that database implementations (such as Oracle,
>etc.) are inherently unstable.
You have to compare apples with apples.
To compare with Oracle, you have to have a version of Oracle that:
a) Removes the lock manager LCK,
b) Removes the transaction manager CKPT,
c) Removes the archive logging facility (e.g. - LGWR),
d) Allows processes to modify database files directly, without locking,
rather than having to proxy through such things as DBWR,
e) Implements atop files atop DOS FAT, rather than using raw partitions.
Oracle doesn't just have *one* thing that works to provide a robust system;
it has a whole host of work processes working together.
And it is worth noting that they don't use a database to store the
system configuration for the database; that is stored in, Surprise,
Surprise...
Text files.
>>o Overly Complex
>
>Hmm, what is more complex? Each program having its own code to
>read its own configuration file format, and each programmer having
>to design his own file format and design and test his own routines
>to parse it, or have one universal set of access routines, which come
>pre-tested, and which all users understand how to us3?
That is a separate question.
I would promote the use of some common configuration libraries, such as
libPropList. It was created particularly for use with WindowMaker, and is
compatible with the property list schemes used in NeXTstep, OPENSTEP, and
GNUstep. It sets up a structure that may be read, manipulated, written, and
synchronized with a file, and by providing an opaque data structure in
between, removes the need for an application to be aware of the form in
which the data is represented.
Its implementation uses text files, which nobody (other than those that
apparently worship O(1) or O(log(n)) operations that result in building
fragile multilayered disk-based pointer hives) seems to complain about.
Note that by using facilities like libPropList, this means that:
the programmer does *not* need to create:
a) Yet Another File Format,
b) Yet Another Parser,
and debug, and so forth.
>I'll tell you what's overly complex and utterly slow: LinuxConf.
>The reason for this is precisely because it has to muck with and
>generate all sorts of text based configuration scripts, instead of
>easily readable binary files.
Have you profiled it to establish that parsing is forcibly the cause of
slowness?
Or are you merely claiming this as a bald fact, devoid of any real evidence
to back up such claims?
The sources are available. Your mission, if you wish to claim evidence that
text parsing is the cause of its slowness, is to compile Linuxconf with
suitable profiling options, collect statistics, and tell us how much of the
wait times related to text parsing.
I also expect that were it to be evaluated, the problems would turn out to
relate to inefficiencies inherent to LinuxConf that would not be resolved at
all by the O(1) access times that might result from storing configuration
data in hash tables.
>One key feature of a database conifguration system, which I never see
>mentioned, is that it is machine writable/editable. E.g. a GUI editor
>for a sendmail.cf file would be extremely, extremely difficult.
Oh, good. Citing sendmail.cf as an example of "why you should use a
database instead."
sendmail.cf is a generalized language, albeit one that is quite arcane.
It does things that a database system couldn't.
A redesign of Sendmail based on a reassessment of requirements would obviate
the need for the egregarious complexity. And such redesigns have been done.
If you don't like Sendmail, use Qmail. Or EXIM. Or smail. There are a
bunch of other mail systems that are considerably simpler to understand and
configure. That has *nothing* to do with databases.
--
Those who do not understand Unix are condemned to reinvent it, poorly.
-- Henry Spencer <http://www.hex.net/~cbbrowne/lsf.html>
[EMAIL PROTECTED] - "What have you contributed to free software today?..."
------------------------------
From: [EMAIL PROTECTED] (David M. Cook)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Reply-To: [EMAIL PROTECTED]
Date: Thu, 24 Jun 1999 06:53:53 GMT
On Wed, 23 Jun 1999 16:09:29 -0700, Ralph Glebe <[EMAIL PROTECTED]>
wrote:
>benefits. Still, it makes me wonder if I'm headed for trouble trying to
>program in C++ on the linux platform.
No, I don't think so. Bruce Eckel (www.eckelobjects.com), who is writing a
second edition to his _Thinking in C++_, seems to think highly of egcs, the
C++ compiler that comes with newer distributions.
>1) The legacy programs were written in C, and its easier to keep them that
>way.
True for a lot of stuff.
>2) There is something inferior about the code produced with the GNU C++
>compiler.
Up until recently g++ was not up to the standard, but it was probably
still adequate for a lot of stuff.
>3) It's an extra effort to download the C++ libraries, so if you want to
>distribute the source, C is the way to go if you want to be sure that your
>code is going to compile.
The C++ libraries should come with most distributions.
I think one of the main reasons is that more people feel comfortable with a
smaller language like C. It's easier to proceed when you feel you have a
grasp of most of a language.
Dave Cook
------------------------------
From: [EMAIL PROTECTED] (Peter.vanHelden)
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why we are still holding on to X Windows
Date: 24 Jun 1999 09:01:40 GMT
Michael Gu ([EMAIL PROTECTED]) wrote:
: If Microsoft is a monopoly, X Windows acts more like a monopoly in the
: Unix world.
Last time I checked X was not a company, but rather an open specifiaction.
Moreover, the sourcecode for a sample implementation is available under
,well, rather liberal license conditions.
: Let's face it. X Windows is a really premitive base for modern GUI,
Primitive? Why?
(Somehow the "Let's face it" tells me you don't know)
: terrible font support breaks GUI all the time, no sound capability, ....
Are you referring to the lack of antialiased fonts. That is considered to be
a problem by a lot of people indeed.
No sound capability? Are you mad? What the heck has a sound system to do
in a window system? FYI, The X consortium has been working on a sound system
(it is called nas, if memory serves me) The unfinished sourcecode was released
to the public at the time the OpenGroup took over control of.
: If Linux is going to desktops to compete with Microsoft, it got to come
: up with something much better then X.
Why? What is wrong with X? Other than the no antialiased fonts argument
your post does not contain a single bit of substance. You might take
the observation that compatibility _does_ matter into consideration...
: So, why don't we drop the X and innovate?
Well, there's a wide range of projects you can join. You see, you are not the
first, err, individual to climb a soap box to spread the "X sucks, Let's Build
the Champion Of All Windowing Systems!" gospel.
Follow ups set.
Peter
Who has seen worse trolls
------------------------------
From: Etienne Lorrain <[EMAIL PROTECTED]>
Subject: Re: You can now use Winmodems in Linux!!!!!!!
Date: Thu, 24 Jun 1999 09:58:36 +0100
Doug DeJulio wrote:
> [...]
> Also, Chase Research (www.chaser.com) gives out the source code for
> the driver for their 16654-based serial boards and modem boards.
>
> (Kernel folks: any word on folding this in to the main kernel?)
Where ? I've just seen precompiled user mode stuff here.
Etienne.
------------------------------
From: Emile van bergen <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: Thu, 24 Jun 1999 11:09:20 +0200
On 24 Jun 1999, Terry Murphy wrote:
>In article <[EMAIL PROTECTED]>,
>Emile van bergen <[EMAIL PROTECTED]> wrote:
>
>>Popper (and nature) argue 'piecemeal tinkering' tends to be more
>>efficient than revolutionary design when it comes to adaptivity. Beauty
>>is something else, however, and it seems you're looking for that.
>
>Published studies have concluded that software engineers who follow the
>design->code paradigm are more efficient and productive than those who
>follow the edit->compile->test paradigm, and that the most productive
>software engineers are those who spend the least amount of time in
>front of a computer (and, yes, I can provide bilbiographic citations to
>back this up).
Okay, but is the probable fact that incompetent programmers tend to be
the edit->compile->test guys, thus polluting the comparison?
Of course, there should be a balance between the two. Leaving out any
design from the process would be rediculous, of course. But I think you
can't have any complex software product in just one cycle, because it is
plain inefficient to try and do so, because at one point, you're
formalising during the design in a way that one might as well start to
code.
Again, I don't argue that the best method of software production is
'hmmm... I don't understand what went wrong... perhaps if I change this
to that? *compile* *run* aiii... still doesn't work... well let's try
something else...'.
--
M.vr.gr. / Best regards,
Emile van Bergen (e-mail address: [EMAIL PROTECTED])
This e-mail message is 100% electronically degradeable and produced
on a GNU/Linux system.
~
~
:wq
------------------------------
From: [EMAIL PROTECTED] (Donal K. Fellows)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 24 Jun 1999 09:42:29 GMT
In article <7krvpq$eou$[EMAIL PROTECTED]>,
Terry Murphy <[EMAIL PROTECTED]> wrote:
> Published studies have concluded that software engineers who follow the
> design->code paradigm are more efficient and productive than those who
> follow the edit->compile->test paradigm, and that the most productive
> software engineers are those who spend the least amount of time in
> front of a computer (and, yes, I can provide bilbiographic citations to
> back this up).
OK, provide them.
I suspect that the design->code and edit->compile->test paradigms are
tuned towards tackling separate problems...
(Has anyone developed a commercial OS yet using a proper formal design
technique? Or are those only ever used in the safety-critical domain?)
Donal.
--
Donal K. Fellows http://www.cs.man.ac.uk/~fellowsd/ [EMAIL PROTECTED]
-- The small advantage of not having California being part of my country would
be overweighed by having California as a heavily-armed rabid weasel on our
borders. -- David Parsons <o r c @ p e l l . p o r t l a n d . o r . u s>
------------------------------
From: "Jay" <[EMAIL PROTECTED]>
Subject: Trouble starting X
Date: Thu, 24 Jun 1999 14:50:18 +0530
Hello ppl,
I have been getting the following errors starting X :
"According to /var/run/gdm.pid , gdm was already running (485)
but seems to have been murdered mysteriously.
" " " " " " "
" " " " " " "
INIT: Id 'x' respawning to fast: disabled for 5 minutes"
i am using GNOME as my default WM
I also cudn't logout or shut down from the GUI Menu and have to issue
/sbin/reboot to re-start
thanking ya in anticipation
I have a HP DJ200 which i configured as lp under HP DJ
400/500/550 ... due to this i dont know why it does print ... it ends up
with junk characters on paper.
--
Regards,
Jay Shah
Fax :- 1-305-847 8019
E-mail :- [EMAIL PROTECTED]
Website :- http://members.xoom.com/linux_always
ICQ-28959413
------------------------------
From: "Jay" <[EMAIL PROTECTED]>
Subject: Trouble starting X
Date: Thu, 24 Jun 1999 14:48:35 +0530
Hello ppl,
I have been getting the following errors starting X :
"According to /var/run/gdm.pid , gdm was already running (485)
but seems to have been murdered mysteriously.
" " " " " " "
" " " " " " "
INIT: Id 'x' respawning to fast: disabled for 5 minutes"
I also cudn't logout or shut down from the GUI Menu and have to
issue /sbin/reboot to re-start
thanking ya in anticipation
I have a HP DJ200 which i configured as lp under HP DJ
400/500/550 ... due to this i dont know why it does print ... it ends up
with junk characters on paper.
--
Regards,
Jay Shah
Fax :- 1-305-847 8019
E-mail :- [EMAIL PROTECTED]
Website :- http://members.xoom.com/linux_always
ICQ-28959413
------------------------------
Crossposted-To: comp.os.linux.development.apps
From: Aurel Balmosan <[EMAIL PROTECTED]>
Subject: Re: Why we are still holding on to X Windows
Date: Thu, 24 Jun 1999 10:25:29 GMT
In comp.os.linux.development.system Michael Gu <[EMAIL PROTECTED]> wrote:
> If Microsoft is a monopoly, X Windows acts more like a monopoly in the
> Unix world.
> Let's face it. X Windows is a really premitive base for modern GUI,
> terrible font support breaks GUI all the time, no sound capability, ....
> If Linux is going to desktops to compete with Microsoft, it got to come
> up with something much better then X.
> So, why don't we drop the X and innovate?
Well, tell me what can be better then an open graphical API which
does not cost anything? You can easily build ontop of X a Windows-
Desktop clone. One such as fwvm95. You can even do interprocess
communication and interprocess syncronisation with X. You can easily
embeded different programms into one window which is managed be
one overall application. So something like embedding VISO into Winword
could be implemented using X quiet easily. This is done by using
subwindows and passing the window-ids to the process which should
manage it.
Everything that was implemented as a replacement for X was
very limited and many features were missing. Such as SVGAlib.
You might know VMWare. With vmware you can run Windows95 or
WindowsNT in a window of your X-Server.
Also the upcoming X-Server XFree86-4.0 will come with more
features to share hardware resources i.e. 3D hardware. NVidia
released a driver for their TNT cards which can use directly
the 3D hardware. Its only a question of time when XFree86 will
have buildin opengl support for different video cards.
Check www.xfree86.org for more information about the upcoming
features of the 4.0 release.
So finaly, why splitting the developers to develop different
graphic API's and not concentrating on improving the one that
is free and already showed how good it can be used.
Of course every one is free to decide to develop a new one
but it will be hard to reach the features of the current XFree86.
Bye,
Aurel Balmosan
--
================================================================
Aurel Balmosan | [EMAIL PROTECTED], [EMAIL PROTECTED]
http://gaia.owl.de/~aurel/ |
================================================================
------------------------------
** 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
******************************
