Linux-Development-Sys Digest #189, Volume #7 Mon, 13 Sep 99 19:14:10 EDT
Contents:
Named pipes ("Willem Joosten")
Linux for SGI (Hong Hu)
Re: graphical debugging, development environments? (Mark Hatch)
major.minor.patch numbering ("Carl Karsten")
Re: Porting Motif based software... (Mark Hatch)
Re: Linux standards compliance (Bill Anderson)
Re: Richards Stevens died (Andrew Gabriel)
Re: threads (Philip Brown)
Re: Named pipes (Paul J Collins)
Re: threads (David Schwartz)
Re: Named pipes (Paul J Collins)
Re: Max threads and TCP connections? (bill davidsen)
Re: threads (Leslie Mikesell)
Re: Max threads and TCP connections? (bill davidsen)
Re: Linux standards compliance (Leslie Mikesell)
----------------------------------------------------------------------------
From: "Willem Joosten" <[EMAIL PROTECTED]>
Subject: Named pipes
Date: Mon, 13 Sep 1999 20:35:24 +0200
Hi,
are the named pipes used in Linux usable to connect to a Windows NT machine?
I'm looking for a way to communicate between perl scripts running on my
Linux server and my NT desktop machine. I'm used to using pipes between NT
apps and don't want to start digging into TCP/IP (yet).
Any other suggestions, links to docs/how-to's are welcome.
Regards,
Willem Joosten
------------------------------
From: Hong Hu <[EMAIL PROTECTED]>
Subject: Linux for SGI
Date: Mon, 13 Sep 1999 10:46:31 -0500
==============D7F6852C43275F51C7BF2D40
Content-Type: text/plain; charset=gb2312
Content-Transfer-Encoding: 7bit
Does anyone know if it is possible to install linux on a old SGI machine? (Say SGI
Indigo)--
===============================================
Hong Hu *
Nieuwland Science Hall 251 *
Department of Chemistry&Biochemistry *
University of Notre Dame *
Notre Dame, IN 46556 *
===============================================
Ph: 219-6313904(office) *
Email [EMAIL PROTECTED] *
===============================================
==============D7F6852C43275F51C7BF2D40
Content-Type: text/html; charset=gb2312
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<pre>Does anyone know if it is possible to install linux on a old SGI machine? (Say
SGI Indigo)--
===============================================
Hong
Hu
*
Nieuwland Science Hall
251
*
Department of
Chemistry&Biochemistry *
University of Notre
Dame
*
Notre Dame, IN
46556
*
===============================================
Ph:
219-6313904(office)
*
Email
[EMAIL PROTECTED]
*
===============================================</pre>
</html>
==============D7F6852C43275F51C7BF2D40==
------------------------------
From: Mark Hatch <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: graphical debugging, development environments?
Date: 13 Sep 1999 12:57:20 PDT
Reply-To: [EMAIL PROTECTED]
Metrowerks's Code Warrior is good, but Cygnus' Code Fusion should also
be considered (www.cygnus.com).
Mark
Jason Rosenberg wrote:
> My previous post entitled "development gui's for linux"
> seems to have been misinterpreted, so I'll try again...
>
> I am interested in knowing about the various integrated
> compiling/debugging environments with graphical interfaces available
> for linux, either free or otherwise. CodeWarrior? GNU?
>
> I am also interested in those that exist for multiple architectures,
> such as Intel, Alpha, SPARC, etc.
>
> Thanks,
>
> Jason
------------------------------
From: "Carl Karsten" <[EMAIL PROTECTED]>
Subject: major.minor.patch numbering
Date: Tue, 14 Sep 1999 04:07:32 -0500
Where can I find the GNU version numbering standard? I am trying to propose
using it, but I don't have a good description of what "it" is.
Carl
please cc me when replying.
------------------------------
From: Mark Hatch <[EMAIL PROTECTED]>
Crossposted-To: comp.os.linux.development.apps
Subject: Re: Porting Motif based software...
Date: 13 Sep 1999 13:39:02 PDT
Reply-To: [EMAIL PROTECTED]
We ported our GUI builder (linux.ics.com) to Linux on the back of
Metrolink's Motif (XiGraphics also has a fine release of Motif worth
checking out too). A GUI builder is probably one of the most stressful
tests for any Motif/X port, because we exercise many of the corner cases
of the Motif/X API to provide the WYSIWYG aspect of our tool. I happy to
report that things really went very well with very few problems. If we
could port with minimal effort, I suspect that most Motif applications
will have few problems.
However, you should check to see if you use any commercial widgets and
if they have been ported to Linux/Motif and what *version of Motif*.
Mixing widget sets, one of which was compiled and linked for Motif 1.2.x
and one of which was compiled and linked with Motif 2.x is a risky
business...
In regards to lesstif, it is still not fully Motif compatible, but
should work for many applications. It is definitely worth a try. Many
users of our GUI builder use lesstif for their generated code without
any problems. The lesstif mailing list is active and new releases seem
to be turned pretty quickly to fix reported bugs.
However, the widget area is again a place to look into. With lesstif,
you have to be concerned with not only third party widgets, but also any
that you may have written too. Some widgets were written using internal
Motif functions, that are not completely and/or publically documented.
Since they are not documented, the lesstif folks cannot clone them. As a
result, some widgets will not port to lesstif. For example, our ViewKit
and EPak libraries cannot port to lesstif because they were written
using these calls. Unfortunately, since the know of these functions is
proprietary to the Open Group, we can't tell the lesstif people how to
implement them. :-(
Regards,
Mark
Jason Rosenberg wrote:
> I am interested in the issues involved with porting
> existing software to linux which is based on Motif.
>
> Are there any free Motif implementations out there?
>
> What is Lesstif?
>
> What is the cost and licensing agreements for the
> official OSF Motif?
>
> Are there any reasonable tools for wrapping motif
> calls into something else, like gtk?
>
> Thanks,
>
> Jason
------------------------------
From: Bill Anderson <[EMAIL PROTECTED]>
Subject: Re: Linux standards compliance
Date: Mon, 13 Sep 1999 14:39:12 -0600
Leslie Mikesell wrote:
>
> In article <[EMAIL PROTECTED]>,
> Horst von Brand <[EMAIL PROTECTED]> wrote:
> >
> >>And if none of them want to write the thing you need, there is
> >>no way to encourage them. If there were, we might have an NFS
> >>that intoperates with others, DVD drivers, full USB support and
> >>so on.
....
> My next desktop machine will have DVD, USB devices, and probably
> eventually digital video via firewire. What OS do you recommend?
> It will likely store files on a networked Linux box. I don't
> see much hope of it actually running Linux in the near future.
What USB devices? Many work now.
DVD: as a drive, yes, to watch encoded movies on it? No. Too expensive,
etc. not even NT has this AFAIK,
...
> There is nothing wrong with the open development process for the places
> it works. I just think it is unrealistic to expect that model to
> work in all cases
I agree with this.
--
Bill Anderson Linux/Unix Administrator, Security
Analyst
ESBU (ARC) [EMAIL PROTECTED]
My opinions are just that; _my_ opinions.
------------------------------
From: [EMAIL PROTECTED] (Andrew Gabriel)
Crossposted-To: comp.unix.programmer,comp.os.linux.development.apps
Subject: Re: Richards Stevens died
Date: 13 Sep 1999 20:08:03 GMT
In article <[EMAIL PROTECTED]>,
joeh <[EMAIL PROTECTED]> writes:
>Are there any biographies of Richard on the inet?
>I have 2 of his UNIX books, and yet don't know anything about him
There was a biography on his home page, but that's been inaccessible
for a while now. The following might still point to the entry in his
local paper (but will probably not do so much longer)...
http://www.bigdealclassifieds.com/classified/plsql/search_classifieds?in_type=results&in_start=0&in_search_text=Stevens&in_dpubdate=
--
Andrew Gabriel
Consultant Software Engineer
------------------------------
From: [EMAIL PROTECTED] (Philip Brown)
Subject: Re: threads
Reply-To: [EMAIL PROTECTED]
Date: 13 Sep 1999 20:45:47 GMT
On Sun, 12 Sep 1999 20:20:52 -0700, [EMAIL PROTECTED] wrote:
>...
> There no excuse for wasing the CPU, whether or not there's plenty of it
>to go around. It's senseless to have to switch contexts ten times just
>because ten connections have received I/O. It's much nicer to wake one
>process which can run in a non-blocking fashion and do all ten I/Os.
>It's nicer to all the other processes too since the total CPU used is
>less.
You are stuck thinking about a single-cpu box.
This is NOT true of a multicpu box. Nor is it true under certain kinds of
data streams.
[Sometimes the "front bit" is more important than the rest of the data.
You want it as soon as possible]
--
[Trim the no-bots from my address to reply to me by email!]
[ Do NOT email-CC me on posts. Pick one or the other.]
http://thomas.loc.gov/cgi-bin/bdquery/z?d105:SN01618:@@@D
The word of the day is mispergitude
------------------------------
From: Paul J Collins <[EMAIL PROTECTED]>
Subject: Re: Named pipes
Date: 13 Sep 1999 21:51:44 +0100
>>>>> "Willem" == Willem Joosten <[EMAIL PROTECTED]> writes:
Willem> Hi, are the named pipes used in Linux usable to connect to
Willem> a Windows NT machine? I'm looking for a way to
Willem> communicate between perl scripts running on my Linux
Willem> server and my NT desktop machine. I'm used to using pipes
Willem> between NT apps and don't want to start digging into
Willem> TCP/IP (yet).
No, named pipes in Unix are a type of file and only processes on the
same machine can communicate using them. You will need to learn
sockets.
But really, sockets are not all that hard. There are a number of good
Unix books that cover them throughly. Something by Stevens would
probably fit the bill.
Paul.
--
Paul Collins <[EMAIL PROTECTED]> Public Key On Keyserver.
Fingerprint: 88BA 2393 8E3C CECF E43A 44B4 0766 DD71 04E5 962C
"I am a stranger in a strange land,
distracted by bright and shiny objects."
------------------------------
From: David Schwartz <[EMAIL PROTECTED]>
Subject: Re: threads
Date: Mon, 13 Sep 1999 14:21:55 -0700
Philip Brown wrote:
> [Sometimes the "front bit" is more important than the rest of the data.
> You want it as soon as possible]
In this case, the thread that blocks on I/O should do as little 'work'
as possible. That way, you'll get all the front bits as soon as
possible.
I just try to keep things as protocol-independent as possible for
simplicity. But obviously, implementation details are going to vary
depending upon the specifics of the application.
DS
------------------------------
From: Paul J Collins <[EMAIL PROTECTED]>
Subject: Re: Named pipes
Date: 13 Sep 1999 21:55:15 +0100
>>>>> "Paul" == Paul J Collins <[EMAIL PROTECTED]> writes:
>>>>> "Willem" == Willem Joosten <[EMAIL PROTECTED]> writes:
Willem> Hi, are the named pipes used in Linux usable to connect to
Willem> a Windows NT machine? I'm looking for a way to
Willem> communicate between perl scripts running on my Linux
Willem> server and my NT desktop machine. I'm used to using pipes
Willem> between NT apps and don't want to start digging into
Willem> TCP/IP (yet).
Paul> No, named pipes in Unix are a type of file and only
Paul> processes on the same machine can communicate using them.
Paul> You will need to learn sockets.
Paul> But really, sockets are not all that hard. There are a
Paul> number of good Unix books that cover them throughly.
Paul> Something by Stevens would probably fit the bill.
Foolishly, I neglected to supply links. Try this one:
http://www.ee.mu.oz.au/linux/programming/
Lots of stuff there.
Paul.
--
Paul Collins <[EMAIL PROTECTED]> Public Key On Keyserver.
Fingerprint: 88BA 2393 8E3C CECF E43A 44B4 0766 DD71 04E5 962C
"I am a stranger in a strange land,
distracted by bright and shiny objects."
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Subject: Re: Max threads and TCP connections?
Date: 13 Sep 1999 22:05:33 GMT
In article <[EMAIL PROTECTED]>,
No Spam <[EMAIL PROTECTED]> wrote:
| But what I'm really getting at is comments or thoughts on actually
| servicing these 1 million+ connections. Assuming i have infinite
| network bandwidth, I still have to have data structures and shit
| associated with each of the connections on the server to actually
| respond to stuff coming in on them. Additionally, I assume on Linux
| each of these TCP connections will use some default TCP window size
| which is some number of bytes of buffers. No to mention TCP timers and
| other crap.
Well, you can have 2GB easily on an Intel machine, and there's a 4GB
patch which was written and contributed by someone, SuSE comes to mind,
but it may only be for 2.3.x kernels. You might not run out of resources
here.
| So 1 million of these suckers cohabitating on one machine (hopefully)
| will eat how much memory? Does linux kernel create thread to handle
| each TCP connection? what about timers for handling the TCP protocol
| itself. Then the big one, I essentailly *can't* simply create a thread
| or process to handle each connection do to the shear number. So is
| there a way to have an ultra light chunk of C code sit on top of each
| connection (perhaps one glorious process with a magic TCPIN and TCPOUT
| function) and process incoming data and outgoing data basically in a
| callback from TCP without going through thread or other sychronization
| object overhead?
You could attack this by using multiple processes, each of which used
select() to handle some reasonable number of sockets. I would think
limiting to about 100-200 sockets/process would be reasonable. I would
have to know more about the application to know if you caould use
threads, I would try processes first.
The whole solution sems like a pretty brute force solution from what
you've told us. In general when you are looking for "how big can I
possibly make a single server" for anything, it's time to step back and
see if a clever data sharding cluster would be a better solution, for
cost, reliability, performance, whatever.
The consensus seems to be that you might stretch a server to that
size, I'm not convinced you should. If the transaction rate on these
sockets is more than minimal you will probably run out of several more
things we haven't addressed. This has been a good thinking exercise, but
I suspect it as a solution.
Let us know if you actually do this, I may have a few tools which
would be useful, which I built when I went to machines with >1GB, etc.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
I thought I had forgotten how to throw a boomerang, but it's
all coming back to me...
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
Subject: Re: threads
Date: 13 Sep 1999 13:51:02 -0500
In article <[EMAIL PROTECTED]>,
David Schwartz <[EMAIL PROTECTED]> wrote:
>
>> > There is a tremendous difference between a 'read' call that completes
>> >immediately and a read call that requires putting the current process to
>> >sleep and then scheduling a new one.
>>
>> And which happens more often? I don't think I've ever written a program
>> that wasn't I/O bound. I'll concede that it is possible, but I doubt
>> if it is common, certainly not if the read() is interacting with
>> humans.
>
> I think we're talking past each other.
>
> In a well-designed server program, you rarely (if ever) call read on a
>socket unless you already know that data is available (due to a 'poll'
>or 'select'). Blocking reads on sockets are expensive, so why do them
>when you can avoid them?
I'm missing something here... How can 2 system calls be cheaper
than one? The only reason to select() is if you have something
to do when there is no input, and a well-designed server program
often doesn't. A blocking read lets the kernel schedule some
equally important other process at a time when this one is
idle.
>> > Sure, and therefore it has to do a process context switch each time,
>> >with a pass through the scheduler.
>>
>> So if we assume we are processing faster than the I/O can happen, it
>> seems like the right thing to do, since the scheduler is the thing
>> that knows where the I/O just completed. This seems especially
>> true if there are many different programs running on the machine.
>
> There no excuse for wasing the CPU, whether or not there's plenty of it
>to go around. It's senseless to have to switch contexts ten times just
>because ten connections have received I/O. It's much nicer to wake one
>process which can run in a non-blocking fashion and do all ten I/Os.
How do you do ten i/o's at once when you are processing faster than
the i/o? You'll service the first one, complete it, sit in select,
service the next, and so on, doing 2 system calls on every input
instead of the one it would take seperate processes doing blocking
reads.
>It's nicer to all the other processes too since the total CPU used is
>less.
I'm not conviced, but would like to know why you think this is true.
Are there any benchmarks that test both approaches to see if there
is some level of i/o where the select() method makes it likely
that you can read() bigger chunks and start saving system calls?
Les Mikesell
[EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (bill davidsen)
Subject: Re: Max threads and TCP connections?
Date: 13 Sep 1999 22:22:38 GMT
In article <[EMAIL PROTECTED]>,
David Schwartz <[EMAIL PROTECTED]> wrote:
| Andrey Fisunenko wrote:
| > How you got 16000? Those test compiled and executed under FreeBSD creates
| > pthreads while system has enough memory.
|
| Not 16,000 threads. You'd never have enough memory for all those
| stacks. Why would anyone even attempt anything so stupid?
Stupid == I never had a use for it?
When writing a server you can do several things:
1 - single process and select
2 - process per client
3 - thread per client
Now (1) has a major defect, you get very little benefit from SMP. So
there might be reason to try (2), particularly if you have used BSD,
which handles thread memory allocation somewhat better. Or at any rate
seems to run more threads in less VM, which is "better" modulo the
requirements of your application.
Now Linux seems to do (3) better than BSD, but it would seem that
memory control could use page faults to up the size of stack VM as well
as physical memory. Many threads don't need a lot of stack, why allocate
it?
I have never run out of threads in Linux, but I have applications
which undoubtedly would do so if I put them on a machine able to handle
that many clients.
I don't see that many threads is less well chosen than many processes,
it's just that some operating systems don't do threads very well.
--
bill davidsen <[EMAIL PROTECTED]> CTO, TMR Associates, Inc
I thought I had forgotten how to throw a boomerang, but it's
all coming back to me...
------------------------------
From: [EMAIL PROTECTED] (Leslie Mikesell)
Subject: Re: Linux standards compliance
Date: 13 Sep 1999 13:23:35 -0500
In article <[EMAIL PROTECTED]>,
Horst von Brand <[EMAIL PROTECTED]> wrote:
>
>>And if none of them want to write the thing you need, there is
>>no way to encourage them. If there were, we might have an NFS
>>that intoperates with others, DVD drivers, full USB support and
>>so on.
>
>You could contract it out too, you know... Linux is as much yours as Donald
>Becker's, or Alan Cox', or anybody else's.
Or I can use an OS where the vendor is encouraged to supply the
driver with the device. It is counterproductive to expect
users or volunteers to keep up with rapidly changing technology
or to expect vendors to release information that they may have
licensed under non-disclosure agreeements themselves. Or for
someone other than the device vendor to fund licensing of
patented technology.
>> As it is, the best you can do is try to put all your
>>devices on the other end of an ethernet and try to use the
>>network interfaces as the 'standard' device layer to hide
>>your netapp, terminal server, X display, etc. instead of waiting
>>for native Linux support to match the hardware you can buy.
>
>Don't be ridiculous. What hardware exactly is the one you can't afford and
>is the lowest cost Linux-friendly alternative?
My next desktop machine will have DVD, USB devices, and probably
eventually digital video via firewire. What OS do you recommend?
It will likely store files on a networked Linux box. I don't
see much hope of it actually running Linux in the near future.
>You'd have to compare to the changelogs for equivalent closed development to
>make a valid point here. The development of Linux takes place in the open,
>driven by its user's public complaints and requests, so you _see_ the bugs
>and mistakes and their fixes, whereas with closed development you only see a
>"patchset" or "new version" now and then that might (or might not) fix four
>favorite peeve; no further clues, no possibility (except for obscene amounts
>of money) to even think about influencing the development in any way.
Yes, the final result of a few million people testing something and
reporting bugs can be very nice after several revisions. However
it can also be nice to have some paid quality control testing done
before a product is released.
>And yes, there are several "not one man jobs" in Linux. And development has
>worked fine so far, with teams that might never have seen each other in
>person. If not, you would have nothing to complain about here in the first
>place ;-)
There is nothing wrong with the open development process for the places
it works. I just think it is unrealistic to expect that model to
work in all cases so the choice becomes one of keeping the OS
intentionally limited or not. I like Linux and would prefer
that it didn't have any intentional limits.
Les Mikesell
[EMAIL PROTECTED]
------------------------------
** 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
******************************
