547 lines
22 KiB
Plaintext
547 lines
22 KiB
Plaintext
From: Digestifier <Linux-Development-Request@senator-bedfellow.mit.edu>
|
|
To: Linux-Development@senator-bedfellow.mit.edu
|
|
Reply-To: Linux-Development@senator-bedfellow.mit.edu
|
|
Date: Thu, 8 Sep 94 13:13:14 EDT
|
|
Subject: Linux-Development Digest #139
|
|
|
|
Linux-Development Digest #139, Volume #2 Thu, 8 Sep 94 13:13:14 EDT
|
|
|
|
Contents:
|
|
Re: Novell routing between IPX/TCPIP? (Mark Evans)
|
|
Re: News Spool File System - new filesystem type?? (Bill Davidsen)
|
|
Re: News Spool File System - new filesystem type?? (Bill Davidsen)
|
|
Re: Alpha Linux (Anton Ertl)
|
|
Re: Serial port problems (Joerg Wedeck)
|
|
Re: Survey: who wants f77,cc,c++,hpf for linux? (Martien Hulsen)
|
|
Re: Multiprocessing Pentium Systems (Alan Cox)
|
|
Re: Alpha Linux (Steven A. Reisman)
|
|
Re: A thought to improve security (Alan Cox)
|
|
Re: Threads for Linux (Rene Angel Sepulveda)
|
|
Re: Survey: who wants f77,cc,c++,hpf for linux? (Highlander)
|
|
Re: Survey: who wants f77,cc,c++,hpf for linux? (Michel Anders)
|
|
|
|
----------------------------------------------------------------------------
|
|
|
|
From: evansmp@mb4715.aston.ac.uk (Mark Evans)
|
|
Subject: Re: Novell routing between IPX/TCPIP?
|
|
Date: Thu, 8 Sep 1994 09:04:48 GMT
|
|
|
|
Rob Janssen (rob@pe1chl.ampr.org) wrote:
|
|
: In <34i23i$9o@nkosi.well.com> cames@well.sf.ca.us (Bob Kaehms) writes:
|
|
|
|
|
|
: >(the way tin's acting, I may have asked this a while back, but since
|
|
: >I didn't hear any replies....)
|
|
|
|
: >Does anyone have any ideas on how I could turn Linux into a router for
|
|
: >both TCPIP and IPX? what would it take to get IPX routing available on
|
|
: >Linux? Buy-in from Novell? Anyone familar enough with IPX to know whether
|
|
: >or not this is doable without Novell?
|
|
|
|
: IPX routing is fully documented by Novell. Much of it is already
|
|
: in Linux.
|
|
|
|
One warning do not set an ethernet driver to promiscuious mode unless you have
|
|
the following patch applied, when you are using IPX.
|
|
|
|
--- /usr/src/linux/net/inet/ipx.c.old Mon Sep 5 11:14:52 1994
|
|
+++ /usr/src/linux/net/inet/ipx.c Mon Sep 5 15:01:08 1994
|
|
@@ -856,7 +861,7 @@
|
|
int free_it=0;
|
|
|
|
/* Rule: Don't forward packets that have exceeded the hop limit. This is fixed at 16 in IPX */
|
|
- if(ipx->ipx_tctrl==16)
|
|
+ if((ipx->ipx_tctrl==16)||(dev->flags&IFF_PROMISC))
|
|
{
|
|
kfree_skb(skb,FREE_READ);
|
|
return(0);
|
|
|
|
Otherwise you will flood the network with IPX packets, and most likely have your netware server consoles
|
|
filled with error messages.
|
|
|
|
------------------------------
|
|
|
|
From: davidsen@elephant.dev.prodigy.com (Bill Davidsen)
|
|
Crossposted-To: news.software.b
|
|
Subject: Re: News Spool File System - new filesystem type??
|
|
Date: 8 Sep 1994 13:19:29 GMT
|
|
|
|
In article <ianm.778965597@miles>, Ian McCloghrie <ianm@qualcomm.com> wrote:
|
|
|
|
:The Right Way to implement this kind of filesystem would be a
|
|
:user-space process, reading and writing the raw device -- essentially
|
|
:just using /dev/hd<foo> as a database. Putting it in the kernel gains
|
|
:you nothing but more kernel bloat.
|
|
|
|
I hate to disagree, but doing it through the kernel gains you portability.
|
|
If you read the last post about why newsrun doesn't kick off automatically,
|
|
you know that authors of news systems have real problems there.
|
|
|
|
For what it's worth, I did a BBS which kept it's own message base instead
|
|
of using one file per message. It worked REALLY well, and I'm rewriting it
|
|
as client server now to solve some locking overhead when multiple processes
|
|
do certain operations.
|
|
|
|
I have thought of writing a complete news system using this method, which
|
|
would restrict reading to NNTP, since the file structure would be all
|
|
diferent. Not a loss, I think. I'm still looking for a fast algorithm to
|
|
find N consecutive bits ON in a bitmap...
|
|
--
|
|
Bill Davidsen, davidsen@tmr.com on weekends.
|
|
"Speaking *from* but not *for* Prodigy"
|
|
|
|
------------------------------
|
|
|
|
From: davidsen@elephant.dev.prodigy.com (Bill Davidsen)
|
|
Crossposted-To: news.software.b
|
|
Subject: Re: News Spool File System - new filesystem type??
|
|
Date: 8 Sep 1994 13:25:55 GMT
|
|
|
|
In article <ROB.94Sep7164407@gangrene.berkeley.edu>,
|
|
Rob Robertson <rob@agate.berkeley.edu> wrote:
|
|
|
|
:I don't think this would work, as so many words in usenet postings are
|
|
:misspelled that looking them up in a dictionary, probably won't buy
|
|
:you anything, cuz they won't be found!
|
|
|
|
An interesting fact is that people tend to quote other articles in their
|
|
own postings. When I was hacking TMNN I set up a feed which threaded the
|
|
articles to be sent on References: headers, and created the compressed
|
|
UUCP batches in order rather than the date order in which I received
|
|
them.
|
|
|
|
Now the reason for all of this was that I was feeding out over a 2400
|
|
baud modem. By sorting I was able to get up to 30% reduction in the
|
|
size of the compressed batch. I have no reason to expect less than 20% for
|
|
text articles (but not binaries).
|
|
|
|
The short answer is "yes, compression works, compression with ordering
|
|
works really well."
|
|
--
|
|
Bill Davidsen, davidsen@tmr.com on weekends.
|
|
"Speaking *from* but not *for* Prodigy"
|
|
|
|
------------------------------
|
|
|
|
From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
|
|
Subject: Re: Alpha Linux
|
|
Date: 8 Sep 1994 13:31:11 GMT
|
|
|
|
In article <34i2gj$9va@news.tuwien.ac.at>, hp@vmars.tuwien.ac.at (Peter Holzer) writes:
|
|
|> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
|
|
|>
|
|
|> >In article <AMBRISKO.94Aug26104834@tasha.kpc.com>, ambrisko@kpc.com (Douglas Ambrisko) writes:
|
|
|> >|> The biggest task with the
|
|
|> >|> Alpha is making everything 64 bit clean and this will apply to the EISA
|
|
|> >|> drivers.
|
|
|>
|
|
|> >Only if Linux on the Alpha will be a 64-bit-OS.
|
|
|>
|
|
|> I sure hope it will be. Who wants a 32 bit OS on an Alpha?
|
|
|
|
The VMS guys. And I prefer a true 32-bit OS to a half-hearted 64-bit
|
|
OS, where one of the main data types of the main language is 32 bits:
|
|
Mark my words: As soon as people will be using really more tha 4G in
|
|
one app, they will complain about 32-bit ints as they do about 8086
|
|
segments now.
|
|
|
|
|> >If it will be, I hope
|
|
|> >that they do not repeat the OSF/1 idiocy of having only 32-bit ints.
|
|
|>
|
|
|> Then you have to drop either the 16 bit or the 32 bit int type.
|
|
|
|
No. Just add an int32_t.
|
|
|
|
|> Both
|
|
|> options may make some people unhappy. The 32 bit int is a reasonable
|
|
|> compromise. It also breaks all those programs which assume that a
|
|
|> pointer and an int are just the same thing, which is a good thing IMHO.
|
|
|
|
Why is this a good thing? And is it also a good thing that programs
|
|
break that assume that an index into an array or the difference
|
|
between to pointers fits into an int?
|
|
|
|
And if you say, that such things can be easily fixed by greping for
|
|
"int" and replacing it with "TrueInt", you are wrong. In C int is not
|
|
just another type, it affects many things in the language: Normal
|
|
integer constants have the int type, int plays a special role in
|
|
conversion rules, switch wants an int argument, etc.
|
|
|
|
I have debugged enough programs (one:-) that worked perfectly well on
|
|
decent OSs on an Atari ST to know why I dislike
|
|
sizeof(int)!=sizeof(void *). Just writing "3" instead of "3L" cost at
|
|
least 5 hours of debugging time of two people (one of them an
|
|
experienced Atari user).
|
|
|
|
- anton
|
|
--
|
|
M. Anton Ertl Some things have to be seen to be believed
|
|
anton@mips.complang.tuwien.ac.at Most things have to be believed to be seen
|
|
|
|
------------------------------
|
|
|
|
From: jw@peanuts.informatik.uni-tuebingen.de (Joerg Wedeck)
|
|
Subject: Re: Serial port problems
|
|
Date: 7 Sep 1994 19:42:38 GMT
|
|
|
|
Rob Janssen (rob@pe1chl.ampr.org) wrote:
|
|
: In <34h945$q20@wsiserv.informatik.uni-tuebingen.de> jw@peanuts.informatik.uni-tuebingen.de (Joerg Wedeck) writes:
|
|
|
|
: >as the subject says i am having problems with the serial port with
|
|
: >ALL linux kernels, when switching to speeds higher than 19200 baud.
|
|
: >from 38400 baud on onward i have to experience data losses.
|
|
|
|
: >the manual says there are 2 NS16C552 compatible UARTs which support
|
|
: >FIFO. Are these UARTs incompatible to the serial driver provided by
|
|
: >linux ?
|
|
|
|
: I use a card with three of these, and one of my ports runs at 76800 bps
|
|
: to my modem. flowcontrol works perfectly.
|
|
|
|
ok, I further investigated the problem. running kermit or minicom outside
|
|
X really runs fine at rates >= 38400 baud. But running from X windows
|
|
results in data loss (linux 1.0.9 and 1.1 until pl 49). any ideas ?
|
|
|
|
Joerg
|
|
|
|
--
|
|
==================================+======================================
|
|
Joerg Wedeck | E-Mail: jw@peanuts.informatik\
|
|
Universitaet Tuebingen | .uni-tuebingen.de
|
|
Lehrstuhl fuer Techn. Informatik |
|
|
Sand 13 |
|
|
72076 Tuebingen |
|
|
Germany |
|
|
==================================+======================================
|
|
Deswegen bin ich ja Optio, und Du nur Legionaer :-)
|
|
=========================================================================
|
|
Public Key for using PGP:
|
|
|
|
begin 600 public-key-jw.pgp
|
|
MF0"- BRF^P$ $$ ,B)]\0]PPT'=HNADPO:L=IN4Q V-SR?[<62 ) >(_2)
|
|
MS^/K\$5#86$M_%&[Q\"P&$#P.TQ$1#9,;HP$GN\(J?4XB$/_FZY+P'PPOJ<U
|
|
MB5;<6@E8&R\F;O4%\PT9"FDM/?K]_J5!^$TI7](^1H#2ZBWF,(! D),>3KZ-
|
|
M_.>$H'*Y 41M#5*;V5R9R!7961E8VL@/&IW0'!E86YU=',N:6YF;W)M871I
|
|
M:RYU;FDM='5E8FEN9V5N+F1E/HD E0(%$"RF_*J^C?SGA*!RN0$!0Z<#_V;A
|
|
MO6M'^$@7L:EH"U:A40S8E6F7%< ?W!;])UZNLB P/75"IX]&?MM*U-3K:!?T
|
|
M<7-N,$3'* 27=-LNF9O)O:@ZIKO0M3 @2:S]>WZ/ \"&%BTJQ!4M\;8B>'AS
|
|
DM)>*)YOG@SN_$#K^QGPK/0!EHG93=FBR JY(,AZVN:B TT44
|
|
|
|
end
|
|
========================================================================+
|
|
|
|
|
|
------------------------------
|
|
|
|
Crossposted-To: comp.lang.fortran
|
|
From: martien@dutw85.wbmt.tudelft.nl (Martien Hulsen)
|
|
Subject: Re: Survey: who wants f77,cc,c++,hpf for linux?
|
|
Date: Thu, 8 Sep 1994 13:34:02 GMT
|
|
|
|
Michel Anders (michela@sci.kun.nl) wrote:
|
|
|
|
> >4. Is there interest in accompanying GUI/non-GUI debuggers and
|
|
> > performance analysis tools?
|
|
|
|
> again, GDB satisfies my needs quite nicely (programming wise :-))
|
|
|
|
Not for f2c though :-(. Hope that g77 will resolve this.
|
|
|
|
Martien
|
|
|
|
------------------------------
|
|
|
|
From: iialan@iifeak.swan.ac.uk (Alan Cox)
|
|
Subject: Re: Multiprocessing Pentium Systems
|
|
Date: Thu, 8 Sep 1994 14:27:49 GMT
|
|
|
|
In article <CvszIu.BJ@ndl.co.uk> rad@ndl.co.uk (Rich Deighton) writes:
|
|
>It has to be said that Linux is a very good OS, but there is little need to
|
|
>flame something just because it comes from Microsoft. Be open minded about
|
|
>such things :-)
|
|
|
|
I think the phrase is 'Bits of NT are pretty neat'. I certainly reckon you
|
|
could run Linux as an NT subsystem instead of the psuedo posix bit.
|
|
|
|
Alan
|
|
|
|
|
|
--
|
|
..-----------,,----------------------------,,----------------------------,,
|
|
// Alan Cox // iialan@www.linux.org.uk // GW4PTS@GB7SWN.#45.GBR.EU //
|
|
``----------'`----------------------------'`----------------------------''
|
|
|
|
------------------------------
|
|
|
|
From: sar@bee.beehive.mn.org (Steven A. Reisman)
|
|
Subject: Re: Alpha Linux
|
|
Date: Thu, 8 Sep 1994 00:49:24 GMT
|
|
|
|
Albert D. Cahalan (adc@bach.coe.neu.edu) wrote:
|
|
|
|
: Why drop one?
|
|
: 16 bits = short int
|
|
: 32 bits = int
|
|
: 64 bits = long
|
|
|
|
128 bits = long long :)
|
|
|
|
--
|
|
Steven A. Reisman
|
|
12695 4th St. S. sar@beehive.mn.org
|
|
Afton, MN 55001 (612) 436-7125
|
|
|
|
------------------------------
|
|
|
|
From: iialan@iifeak.swan.ac.uk (Alan Cox)
|
|
Subject: Re: A thought to improve security
|
|
Date: Thu, 8 Sep 1994 11:20:23 GMT
|
|
|
|
In article <34jvth$ovl@nic.wi.leidenuniv.nl> jvdmost@hupnos.wi.leidenuniv.nl (J.A.vanderMost) writes:
|
|
>Some programs in a Unix system have to be SUID root to do the things they do.
|
|
>Like /bin/passwd /bin/login /usr/bin/lp /user/bin/at etc.. are all SUID root.
|
|
|
|
You can implement a non suid lpr set with thought, and a non setuid root one
|
|
quite easily.
|
|
|
|
>But being root is MUCH to powerful for these programs, they don't need all
|
|
>the abilities of root, only a very small portion of it. And that's exactly
|
|
|
|
passwd/login are bad examples. They need to be/can be root because after all
|
|
if you can break them you can probably break the whole system anyway.
|
|
|
|
>Let's say lpr has a security bug in it, it allows a normal user that knows
|
|
>witch options, etc. to use, to modify a file that this user couldn't normally
|
|
>modify. This is a very harmful bug, because this user can easily become root!
|
|
|
|
With some older lpr's you could 8)
|
|
|
|
>Let's modify the kernel a bit, and redefine the meaning of the UIDs below 256:
|
|
>UID 0 is root ( like it always was, many programs depend on this )
|
|
>UID >256 are normal users, without a special meaning.
|
|
>UID 1-255 are not what they used to be, they have a special meaning :
|
|
|
|
It now doesn't work anything like proper Unix. The problem isn't one of
|
|
kernel facilities its more one of sloppy code. To fix it properly requires
|
|
a lot of thought and care whatever system you choose to use. I've run one
|
|
Unix machine with no user accessible setuid binaries. Indeed all the user
|
|
visible filestore was nosuid. A small true root partition with the user
|
|
space chroot()ed under it held the only setuid binaries. All these talked
|
|
via named pipes and an encyrption key system to/from the user clients
|
|
with agreed minimalist protocol options including the fact that all files
|
|
were passed down the pipe and never opened by the priviledged server.
|
|
|
|
It's a case of discipline and planning not quick hacks.
|
|
|
|
Alan
|
|
|
|
--
|
|
..-----------,,----------------------------,,----------------------------,,
|
|
// Alan Cox // iialan@www.linux.org.uk // GW4PTS@GB7SWN.#45.GBR.EU //
|
|
``----------'`----------------------------'`----------------------------''
|
|
|
|
------------------------------
|
|
|
|
From: rene@inf.utfsm.cl (Rene Angel Sepulveda)
|
|
Subject: Re: Threads for Linux
|
|
Date: 7 Sep 1994 18:20:18 -0400
|
|
|
|
Nicolas Droux (droux@info.isbiel.ch) wrote:
|
|
: Hi there,
|
|
|
|
Hi
|
|
|
|
: I need to be able to create threads, or lightweight processes, under
|
|
: Linux. Is there a good solution to this problem ? Is this feature
|
|
: integrated in a recent release of the kernel, is it planned, or is it
|
|
: possible to do this by means of a 3rd party package ?
|
|
|
|
You can use the pthread library.
|
|
|
|
this library is port to Linux-1.0
|
|
|
|
it's the FAQ
|
|
|
|
============= cut here ================
|
|
|
|
Answers to frequently asked questions
|
|
for my implementation of POSIX threads
|
|
|
|
Question: What are pthreads?
|
|
Answer: Pthreads stands for POSIX threads. Currently their is NO
|
|
POSIX thread standard, just drafts. The last draft circulated
|
|
was draft 8, in October 1993. I expect that it won't be
|
|
approved and another draft will be circulated soon.
|
|
|
|
Question: I've read somewhere that the calling arguments for the
|
|
pthread function FOO() was BAR but your implemnentation
|
|
is BAZ. Which is right?
|
|
Answer: If I've implemented the function foo() then my implementation
|
|
is probably correct according to the current draft of pthreads.
|
|
I've tried to keep my implementation as up to date as possible.
|
|
The discrepency you are seeing is probably because you've
|
|
seen the OSF/DCE implementation of threads which was based
|
|
on draft 4 of the POSIX thread standard, and there has been
|
|
significant changes to the interfaces since then.
|
|
There is one discrepency to this see below.
|
|
|
|
Question: What about pthread_detach()
|
|
Answer: The latest draft has completely removed this function from the
|
|
standard. I've considered this very a rather bad move on their
|
|
part and have kept pthread_detach(). It is based on the last
|
|
draft to contain the pthread_detach() function (draft 7).
|
|
|
|
Question: Where do I get the latest draft of pthreads?
|
|
Answer: You can try IEEE which is the organization which POSIX belongs.
|
|
I have found them to be completely unhelpful for my needs and
|
|
have had to go out and beg for my own copy. Usually they
|
|
release the previous draft just in time for the next draft to
|
|
go up for balloting.
|
|
|
|
Question: Where can I get this implementation?
|
|
Answer: You can try sipb.mit.edu:/pub/pthreads or
|
|
toxicwaste:/pub/archive/pthreads
|
|
|
|
Question: Where can I get documentation?
|
|
Answer: I haven't written man pages yet, and I only have some of the
|
|
functions available online. You can find them under my home page.
|
|
HTTP://www.mit.edu:8001/people/proven/home_page.html
|
|
|
|
========================== cut here =====================================
|
|
|
|
regards,
|
|
--
|
|
Rene Angel Sepulveda e-mail: rene@inf.utfsm.cl
|
|
Ing. Civil Informatica http://www.inf.utfsm.cl/~rene/
|
|
UTFSM, Valpariso. CHILE "Que vana es la gracia y falsa la belleza" (hamlet)
|
|
|
|
------------------------------
|
|
|
|
From: tabaer@magnus.acs.ohio-state.edu (Highlander)
|
|
Crossposted-To: comp.lang.fortran
|
|
Subject: Re: Survey: who wants f77,cc,c++,hpf for linux?
|
|
Date: 8 Sep 1994 11:49:43 GMT
|
|
|
|
In article <34m769$bju@indy.pgroup.com>, Larry Meadows <lfm@pgroup.com> wrote:
|
|
>Hello
|
|
>
|
|
>Given the interest in Linux, I thought I'd post a short survey:
|
|
>
|
|
>1. Are people interested in a commercial compiler suite for Linux on
|
|
> Intel Architecture platforms? The suite would include true compilers
|
|
> for extended Fortran 77, ANSI C, Draft-ANSI C++ with extensions, and
|
|
> High Performance Fortran. C, f77, and C++ could support shared memory
|
|
> parallelism (thread-based) if system support is available in Linux.
|
|
> HPF would support socket-based communications on networked systems,
|
|
> and could support custom interconnects.
|
|
|
|
F77 and HPF would be nice. ANSI C and draft-ANSI C++ are kind of pointless
|
|
unless you really want to try competing with gcc/g++, since in theory anybody
|
|
who wanted to could add thread-based parallelism to them. Yeah, it'd be
|
|
a pain in the butt to do
|
|
|
|
>2. How much would people pay for such a product [ loaded question ]?
|
|
|
|
Speaking only for myself, I'd pay for a compiler. Iff the price isn't
|
|
ridiculous. I'm not going to pay thousands of dollars for a FORTRAN
|
|
compiler when I can use f2c and gcc for free with source code, but I would
|
|
be willing to pay on the order of a couple hundred dollars for a parallelizing
|
|
FORTRAN compiler that's (for instance) PVM-aware. I'd say $500 max, but then
|
|
I'm a poor college student and I've been kicking around the idea of writing
|
|
my own compiler (although not terribly seriously).
|
|
|
|
>3. What distribution media would be required?
|
|
|
|
Probably floppy and/or ftp. Not too many Linux users I know have tape
|
|
drives. CD-ROM might be doable as well (and would give me an excuse to
|
|
finally buy a CD-ROM drive for something other than games).
|
|
|
|
>4. Is there interest in accompanying GUI/non-GUI debuggers and
|
|
> performance analysis tools?
|
|
|
|
Definitely, if they actually work. Trying to figure out gdb is a pain,
|
|
especially since it's not FORTRAN-aware yet. I've taken to using Ups,
|
|
but it has its own set of problems.
|
|
|
|
I guess a larger question is, how many people are doing serious numerical
|
|
work with FORTRAN on Linux? I've done some, but it's difficult for two
|
|
reasons: 1.) no native FORTRAN compiler, and 2.) i[345]86 floating point
|
|
performance sucks big fuzzy Volkswagens through a straw. Anybody tried
|
|
running something really perverse like the NAS Parallel Benchmarks on a
|
|
Linux box? (11 seconds on a Cray Y-MP, 22 hours on a VAX 785 :)
|
|
|
|
Just my $0.02
|
|
|
|
--Troy
|
|
+--------------------+------------------------------------------------+
|
|
| Troy A. Baer | "My soul is painted like wings of butterflies, |
|
|
| Senior, Aero. Engr.| Fairy tales of yesterday, grow but never die, |
|
|
| DOS?!? Try Linux!! | I can fly, my friends!" --Brian May |
|
|
+--------------------+------------------------------------------------+
|
|
|
|
|
|
|
|
------------------------------
|
|
|
|
Crossposted-To: comp.lang.fortran
|
|
From: michela@sci.kun.nl (Michel Anders)
|
|
Subject: Re: Survey: who wants f77,cc,c++,hpf for linux?
|
|
Date: Thu, 8 Sep 1994 11:28:47 GMT
|
|
|
|
In <34m769$bju@indy.pgroup.com> lfm@pgroup.com (Larry Meadows) writes:
|
|
|
|
>Hello
|
|
|
|
>Given the interest in Linux, I thought I'd post a short survey:
|
|
|
|
>1. Are people interested in a commercial compiler suite for Linux on
|
|
> Intel Architecture platforms? The suite would include true compilers
|
|
> for extended Fortran 77, ANSI C, Draft-ANSI C++ with extensions, and
|
|
> High Performance Fortran. C, f77, and C++ could support shared memory
|
|
> parallelism (thread-based) if system support is available in Linux.
|
|
> HPF would support socket-based communications on networked systems,
|
|
> and could support custom interconnects.
|
|
|
|
GCC/G++ (and f2c) are excellent compilers and free..., and since i'm not
|
|
writing any *commercial* software these suffice.
|
|
|
|
>4. Is there interest in accompanying GUI/non-GUI debuggers and
|
|
> performance analysis tools?
|
|
|
|
again, GDB satisfies my needs quite nicely (programming wise :-))
|
|
|
|
For non-commercial programmers like me, i fail to see how a commercial
|
|
compiler could surpass the available GNU software. It would be interesting
|
|
to see, though, how many commercial developers are interested in the Linux
|
|
platform and what kind of products the consider to offer.
|
|
|
|
Michel.
|
|
|
|
/*-------------------------------------------------------------------------*/
|
|
/* Michel J. Anders Dept. Experimental Solid State Physics 3 */
|
|
/* michela@sci.kun.nl University of Nijmegen */
|
|
/* +31 80 653434 Toernooiveld 1, Nijmegen */
|
|
/*-------------------------------------------------------------------------*/
|
|
|
|
------------------------------
|
|
|
|
|
|
** 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: Linux-Development-Request@NEWS-DIGESTS.MIT.EDU
|
|
|
|
You can send mail to the entire list (and comp.os.linux.development) via:
|
|
|
|
Internet: Linux-Development@NEWS-DIGESTS.MIT.EDU
|
|
|
|
Linux may be obtained via one of these FTP sites:
|
|
nic.funet.fi pub/OS/Linux
|
|
tsx-11.mit.edu pub/linux
|
|
sunsite.unc.edu pub/Linux
|
|
|
|
End of Linux-Development Digest
|
|
******************************
|