Hello, we're trying to do something a little odd in NFS that I
don't believe is currently possible. However, I have seen in the mail
archives that Neil Brown discussed this back in 7-4-2001.
The problem is this:
We have a huge RAID system that houses, among other things, many
ISO image files.
The quality assurance people would like to have a "virtual
jukebox" that is distributed via NFS to our large array of test machines.
This jukebox would contain the mounted ISO images.
However, currently there is no way to have a single parent
directory distributed over NFS that will propogate its mounted contents.
One must currently define an explicit mount point in /etc/exports (eg:
/Jukebox/M-LINUX-L/6.0.0/187885). Additionally, the client must know the
explicit mount point to properly mount this shared image.
This is a problem when you want to have several hundred (well, no
more than 255 theoretically because of the 8-bit 'minor' device issue with
loop devices) ISO images that you'd like to distribute, because you then
are responsible for maintaining EVERY explicit mount point for each image,
both on the server and each client.
Even more frustrating is the fact that this is going to be an
automated dynamic process. That is - as ISO images are automatically built
by other systems, we'll want to mount and export their contents
automatically. Likewise, we'll need to prune existing ISO images and their
respective mounts.
And, there is no way for the client-side to "know" each mount
point in an automated fashion. That is - if the ISO builder system
generates a new ISO image, mounts it, and distributes it, there is now a
unique mount point that the client can't programatically determine.
So - why the heck am I bothering NFS people with this?
Because I am wondering if there is a way to simply have ONE mount
point exported and mounted on the client side, and have it recursively
inherit each of the mounted image directories within it.
Also - for those who are asking, "Hey dummy - why don't you just
mount the images on the NFS server, then copy their contents into /Jukebox
in the appropriate directory?!". Well, because our quality assurance
people would like to work with the EXACT files that are going to get
burned to CD if the build is a success. Copying the files introduces an
extra step that makes them nervous. Plus - every ISO image whose contents
we must actually COPY means another 600+ megs we have to allocate disk to.
Thoughts, anyone?
If all you can say is, "That's impossible" or "You're a moron" -
your reply will find its way into /dev/null. :-)
Dave
--
Dave Ingram
Tools and Automation Engineer
Wolfram Research
217-398-0700 x776
-------------------------------------------------------
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Wed, 2002-10-23 at 15:51, Dave Ingram wrote:
>
> Hello, we're trying to do something a little odd in NFS that I
> don't believe is currently possible. However, I have seen in the mail
> archives that Neil Brown discussed this back in 7-4-2001.
>
> The problem is this:
>
> We have a huge RAID system that houses, among other things, many
> ISO image files.
>
> The quality assurance people would like to have a "virtual
> jukebox" that is distributed via NFS to our large array of test machines.
> This jukebox would contain the mounted ISO images.
>
> However, currently there is no way to have a single parent
> directory distributed over NFS that will propogate its mounted contents.
> One must currently define an explicit mount point in /etc/exports (eg:
> /Jukebox/M-LINUX-L/6.0.0/187885). Additionally, the client must know the
> explicit mount point to properly mount this shared image.
>
> This is a problem when you want to have several hundred (well, no
> more than 255 theoretically because of the 8-bit 'minor' device issue with
> loop devices) ISO images that you'd like to distribute, because you then
> are responsible for maintaining EVERY explicit mount point for each image,
> both on the server and each client.
>
> Even more frustrating is the fact that this is going to be an
> automated dynamic process. That is - as ISO images are automatically built
> by other systems, we'll want to mount and export their contents
> automatically. Likewise, we'll need to prune existing ISO images and their
> respective mounts.
>
> And, there is no way for the client-side to "know" each mount
> point in an automated fashion. That is - if the ISO builder system
> generates a new ISO image, mounts it, and distributes it, there is now a
> unique mount point that the client can't programatically determine.
>
> So - why the heck am I bothering NFS people with this?
>
> Because I am wondering if there is a way to simply have ONE mount
> point exported and mounted on the client side, and have it recursively
> inherit each of the mounted image directories within it.
>
> Also - for those who are asking, "Hey dummy - why don't you just
> mount the images on the NFS server, then copy their contents into /Jukebox
> in the appropriate directory?!". Well, because our quality assurance
> people would like to work with the EXACT files that are going to get
> burned to CD if the build is a success. Copying the files introduces an
> extra step that makes them nervous. Plus - every ISO image whose contents
> we must actually COPY means another 600+ megs we have to allocate disk to.
>
> Thoughts, anyone?
>
> If all you can say is, "That's impossible" or "You're a moron" -
> your reply will find its way into /dev/null. :-)
>
You might be able to work some dark magic with autofs over the nfs
exported locations.
look into how autofs functions - I think it might just be possible if
you're not afraid of some painful thinking.
-sv
The April Linux Journal had an article on building a virtual CD-ROM
jukebox, and is available here. It sounds a bit like what you are
looking for. It's available here:
http://www.linuxjournal.com/article.php?sid=5639
I don't recall whether it addresses the issues you bring up, but it
might.
dbr
On Wed, 2002-10-23 at 15:51, Dave Ingram wrote:
> Hello, we're trying to do something a little odd in NFS that I
> don't believe is currently possible. However, I have seen in the mail
> archives that Neil Brown discussed this back in 7-4-2001.
>
> The problem is this:
>
> We have a huge RAID system that houses, among other things, many
> ISO image files.
>
> The quality assurance people would like to have a "virtual
> jukebox" that is distributed via NFS to our large array of test machines.
> This jukebox would contain the mounted ISO images.
>
> However, currently there is no way to have a single parent
> directory distributed over NFS that will propogate its mounted contents.
> One must currently define an explicit mount point in /etc/exports (eg:
> /Jukebox/M-LINUX-L/6.0.0/187885). Additionally, the client must know the
> explicit mount point to properly mount this shared image.
>
> This is a problem when you want to have several hundred (well, no
> more than 255 theoretically because of the 8-bit 'minor' device issue with
> loop devices) ISO images that you'd like to distribute, because you then
> are responsible for maintaining EVERY explicit mount point for each image,
> both on the server and each client.
>
> Even more frustrating is the fact that this is going to be an
> automated dynamic process. That is - as ISO images are automatically built
> by other systems, we'll want to mount and export their contents
> automatically. Likewise, we'll need to prune existing ISO images and their
> respective mounts.
>
> And, there is no way for the client-side to "know" each mount
> point in an automated fashion. That is - if the ISO builder system
> generates a new ISO image, mounts it, and distributes it, there is now a
> unique mount point that the client can't programatically determine.
>
> So - why the heck am I bothering NFS people with this?
>
> Because I am wondering if there is a way to simply have ONE mount
> point exported and mounted on the client side, and have it recursively
> inherit each of the mounted image directories within it.
>
> Also - for those who are asking, "Hey dummy - why don't you just
> mount the images on the NFS server, then copy their contents into /Jukebox
> in the appropriate directory?!". Well, because our quality assurance
> people would like to work with the EXACT files that are going to get
> burned to CD if the build is a success. Copying the files introduces an
> extra step that makes them nervous. Plus - every ISO image whose contents
> we must actually COPY means another 600+ megs we have to allocate disk to.
>
> Thoughts, anyone?
>
> If all you can say is, "That's impossible" or "You're a moron" -
> your reply will find its way into /dev/null. :-)
>
> Dave
>
> --
> Dave Ingram
> Tools and Automation Engineer
> Wolfram Research
> 217-398-0700 x776
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: Influence the future
> of Java(TM) technology. Join the Java Community
> Process(SM) (JCP(SM)) program now.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
>
> _______________________________________________
> NFS maillist - [email protected]
> https://lists.sourceforge.net/lists/listinfo/nfs
--
David B. Ritch
High Performance Technologies, Inc.
-------------------------------------------------------
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On 23 Oct 2002, seth vidal wrote:
> You might be able to work some dark magic with autofs over the nfs
> exported locations.
>
> look into how autofs functions - I think it might just be possible if
> you're not afraid of some painful thinking.
:) I wrestled with this on the 2nd night of trying to come up with
a solution.
While this may simplify the client's transaction, the server now
has to automatically:
1. Create an auto.XXX autofs config file for every ISO mounted directory
2. Update /etc/auto.master
3. the autofs daemon gets reloaded for each new addition/subtraction
All of this needs to be done by root as well. Of course, a
specialized SUID wrapper can be constructed to do this, but it's still a
bit of a boondoggle. It's fair to say, however, that almost any solution
currently will have to be a bit of a hack.
But it's hard to believe that there aren't other people with a
genuine need for something like this sort of dynamic recursive
distribution.
Thanks very much for the fast response!
Dave
--
Dave Ingram
Tools and Automation Engineer
Wolfram Research
217-398-0700 x776
-------------------------------------------------------
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Wed, 2002-10-23 at 16:16, Dave Ingram wrote:
> On 23 Oct 2002, seth vidal wrote:
>
> > You might be able to work some dark magic with autofs over the nfs
> > exported locations.
> >
> > look into how autofs functions - I think it might just be possible if
> > you're not afraid of some painful thinking.
>
> :) I wrestled with this on the 2nd night of trying to come up with
> a solution.
>
> While this may simplify the client's transaction, the server now
> has to automatically:
>
> 1. Create an auto.XXX autofs config file for every ISO mounted directory
> 2. Update /etc/auto.master
> 3. the autofs daemon gets reloaded for each new addition/subtraction
>
> All of this needs to be done by root as well. Of course, a
> specialized SUID wrapper can be constructed to do this, but it's still a
> bit of a boondoggle. It's fair to say, however, that almost any solution
> currently will have to be a bit of a hack.
>
> But it's hard to believe that there aren't other people with a
> genuine need for something like this sort of dynamic recursive
> distribution.
>
> Thanks very much for the fast response!
You could do it via nis maps - then no restarting the autofs daemon at
all.
Additionally, you could have the maps dynamically generated and pushed
from the nis master.
one place, less pain.
-sv
Quoting Dave Ingram <[email protected]>:
> We have a huge RAID system that houses, among other things, many
> ISO image files.
> The quality assurance people would like to have a "virtual
> jukebox" that is distributed via NFS to our large array of test
> machines.
> This jukebox would contain the mounted ISO images.
> However, currently there is no way to have a single parent
> directory distributed over NFS that will propogate its mounted contents.
Correct, because NFS will not cross filesystem boundaries (for various reasons).
> One must currently define an explicit mount point in /etc/exports (eg:
> /Jukebox/M-LINUX-L/6.0.0/187885).
That's easy to automate with "sed." You've probably want to setup Automounter
on the server as well, which is also trivial.
> Additionally, the client must know the explicit mount point to
> properly mount this shared image.
> This is a problem when you want to have several hundred (well, no
> more than 255 theoretically because of the 8-bit 'minor' device issue
> with loop devices) ISO images that you'd like to distribute, because you
> then are responsible for maintaining EVERY explicit mount point for each
> image, both on the server and each client.
NIS Automounter Maps make this trivial for the clients. You'll need to enable
Automounter on the client too, which is even more trivial.
> Even more frustrating is the fact that this is going to be an
> automated dynamic process. That is - as ISO images are automatically
> built by other systems, we'll want to mount and export their contents
> automatically. Likewise, we'll need to prune existing ISO images and
> their respective mounts.
Again, NIS Automounter Maps anyone???
> And, there is no way for the client-side to "know" each mount
> point in an automated fashion. That is - if the ISO builder system
> generates a new ISO image, mounts it, and distributes it, there is now a
> unique mount point that the client can't programatically determine.
I change my NIS Automounter Maps on-the-fly and it seems to get updated on my
Linux and Solaris NIS/NFS clients without issue.
> So - why the heck am I bothering NFS people with this?
> Because I am wondering if there is a way to simply have ONE mount
> point exported and mounted on the client side, and have it recursively
> inherit each of the mounted image directories within it.
No, again, because NFS won't cross filesystems.
> Also - for those who are asking, "Hey dummy - why don't you just
> mount the images on the NFS server, then copy their contents into
> /Jukebox in the appropriate directory?!". Well, because our quality
> assurance people would like to work with the EXACT files that are
> going to get burned to CD if the build is a success. Copying the
> files introduces an extra step that makes them nervous. Plus -
> every ISO image whose contents we must actually COPY means another
> 600+ megs we have to allocate disk to.
Unless you have remote clients dynamically run "mkisofs," possibly with rsh/ssh
commands.
In fact, you might be looking at this wrong. I'd just plunk the files on the
server, then make .iso files as necessary. Especially if the CDs change regularly.
> Thoughts, anyone?
> If all you can say is, "That's impossible" or "You're a moron" -
> your reply will find its way into /dev/null. :-)
I might not be understanding exactly what you want to do, but I think you're
approaching this wrong.
Also, I assume you've never messed with Automounter or NIS Automounter Maps, as
it makes the NFS world so much easier. Learn it and you'll wonder how you ever
lived without it.
--
Bryan J. Smith, E.I. Contact Info: http://thebs.org
A+/i-Net+/Linux+/Network+/Server+ CCNA CIWA CNA SCSA/SCWSE/SCNA
---------------------------------------------------------------
limit guilt = { psychopath,
remorse->0 innocent }
-------------------------------------------------------
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Wed, 23 Oct 2002, Bryan J. Smith wrote:
> Correct, because NFS will not cross filesystem boundaries (for various reasons).
I understand. But I think it's odd that I did the following
successfully:
1. Mounted 3 ISO images from the /Source partition to /Jukebox
2. Added entries for each of the /Jukebox/... directories into 'exports'
3. Reloaded NFS
4. Successfully NFS mounted and used the files from the server
How is that possible if one cannot cross filesystem boundaries on
the server side? The source partition is different than the destination
partition.
> NIS Automounter Maps make this trivial for the clients. You'll need to enable
> Automounter on the client too, which is even more trivial.
Ah. That's provided that all your clients can deal with autofs. We
have every *NIX flavor you can think of here. The single common
denominator for them is NFS.
> I change my NIS Automounter Maps on-the-fly and it seems to get updated on my
> Linux and Solaris NIS/NFS clients without issue.
Well, you're lucky - Linux and Solaris support autofs and have
consistent mechanisms for configuring them. Some of our *NIX's either
don't have anything like autofs/NIS or have completely different ways of
configuring them.
> No, again, because NFS won't cross filesystems.
I'm still confused then how I was able to perform the experiment
quoted earlier. From all appearances, I *did* cross filesystems (which as
I said confuses me greatly)
> Unless you have remote clients dynamically run "mkisofs," possibly with rsh/ssh
> commands.
You're assuming again that all the client machines HAVE something
even remotely like "mkisofs". A lot of them do not.
> In fact, you might be looking at this wrong. I'd just plunk the files on the
> server, then make .iso files as necessary. Especially if the CDs change regularly.
Unfortunately that just isn't how our software engineering system
works. SQA is explicit about having the files they test be directly FROM
the ISO image. Burning many CDs every day and shuffling them around is a
nightmare, which is why we're trying to do this.
> Also, I assume you've never messed with Automounter or NIS Automounter Maps, as
> it makes the NFS world so much easier. Learn it and you'll wonder how you ever
> lived without it.
No, I *have* worked with automounter, under Solaris several years
ago.
Dave
--
Dave Ingram
Tools and Automation Engineer
Wolfram Research
217-398-0700 x776
-------------------------------------------------------
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Quoting Dave Ingram <[email protected]>:
> I understand. But I think it's odd that I did the following
> successfully:
> 1. Mounted 3 ISO images from the /Source partition to /Jukebox
> 2. Added entries for each of the /Jukebox/... directories into
> 'exports'
> 3. Reloaded NFS
> 4. Successfully NFS mounted and used the files from the server
> How is that possible if one cannot cross filesystem boundaries on
> the server side? The source partition is different than the destination
> partition.
And you're mounting the source partition too, right? That should work then.
> Ah. That's provided that all your clients can deal with autofs. We
> have every *NIX flavor you can think of here. The single common
> denominator for them is NFS.
> Well, you're lucky - Linux and Solaris support autofs and have
> consistent mechanisms for configuring them. Some of our *NIX's either
> don't have anything like autofs/NIS or have completely different ways of
> configuring them.
Really? I've messed with AIX and Irix too and it had both as well.
Sometimes I've had to create maps named "auto_master_irix" and similiar, but it
worked.
> I'm still confused then how I was able to perform the experiment
> quoted earlier. From all appearances, I *did* cross filesystems (which
> as I said confuses me greatly)
If you mount _both_ the .iso source _and_ the loopback mount, it _will_ work.
> You're assuming again that all the client machines HAVE something
> even remotely like "mkisofs". A lot of them do not.
First off, mkisofs runs on _everything_ I've seen, even Windows.
Secondly, run "mkisofs" on the server, but write on the client.
> Unfortunately that just isn't how our software engineering system
> works. SQA is explicit about having the files they test be directly
> FROM the ISO image.
As an engineer myself, used to working in production testing environments, I
find this logic rather flawed. You aren't really running from the .iso image
anyway. ;-P
> Burning many CDs every day and shuffling them around is a
> nightmare, which is why we're trying to do this.
Again, I think your QA process is not exactly true.
> No, I *have* worked with automounter, under Solaris several years
> ago.
What UNIX client flavors are you running anyway?
--
Bryan J. Smith, E.I. Contact Info: http://thebs.org
A+/i-Net+/Linux+/Network+/Server+ CCNA CIWA CNA SCSA/SCWSE/SCNA
---------------------------------------------------------------
limit guilt = { psychopath,
remorse->0 innocent }
-------------------------------------------------------
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
On Wed, 23 Oct 2002, Bryan J. Smith wrote:
> > Ah. That's provided that all your clients can deal with autofs. We
> > have every *NIX flavor you can think of here. The single common
> > denominator for them is NFS.
> > Well, you're lucky - Linux and Solaris support autofs and have
> > consistent mechanisms for configuring them. Some of our *NIX's either
> > don't have anything like autofs/NIS or have completely different ways of
> > configuring them.
>
> Really? I've messed with AIX and Irix too and it had both as well.
Hmmmm. Has it always been in IRIX? I can't find it on our 6.3
machine. I see you are correct that it's on AIX - I missed it earlier. And
it's on HP-UX. So - perhaps I stand corrected. :-P
> > I'm still confused then how I was able to perform the experiment
> > quoted earlier. From all appearances, I *did* cross filesystems (which
> > as I said confuses me greatly)
>
> If you mount _both_ the .iso source _and_ the loopback mount, it _will_ work.
I'm still a little fuzzy on this, sorry. Is the loopback mount the
key here?
> First off, mkisofs runs on _everything_ I've seen, even Windows.
Wow. I haven't seen it work on HP-UX or Tru64. Maybe I'm missing
something.
> Secondly, run "mkisofs" on the server, but write on the client.
I misunderstood you, sorry.
> > Unfortunately that just isn't how our software engineering system
> > works. SQA is explicit about having the files they test be directly
> > FROM the ISO image.
>
> As an engineer myself, used to working in production testing environments, I
> find this logic rather flawed. You aren't really running from the .iso image
> anyway. ;-P
I certainly won't argue with you. I think, however, sanity issues
aside, we're still contending with a large pool of ISO images. We have
several hundred gigabytes in this part of the array to play with, of
course, but I like to avoid unnecessary (but maybe it IS necessary)
copying of things when I can. Especially when it sucks space aggressively.
> > Burning many CDs every day and shuffling them around is a
> > nightmare, which is why we're trying to do this.
>
> Again, I think your QA process is not exactly true.
Well, it's come a long way. I'm not in QA, but my group has
greatly reduced the number of physical CD's that get tossed around. We're
trying to get it to where the only time anybody should be burning CDs
is for an alpha or beta candidate.
> What UNIX client flavors are you running anyway?
Here's all the things we've got here:
Linux (x86, PPC, Alpha, Itanium [soon Itanium2])
Mac OS/X (well okay it's not really UNIX)
HP-UX (10.x, 11.x)
AIX (4.x, 5.x)
Tru64 (5.x)
Solaris (2.5, 2.6, 7, 8, 9)
IRIX
Hmmm - I guess that's not TOO many. Nonetheless, it's a rather
diverse bunch. IRIX and Linux-PPC (and Alpha) are going away soon (here,
that is).
Dave
--
Dave Ingram
Tools and Automation Engineer
Wolfram Research
217-398-0700 x776
-------------------------------------------------------
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs
Quoting Dave Ingram <[email protected]>:
> Hmmmm. Has it always been in IRIX? I can't find it on our 6.3
> machine. I see you are correct that it's on AIX - I missed it earlier.
> And it's on HP-UX. So - perhaps I stand corrected. :-P
I apologize since I haven't touched Irix since 1999, but I was fairly certain my
Irix 6.x systems had it. Now they _do_ sell NIS/NFS as a separate add-on which
we _did_ buy, but that was just the server. I thought the clients came standard.
> I'm still a little fuzzy on this, sorry. Is the loopback mount the
> key here?
You essentially need both. The loopback mount, since that's what is what you
are browsing, and the filesystem with the .iso files, because
> Wow. I haven't seen it work on HP-UX or Tru64. Maybe I'm missing
> something.
I've always been able to find binaries.
> I misunderstood you, sorry.
There's a million ways to run something on a server, but write to a client.
Remember, you're using UNIX. ;-P
> I certainly won't argue with you. I think, however, sanity issues
> aside, we're still contending with a large pool of ISO images.
> We have several hundred gigabytes in this part of the array to play
> with, of course, but I like to avoid unnecessary (but maybe it IS
> necessary) copying of things when I can. Especially when it sucks
> space aggressively.
> Well, it's come a long way. I'm not in QA, but my group has
> greatly reduced the number of physical CD's that get tossed around.
> We're trying to get it to where the only time anybody should be
> burning CDs is for an alpha or beta candidate.
Again, I think the QA department has a "false sense" of a loopback mounted .iso
file being the exact same as a CD. Heck, dd a CD then dd an .iso file -- not
the same because an .iso file is just the data track format for ISO9660 Yellow
Book, not the entire CD.
> Here's all the things we've got here:
> Linux (x86, PPC, Alpha, Itanium [soon Itanium2])
NIS, Autofs, NSSwitch all there.
> Mac OS/X (well okay it's not really UNIX)
Hmmm, not sure there though. BSD has an automounter, or maybe you've gotta get
amd working?
> HP-UX (10.x, 11.x)
I've only limited experience with HP-UX (1995 timeframe).
> AIX (4.x, 5.x)
All there.
> Tru64 (5.x)
All there.
> Solaris (2.5, 2.6, 7, 8, 9)
The original GNU platform (I love how the media "trips over itself" wondering
why Sun is so much like Linux ;-).
> IRIX
Again, they should be available there too.
> Hmmm - I guess that's not TOO many. Nonetheless, it's a rather
> diverse bunch. IRIX and Linux-PPC (and Alpha) are going away soon
> (here, that is).
Linux/Alpha has always been the engineer's dream platform. UNIX on an
ultra-anal RISC platform. Ahhh ...
--
Bryan J. Smith, E.I. Contact Info: http://thebs.org
A+/i-Net+/Linux+/Network+/Server+ CCNA CIWA CNA SCSA/SCWSE/SCNA
---------------------------------------------------------------
limit guilt = { psychopath,
remorse->0 innocent }
-------------------------------------------------------
This sf.net email is sponsored by: Influence the future
of Java(TM) technology. Join the Java Community
Process(SM) (JCP(SM)) program now.
http://ads.sourceforge.net/cgi-bin/redirect.pl?sunm0002en
_______________________________________________
NFS maillist - [email protected]
https://lists.sourceforge.net/lists/listinfo/nfs