Linux-Development-Sys Digest #869, Volume #6 Wed, 23 Jun 99 20:14:29 EDT
Contents:
Re: Question to ps (Alex Rhomberg)
Re: TAO: the ultimate OS (Terry Murphy)
Re: TAO: the ultimate OS (Stefaan A Eeckels)
Re: NT kernel guy playing with Linux (Erik de Castro Lopo)
Kernel data to user space files (Monkey Boy)
Increasing Max TCP Connections (Dan Eble)
Re: You can now use Winmodems in Linux!!!!!!! (Jonathan A. Buzzard)
promiscuous ethernet packets (Hisham Petry)
Re: Why not C++ (Erik de Castro Lopo)
Re: NT kernel guy playing with Linux (Mario Klebsch)
Re: TAO: the ultimate OS (Bill Anderson)
Disney vacation 6594 ([EMAIL PROTECTED])
Re: Run in background (ellis)
Re: Is there a virtual floppy device? (Adrian 'Dagurashibanipal' von Bidder)
Re: Why not C++ (Frank Sweetser)
----------------------------------------------------------------------------
Date: Fri, 18 Jun 1999 09:29:47 +0200
From: Alex Rhomberg <[EMAIL PROTECTED]>
Subject: Re: Question to ps
Ulrich R�mer wrote:
>
> Hello,
>
> I want to know, how many processes are running at the moment.
> I want do it in an c-program, without calling system(ps).
> Does anyone know, how I can do it.
Look at the /proc directory (man proc). AFAIK ps does it this way.
- Alex
------------------------------
From: [EMAIL PROTECTED] (Terry Murphy)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 23 Jun 1999 00:29:46 GMT
In article <7kp52j$f94$[EMAIL PROTECTED]>,
Stefaan A Eeckels <[EMAIL PROTECTED]> wrote:
>The problem is that very often a detailed and unambiguous
>design document is *more* difficult to realize, *and* less
>unambiguous than the actual code.
Of course its less unambiguous (inevitably). My concern is, if you dive
straight into coding a complex API (for example, a set of OS system
routines), where is the forethought? Some of the things you need to do
for such a project are: decide on an orthogonal set of functions,
decide on the usage model for the functions, decide on the error
conditions brought up by the routines, devise a strategy for testing
the routines, and document precisely what the routines accomplish.
This is NOT the type of work I see being done by people who pop open VI
or EMACS and start coding, but is the type of work necessary to produce
robust code and products.
>I'm quite sure Sun, HP, SGI, Compaq, SCO etc. have quite
>detailed requirements documents for each new release of
>their respective OSes.
Oh, I am sure you are correct; but the damage has already been done.
I'm sure Intel also goes through quite a formal process to add new
instructions to IA-32, but that doesn't make IA-32 a well designed
ISA. It is the CORE of the product that requires the greatest
attention to detail, and this is what Unix was missing (indeed, several
of the now key features of Unix, such as portability by way of "C", and
software resuability by way of pipes, were not added until several
years after the original project began).
To be fair, Unix was more of an exploratory/reseach project and not
really intended to be a product, and this sort of engineering is
necessary. But, of course, projects like these need to be engineered
into workable products, and not just put out in unfinished form. I
see open source as more exploratory- than product-oriented, and I'm
not even sure many would disagree with that.
>The reason Open Source (no flames please) is so often
>successful is that source code is the best specification
>and design language available.
There are many of us who would argue that open source is not
successful (technically) at all. The main successful Open Source
projects are simply implementations of well understood systems, such as
the Linux kernel or Apache, and tend to require minimal API or user
interface design, and are tested by brute force methods (e.g. release
to a lot of users and see if it works for them). I don't see this model
being extended to original, high quality, and innovative products, such
as say IE5 (c.f. Mozilla as a failure as far as that goes). There are
SOME exceptions: the GIMP and GNOME, for example, are turning out
REASONABLY well, but those exceptions are few and far between, and
really do not compare to high quality, commerical applications.
-- Terry
------------------------------
From: [EMAIL PROTECTED] (Stefaan A Eeckels)
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: 23 Jun 1999 21:48:08 GMT
In article <7kp9pq$9gg$[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Terry Murphy) writes:
> In article <7kp52j$f94$[EMAIL PROTECTED]>,
> Stefaan A Eeckels <[EMAIL PROTECTED]> wrote:
>
>>The problem is that very often a detailed and unambiguous
>>design document is *more* difficult to realize, *and* less
>>unambiguous than the actual code.
>
> Of course its less unambiguous (inevitably). My concern is, if you dive
> straight into coding a complex API (for example, a set of OS system
> routines), where is the forethought? Some of the things you need to do
> for such a project are: decide on an orthogonal set of functions,
> decide on the usage model for the functions, decide on the error
> conditions brought up by the routines, devise a strategy for testing
> the routines, and document precisely what the routines accomplish.
> This is NOT the type of work I see being done by people who pop open VI
> or EMACS and start coding, but is the type of work necessary to produce
> robust code and products.
Your portraying of the situation is too polarized. It's
impossible to just open vi and start coding --you'd at least
need to know what you're going to code.
That being said, a lot of recreational programming is indeed
as you describe.
The core UNIX API was carefully designed; a lot of the concepts
came straight from Multics, and if ever an OS project was "designed"
Multics was it. It was so complete, and so comprehensive, that
when it finally ran, it was so slow as to be unusable. But sure,
it was "professionally designed". I'm quite sure Multics would
run quite well on today's hardware, but somehow it seems to have
lost its relevancy.
Any system that lives longer than a few years is bound to be
modified; even the most open and flexible design cannot foresee
the requirements of the future (one can try, but the rate of
success is quite low :-). As a result, applying 20/20 hindsight
will indeed show warts and flaws. That does not mean the original
was not designed --hell, UNIX is 30 years old, and when it was
designed the target platform had less power than a Psion 5.
The simple fact that the concepts embodied in the OS are still
relevant today is an amazing tribute to the quality of the
original design (or concepts, if you wish).
>
>>I'm quite sure Sun, HP, SGI, Compaq, SCO etc. have quite
>>detailed requirements documents for each new release of
>>their respective OSes.
>
> Oh, I am sure you are correct; but the damage has already been done.
> I'm sure Intel also goes through quite a formal process to add new
> instructions to IA-32, but that doesn't make IA-32 a well designed
> ISA. It is the CORE of the product that requires the greatest
> attention to detail, and this is what Unix was missing (indeed, several
> of the now key features of Unix, such as portability by way of "C", and
> software resuability by way of pipes, were not added until several
> years after the original project began).
Pray tell me how UNIX would have been any better if pipes and 'C'
would have been invented in 1969, or if the original ideas would
have been abandoned in 1974 when it was recoded in 'C'?
Requiring *all* the concepts to be invented (stumbled upon) before
a line of code is written is just plain impossible. Limiting yourself
to what you've originally committed to paper is just plain stupid
(but it might be a contractual requirement, in which case I refrain
from commenting).
UNIX69 implemented a number of core ideas that proved to be useful,
and stimulating. The fact that UNIX wasn't a contractually limited
"quality commercial development" enabled the Bell Labs guys to use
the intellectual stimulus it provided to evolve the original design
into a coherent whole by adding such things as pipes, proving the
intrinsic value of the "everything is a file" concept.
> To be fair, Unix was more of an exploratory/reseach project and not
> really intended to be a product, and this sort of engineering is
> necessary. But, of course, projects like these need to be engineered
> into workable products, and not just put out in unfinished form. I
> see open source as more exploratory- than product-oriented, and I'm
> not even sure many would disagree with that.
I agree fully. I just don't believe that the only valuable form
of software is found in colourful boxes on computer shop shelves.
>
>>The reason Open Source (no flames please) is so often
>>successful is that source code is the best specification
>>and design language available.
>
> There are many of us who would argue that open source is not
> successful (technically) at all. The main successful Open Source
> projects are simply implementations of well understood systems, such as
> the Linux kernel or Apache, and tend to require minimal API or user
> interface design, and are tested by brute force methods (e.g. release
> to a lot of users and see if it works for them).
Or if you're called Microsoft, you even get the poor sods to pay for
the privilege of testing the stuff for you.
> I don't see this model
> being extended to original, high quality, and innovative products, such
> as say IE5 (c.f. Mozilla as a failure as far as that goes).
Don't make me laugh. IE5 an original, high quality, innovative product.
ROTFLMAO. Really. Ever looked at the credits? The original code base
for Netscape *and* IE is Mosaic. Carefully designed indeed. Both
browsers are incredible hacks.
> There are
> SOME exceptions: the GIMP and GNOME, for example, are turning out
> REASONABLY well, but those exceptions are few and far between, and
> really do not compare to high quality, commerical applications.
And would you kindly name just *one* of these "high quality, commercial
applications"?
I know *no* commercial application that is not a (more or less
successful) evolution of an extremely limited original code base.
None of these products respond to carefully written and conscienciously
maintained requirements and design documents. I do challenge you to
name just *one* commercial application, OS, or just *any* piece of code
that conforms to the development method you described.
--
Stefaan
--
PGP key available from PGP key servers (http://www.pgp.net/pgpnet/)
___________________________________________________________________
Perfection is reached, not when there is no longer anything to add,
but when there is no longer anything to take away. -- Saint-Exup�ry
------------------------------
From: Erik de Castro Lopo <[EMAIL PROTECTED]>
Subject: Re: NT kernel guy playing with Linux
Date: Thu, 24 Jun 1999 08:35:46 +1000
B. James Phillippe wrote:
>
> On Tue, 22 Jun 1999, Holden McGroin wrote:
>
> > I must say, I'm a little disappointed in the linux's apparent
> > non-reentrancy. Rubini says there's a global semaphore that is grabbed
> > every time a process enters the kernel.
>
> You're really critiquing old technology; linux-2.2 resolves many of the
> problems you've encountered. And linux-2.3 (currently in development) is
> going even further.
<snip>
For a really up-to-date discussion of where the kernel is up to have a look
at :
http://www.technetcast.com/tnc_program.phtml?program_id=17
Erik
--
+-------------------------------------------------+
Erik de Castro Lopo [EMAIL PROTECTED]
+-------------------------------------------------+
Fifty years of programming language research, and we end up with C++ ???
--Richard A. O'Keefe
------------------------------
From: Monkey Boy <[EMAIL PROTECTED]>
Subject: Kernel data to user space files
Date: Wed, 23 Jun 1999 11:32:09 -0700
Reply-To: [EMAIL PROTECTED]
I am doing security reasearch in Linux and have been reading up on the
kernel and there is a lack of documentation on many features. What I
need to do is move large amounts of data from inside the kernel to a
file on the harddrive so that it can later be analyzed. The data comes
erraticly and in about 32K chunks. Some one told me to use mmap and
copy_to_user but would say any more about it. I looked in the
documentation I have and I can't find much on either of these. I think
I understand copy_to_user but not how to use mmap to map a file out on
the hard drive. Could someone direct me to some documentation/examples
or explain any of this to me? I am proficient in C but not on the
kernel stuff.
michael
------------------------------
From: Dan Eble <[EMAIL PROTECTED]>
Subject: Increasing Max TCP Connections
Date: Wed, 23 Jun 1999 15:54:52 -0400
I want to modify the kernel's parameters for the maximum number of
connections. Where are the relevant #defines?
(I need to allow for somewhere between 2000 and 10000 connections.)
Please respond via email. Thanks.
--
Dan Eble <[EMAIL PROTECTED]>
------------------------------
From: [EMAIL PROTECTED] (Jonathan A. Buzzard)
Subject: Re: You can now use Winmodems in Linux!!!!!!!
Date: Wed, 23 Jun 1999 23:54:15 +0100
In article <[EMAIL PROTECTED]>,
Medical Electronics Lab <[EMAIL PROTECTED]> writes:
[SNIP]
> The winmodem is just a digitizer that does DMA into a buffer. The
> processor has to convert the audio bits to multiple tone data, and
> then to data bits. It's straight forward data manipulation. There
> is no reason we can't write a driver for any winmodem.
>
What an absolute load of rubbish. The vast majority of winmodems have
DSP that do all the modulation etc. What they don't provide is a
standard serial interface and an AT command interprator. Try reading
some of the literature for winmodem chipsets. The Lucent Mars chipset,
used in Toshiba and Compaq laptops would be a good place to start.
JAB.
--
Jonathan A. Buzzard Email: [EMAIL PROTECTED]
Northumberland, United Kingdom. Tel: +44(0)1661-832195
------------------------------
From: [EMAIL PROTECTED] (Hisham Petry)
Subject: promiscuous ethernet packets
Date: Wed, 23 Jun 1999 19:19:41 GMT
Can anyone tell me how to send and receive non-IP packets on eth0. If
I bind to a socket I can write and read raw IP packets, but I need to
be able to change the ethertype. Thanks
Hisham Petry
[EMAIL PROTECTED]
------------------------------
From: Erik de Castro Lopo <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Why not C++
Date: Thu, 24 Jun 1999 09:29:57 +1000
Ralph Glebe wrote:
>
> I'v started to do some development on the linux platform. Looking at some of
> the source code around, I noticed that it is all C as opposed to C++.
> Although I've been a C programmer for many years, in the last year most of
> my programming has been in C++, and I've come to appreciate some of its
> benefits. Still, it makes me wonder if I'm headed for trouble trying to
> program in C++ on the linux platform. Are all the programs in C because:
>
> 1) The legacy programs were written in C, and its easier to keep them that
> way.
This is true. Most of the GNU utilities were written some time ago.
> 2) There is something inferior about the code produced with the GNU C++
> compiler.
This is not the case AFAIK.
> 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.
Nope, most people would get the C++ libs when they install their system
from
CDROM.
I personally prefer working in C for most things because there does not
seem to be any real tangible benefits (for me) to use C++. I find C++
far less readable, less maintainable and usually more trouble than its
worth.
Hope this helps,
Erik
--
+-------------------------------------------------+
Erik de Castro Lopo [EMAIL PROTECTED]
+-------------------------------------------------+
BSD: A psychoactive drug, popular in the 80s, probably developed at UC
Berkeley or thereabouts. Similar in many ways to the prescription-only
medication called "System V", but infinitely more useful. (Or, at least,
more fun.) The full chemical name is "Berkeley Standard Distribution".
------------------------------
From: Mario Klebsch <[EMAIL PROTECTED]>
Subject: Re: NT kernel guy playing with Linux
Date: Wed, 23 Jun 1999 18:18:15 +0200
hi!
[EMAIL PROTECTED] (Holden McGroin) writes:
>The things I like about NT are:
>1) the IRP model. That is, each request from user mode is handed to
>the kernel as an IRP (IO Request Packet). ALL drivers receive IRPs.
>Any driver can generate a new IRP for a lower driver, or pass a
>received IRP onto a lower driver. Therefore a driver doesn't know or
>care whether a user mode app is talking it or another driver. IRPs
>have a stack mechanism to allow a single IRP (with associated user
>mode buffer etc) to pass through multiple layers of drivers. Any 3rd
>party driver can install itself as a "filter" on top of any other
>driver.
Sounds like SYSV streams. You could stack modules and drivers onto each
other. Unfortunately, they never were popular (probably because of their
origin at AT&T), so Linux did not reinvent this wheel.
73, Mario
--
Mario Klebsch [EMAIL PROTECTED]
------------------------------
From: Bill Anderson <[EMAIL PROTECTED]>
Crossposted-To: alt.os.linux,comp.os.linux.advocacy,comp.os.misc,comp.unix.advocacy
Subject: Re: TAO: the ultimate OS
Date: Wed, 23 Jun 1999 17:21:57 -0600
"Vladimir Z. Nuri" wrote:
>
> Christopher B. Browne ([EMAIL PROTECTED]) wrote:
>
> : The advantage to the "lack" of forced support is that it doesn't force
> : people into a particular approach by making it permeate the kernel.
> : Supposing there was, in the Linux kernel, a record-oriented DB scheme not
> : unlike the (boo, hiss!) "Windows Registry," people would be encouraged to
> : push things into The Database that don't fit properly.
>
> I don't understand the implied comparison of the registry to SQL or other
> databases.. it seems to me they are fundamentally designed to accomplish
> different means.. the registry is just "program data/parameters"..
> databases are general purpose /high performance
> data holders/indexers/sorters/retrievers etc.
>
> also: I don't like the windows registry implementation either (have
> had my share of its incredibly awkward interface), but I think
> the overall idea of the OS imposing a sort of ordering on the way that
> apps store their data is appropriate...
An OS should not dictate how a random app stores it's data.
> question for you: would there be a way to implement the registry in
> a more streamlined way in which you wouldnt "boo hiss" it.. also for what
> reasons are you "boo hissing" it?
A few reasons:
o A failure of a proprietary, binary dataset results in total system
failure. Solution: reinstall OS.
o In order to fix it, it needs to have a running system with full a
toolsuite.
o Buggy
o Instable
o Overly Complex
Just off the top.
--
Bill Anderson Linux Administrator
MCS-Boise (ARC) [EMAIL PROTECTED]
My opinions are just that; _my_ opinions.
------------------------------
From: [EMAIL PROTECTED]
Subject: Disney vacation 6594
Date: 23 Jun 1999 22:55:27 GMT
Would you like to find out where can you get, the best priced ever, Disney vacation
packages?
Go To: http://www.altavista.com/cgi-bin/query?pg=q&kl=XX&q=Disney+vacation+packages
and you will find.
Thank you.
fhvwyvrxnjzxycbefqkctjmkfxomkhuvqe
------------------------------
From: [EMAIL PROTECTED] (ellis)
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.misc
Subject: Re: Run in background
Date: 23 Jun 1999 23:49:16 GMT
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.
--
http://www.fnet.net/~ellis/photo/
------------------------------
From: [EMAIL PROTECTED] (Adrian 'Dagurashibanipal' von Bidder)
Subject: Re: Is there a virtual floppy device?
Date: Wed, 23 Jun 1999 20:06:22 GMT
On Thu, 24 Jun 1999 00:11:51 +1000, scottxb <[EMAIL PROTECTED]>
wrote:
>
>I am looking for a device driver that emulates a floppy
>device (especially a 2.88MB floppy device).
>
Hi!
Compile the loopback device into the kernel (or as a module) - and
read the accompanying help texts (Documentation/fs/loopback.txt ?).
The package (together with a newer /modified?) mount program allows
you to handle files like disks (fdisk them, format them, mount them,
just do as you like).
Greets from over there
Dagurashibanipal
[EMAIL PROTECTED]
--
Hi! I'm a .signature virus!=20
Copy me into your ~/.signature to help me spread!
------------------------------
From: Frank Sweetser <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps,comp.os.linux.networking
Subject: Re: Why not C++
Date: 23 Jun 1999 19:08:50 -0400
"Ralph Glebe" <[EMAIL PROTECTED]> writes:
> I'v started to do some development on the linux platform. Looking at some of
> the source code around, I noticed that it is all C as opposed to C++.
> Although I've been a C programmer for many years, in the last year most of
> my programming has been in C++, and I've come to appreciate some of its
> benefits. Still, it makes me wonder if I'm headed for trouble trying to
> program in C++ on the linux platform. Are all the programs in C because:
>
> 1) The legacy programs were written in C, and its easier to keep them that
> way.
> 2) There is something inferior about the code produced with the GNU C++
> compiler.
> 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.
i would say it's mostly 1) and 2), though 2) is getting better (esp with egcs).
--
Frank Sweetser rasmusin at wpi.edu fsweetser at blee.net | PGP key available
paramount.ind.wpi.edu RedHat 5.2 kernel 2.2.5 i586 | at public servers
> I was wondering why the ext2fs filesystems was developed for Linux
>rather than using the BSD4.4 Berkeley Fast Filesystem.
Because it was a real fun to design and program it...
-- Remy Card
------------------------------
** 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
******************************
