Re: linux-kernel-digest V1 #456

pemso@luxor.latrobe.edu.au
Wed, 21 Aug 1996 08:39:20 +1000

Messages sorted by: [ date ][ thread ][ subject ][ author ]
Next message: James L. McGill: "Re: Linux support denial in commercial products?"
Previous message: Stig: "Re: AWE32 Programming Info (Official) Released!!!!"

>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

Next message: James L. McGill: "Re: Linux support denial in commercial products?"
Previous message: Stig: "Re: AWE32 Programming Info (Official) Released!!!!"