Messages in this thread |  | | From | pemso@luxor ... | Date | Wed, 21 Aug 1996 08:39:20 +1000 | Subject | Re: linux-kernel-digest V1 #456 |
| |
>linux-kernel-digest Tuesday, 20 August 1996 Volume 01 : Number 456 > >In this issue: > > Re: Linux support denial in commercial products? > Re: Sprintlink probs? > Re: 64bit lseek (Was: Re: >31 bit filesystems) > Re: interrupt counts > Re: Remove me from this list - Please (fwd) > Re: Remove me from this list - Please (fwd)s.edu > >See the end of the digest for information on subscribing to the linux-kernel >or linux-kernel-digest mailing lists. > >---------------------------------------------------------------------- > >From: Matthias Urlichs <smurf@smurf.noris.de> >Date: Tue, 20 Aug 1996 13:22:16 +0100 >Subject: Re: Linux support denial in commercial products? > >In linux.dev.kernel, article <ueg25iwfva.fsf@rama.esegi.es>, > jsanchez@esegi.es writes: >> >> This smells of Motif. That guy does not know what he's talking about, >> but I think what he has somewhere overhead is that Linux does not have >> the Motif libraries. You just happened to hear a poor translation. >> >Besides, it's wrong too. Motif costs money. You can't even ship a program >(or, worse, a set of programs) with dynamically-linked Motif libraries, >even though nobody is hurt by this, other than the RAM manufactures. :-( > >- -- >I'm always looking for meaningful one-night stands. > -- Dudley Moore >- -- >Matthias Urlichs \ noris network GmbH / Xlink-POP N¸rnberg >Schleiermacherstraþe 12 \ Linux+Internet / EMail: urlichs@noris.de >90491 N¸rnberg (Germany) \ Consulting+Programming+Networking+etc'ing > PGP: 1024/4F578875 1B 89 E2 1C 43 EA 80 44 15 D2 29 CF C6 C7 E0 DE > Click <A HREF="http://info.noris.de/~smurf/finger">here</A>. 42 > >------------------------------ > >From: Matti E Aarnio <mea@mea.utu.fi> >Date: Tue, 20 Aug 1996 14:48:59 +0300 (EET DST) >Subject: Re: Sprintlink probs? > >> Has anyone besides myself had the following problem? It's been like >> this for nearly a week now... > > [ I doubt this reply reaches straight from Finland to the > person(s) asking, but VGER can talk to them. Therefore > please do bear with me this off-topic reply ... ] > > Just now testing it -- yes, you are not reachable from > ftp.funet.fi either. Actually the route stops at the > first router with global routeing database. > > I suggest you talk with your service provider, as to why your > network is not known to the network at large, specifically why > you can't reach FUNET networks that are with AS number 1741. > (modern routeing works with Autonomous Systems numbers, not so > much with IP-nets anymore. ASes can contain many nets, but > each net must belong to at most one AS. If a net does not > belong to any, BGP4 speaking core routers will not know it.) > > Trace goes a bit further for your service provider, but stops > right after exiting the trans-atlantic icp.net system. > > Problems are propably around MAE-East. > > (Be them technical, or political/agreenmental, I don't know..) > >> -NL > > /Matti Aarnio <mea@utu.fi> <mea@ftp.funet.fi> > >> --------- >> Script started on Tue Aug 20 05:04:51 1996 >> nixnet:~# >> nixnet:~# ping ftp.funet.fi -c 5 >> PING ftp.funet.fi (128.214.248.6): 56 data bytes >> >> --- ftp.funet.fi ping statistics --- >> 5 packets transmitted, 0 packets received, 100% packet loss >> nixnet:~# >> nixnet:~# traceroute ftp.funet.fi >> traceroute to ftp.funet.fi (128.214.248.6), 30 hops max, 40 byte packets >> 1 INDIANA.NET (205.243.46.33) 223.652 ms 242.999 ms 218.592 ms >> 2 * peter.qrp.com (205.243.46.1) 230.05 ms 231.669 ms >> 3 huf-qrp.cioe.net (206.160.234.245) 246.576 ms 249.026 ms 239.468 ms >> 4 huf-rt2.cioe.com (206.160.234.35) 249.338 ms 249.024 ms 249.551 ms >> 5 sl-chi-13-S3/1-T1.sprintlink.net (144.228.153.105) 249.465 ms >>249.293 ms 249.336 ms >> 6 sl-chi-3-F0/0.sprintlink.net (144.228.50.3) 249.274 ms 248.773 ms >>259.435 ms >> 7 sl-pen-2-H2/0-T3.sprintlink.net (144.228.10.37) 279.501 ms 278.818 >>ms 289.532 ms >> 8 * * * >> 9 * * * >> 10 * * * >> 11 * * * >> 12 * * * >> 13 * * * >> 14 * * * >> 15 * * * >> 16 * * * >> 17 * * * >> 18 * * * >> 19 * * * >> 20 * * * >> 21 * * * >> 22 * * * >> 23 * * * >> 24 * * * >> 25 * * * >> 26 * * * >> 27 * * * >> 28 * * * >> 29 * * * >> 30 * * * >> nixnet:~# >> nixnet:~# exit >> exit >> >> Script done on Tue Aug 20 05:15:51 1996 >> > > >------------------------------ > >From: "Stephen C. Tweedie" <sct@dcs.ed.ac.uk> >Date: Tue, 20 Aug 1996 10:49:23 +0100 >Subject: Re: 64bit lseek (Was: Re: >31 bit filesystems) > >Hi, > >On Sun, 18 Aug 96 12:21 EDT, ssd@nevets.oau.org (Steven S. Dick) said: > >> Just to note.... > >> Solaris 2 implmements llseek() which takes a long long. >> However (as noted in the sun man page), llseek() currently only works for >> addresses >32b on devices. In fact, it doesn't even work on buffered disk >> devices. It has to be a raw disk device. > >> I suppose eventually this restriction will go away. > >> I assume linux 64 bit file support will use llseek too? > >No. It will have the compile-time option of either a 64-bit clean >lseek() with a large off_t type, or the normal situation of a 32-bit >lseek augmented by a 64-bit lseek64(). However, linux _already_ has >llseek() (supported, just as for Solaris, for device files only), so >we'll probably keep that around for compatibility's sake. > >Cheers, > Stephen. >- -- >Stephen Tweedie <sct@dcs.ed.ac.uk> >Department of Computer Science, Edinburgh University, Scotland. > > >------------------------------ > >From: "Stephen C. Tweedie" <sct@dcs.ed.ac.uk> >Date: Tue, 20 Aug 1996 11:19:39 +0100 >Subject: Re: interrupt counts > >Hi, > >On Mon, 19 Aug 1996 12:11:12 +0300 (EET DST), Matti E Aarnio ><mea@mea.cc.utu.fi> said: > >>> I dont know how much handling 64bit instead of 32 bit decereases >>> performance, but this is definately an option. > >> If you look deep down, at 32-bit machines it will take >> twice as much work as native size counter handling does. >> At Alphas I would use 64-bit longs anyway :-) > >It's not nearly that bad. The biggest bottleneck is probably memory >speed, not CPU cycles, and we do all memory transfers in units of >cache lines already, not words. We'll still just be doing a >read-modify-write of a single cache line whether the update is for a >single 32-bit word or a 64-bit doubleword. This is assuming you have >got a write-back cache, of course; a 486 with write-through cache will >be a full memory write worse off for the 64-bit counter update. > >Cheers, > Stephen. >- -- >Stephen Tweedie <sct@dcs.ed.ac.uk> >Department of Computer Science, Edinburgh University, Scotland. > > >------------------------------ > >From: tyoung <tyoung@netaxis.com> >Date: Tue, 20 Aug 1996 07:39:41 -0400 (EDT) >Subject: Re: Remove me from this list - Please (fwd) > >Thanks Mick. I thought this was all my mistake. > >- ---------- Forwarded message ---------- >Date: Tue, 20 Aug 1996 07:36:54 -0400 (EDT) >From: tyoung <tyoung@netaxis.com> >To: Majordomo@vger.rutgers.edu >Subject: Re: Remove me from this list - Please > >unsubscribe linux-kernel tyoung@netaxis > > >unsubscribe linux-kernel tyoung@netaxis > > >I have been trying to unsubsribe here for weeks. If this doesn't >work, I'll have to configure my mail reader to reject >linux kernel mail. > >On Mon, 19 Aug 1996, Mick Ghazey wrote: > >> I've tried several times to send a message to Majordomo according to the >> following instructions I saved when I joined. No luck. Please help. >> >> > If you ever want to remove yourself from this mailing list, >> > you can send mail to <Majordomo@vger.rutgers.edu> with the following >> > command in the body of your email message: >> >> > unsubscribe linux-kernel mghazey@cybernex.net >> >> >> > > >------------------------------ > >From: Matti E Aarnio <mea@mea.utu.fi> >Date: Tue, 20 Aug 1996 15:49:15 +0300 (EET DST) >Subject: Re: Remove me from this list - Please (fwd)s.edu > >> Thanks Mick. I thought this was all my mistake. > > To the first person I replied privately, but as this > appears to be a wider misunderstanding... > >> ---------- Forwarded message ---------- >> Date: Tue, 20 Aug 1996 07:36:54 -0400 (EDT) >> From: tyoung <tyoung@netaxis.com> >> To: Majordomo@vger.rutgers.edu >> Subject: Re: Remove me from this list - Please >> >> unsubscribe linux-kernel tyoung@netaxis >> >> I have been trying to unsubsribe here for weeks. If this doesn't >> work, I'll have to configure my mail reader to reject >> linux kernel mail. > > Please use your fully qualified address! > Address "tyoung@netaxis" does not match with (the real) > address "tyoung@netaxis.com" (which was at the list), > therefore the command does not have any effect. > I deleted this recipient manually anyway.) > > Also the first person asking for help... > >> On Mon, 19 Aug 1996, Mick Ghazey wrote: >> >> > I've tried several times to send a message to Majordomo according to the >> > following instructions I saved when I joined. No luck. Please help. >> > >> > > If you ever want to remove yourself from this mailing list, >> > > you can send mail to <Majordomo@vger.rutgers.edu> with the following >> > > command in the body of your email message: >> > >> > > unsubscribe linux-kernel mghazey@cybernex.net > > ... is not subscribed to linux-kernel at all, but can be > found from linux-net. > > It is no wonder that unsubscribe from linux-kernel is > unsuccessfull. I did not remove him, because the list > didn't match. > >/Matti Aarnio <mea@utu.fi> -- just monitoring the mailer at VGER. > >------------------------------ > >End of linux-kernel-digest V1 #456 >********************************** > >To subscribe to linux-kernel-digest, send the command: > > subscribe linux-kernel-digest > >in the body of a message to "Majordomo@Majordomo.vger.rutgers.edu". If >you want >to subscribe something other than the account the mail is coming from, >such as a local redistribution list, then append that address to the >"subscribe" command; for example, to subscribe "local-linux-kernel": > > subscribe linux-kernel-digest local-linux-kernel@your.domain.net > >A non-digest (direct mail) version of this list is also available; to >subscribe to that instead, replace all instances of "linux-kernel-digest" >in the commands above with "linux-kernel".
dear whoever, these messages keep getting sent to our address. please stop sending them. yours truly, Joseph
Lesley Humphries PEMSO c/- La Trobe University Union Bundoora Victoria Australia 3083 Phone 03 9479 2057 E-mail pemso@luxor.latrobe.edu.au
|  |