Linux-Advocacy Digest #130, Volume #27 Fri, 16 Jun 00 20:13:04 EDT
Contents:
Re: Dealing with filesystem volumes (Stefan Ohlsson)
Re: Linsux as a desktop platform ([EMAIL PROTECTED])
----------------------------------------------------------------------------
From: [EMAIL PROTECTED] (Stefan Ohlsson)
Crossposted-To: comp.os.ms-windows.advocacy,comp.sys.mac.advocacy,comp.unix.advocacy
Subject: Re: Dealing with filesystem volumes
Reply-To: Stefan Ohlsson <[EMAIL PROTECTED]>
Date: 17 Jun 2000 01:04:43 +0100
[EMAIL PROTECTED] wrote:
>>>Why should the regular users have to know which volume contains their files.
>>You tell them? Just a thought...
>>"Home:" perhaps.
>You missed the point of the question. I asked, "Why SHOULD the regular
>users have to know..." Your response seems to imply that you interpreted
>the question as "How COULD the regular user know...".
>
Actually I read it as WOULD, and I missed the "have to" too.
Sorry about that.
>Informing users to
>change their procedures and update their references to files because of the
>redistribution of files through the various storage devices is not an ideal
>situation. This should be a detail that is handled by the system
>administrator, supervisor, operator, or what ever title, and does not
>concern the regular users in anyway. With one or a few users sharing one or
>two computers, the method that you champion could be manageable. But what
>about when you have to manage tens, hundreds, or thousands of computers
>supporting hundreds of users each? Would you want to make sure that
>everyone is aware of the changing locations of the files that might affect
>them? And what about all the scripts and programs that they might be using
>that would have to be updated?
>
No need. The user's home directory would always be pointed to by the "Home:"
logical device. Like the $HOME env variable. When I was in the equivalent
of high school we had a novell system that we logged in to, and our home
directory was always H:.
>>Example; the system disk is becoming full, I need to move all dynamic
>>libraries to another place (disk, partition, etc). I copy it over and
>>assign the new place the logical name (for example "LIBS:") and it's done.
>>I could also divide the place where the libraries reside and put all new
>>ones in the new place. Then I only have to assign the new place as LIBS:
>>also and the system will look in both places looking for a specific
>>library.
>All right perhaps using a library directory was not the best possible
>example.
>
Why? Because it worked OK without using the Unix-way? :-)
>Consider this: there is an ambitious project that is being supported by a
>host or hosts that you are the sysadmin for. Let's say it is called the
>Forbin Project. Everyone knew that this was going to be a big project that
>would consume a large amount of storage. So an extra disk was installed
>into the central data storage host for the project. But the project has
>grown out of all estimated proportions. Other than setting up a directory
>to serve as the root directory of the project you had no authority over the
>layout of any of the data in the project--only Dr. Forbin had authority over
>that. Now the project has grown out of all proportions and beyond anyone's
>expectations. You are directed to split the data store between six
>additional disk drives. There are many, many hard coded filespecs in the
>projects programs, scripts, and data files. In the process of splitting the
>directory it is your responsibility to make certain that all these filespecs
>are still valid after the upgrade and you have no athority to examine or
>modifiy the contents of any of the files of the project.--even Dr. Forbin
>does not have that auhtority anymore. if just one hardcoded filespec fails
>to work after the upgrade, you will be taken outside of the building and
>executed by a firing squad.
>
First thing I'd do would be find Dr.Forbin and make them shoot him instead
for making such a mess out of his project. I think you would agree that
hard coded filespecs in a mess of directories here and there is no way
to run a project. Other than that I would have to say that this is an example
where hte unix way prevails and the others fail. However if Dr.Forbin (or
whoever) had put some thought into the structure of his project and used
logical assigns for different parts of the project things would have worked
out fine.
You see, using a different system you will also have to structure your things
differently. If you do, things work fine.
The only reason, BTW, why I can't expand Dr.Forbin's project is the lack of
softlinks on my system. There's really nothing in the design keeping them
from being implemented either.
How do you get unix to tell an user to insert his floppy or zip disk
labelled "MyFiles"? And how do you tell the user that he inserted the wrong
disk (if he did)? Even if it had a file with the name and in the place your
program was looking for, but the disk had the wrong label?
Or put in the spirit of your example above;
You have two floppies with the same dir structure, but one file contains
different data. They are unmarked. The program asks for the file "a" on Disk1
but will make the computer explode if you mount Disk2 and it gets to read file
"a" from Disk2. What do you do?
On a system where the disks have a name the system will ask specifically
for Disk1 and refuse Disk2 before the program gets to it.
>>It's not just an idea, it's a system in use.
>That is obvious, all these methods are in use so that comment adds nothing
>to this disscussion.
>
It clearifies the fact.
>>I have user the last option frequently not because of size issues, but for
>>the sake of modularity. When I installed a large package (IxEmul) with a
>>lot of libraries I installed everything in the same place and just added
>>references to it. That way I can 1) remove it by just deleting the entire
>>directory and remove the references and 2) upgrade it by just making a new
>>directory and install the new version there and alter the references. And
>>of course 3) disable it by just removing the references.
>Your point here is? What you are describing here can be done with unix as
>well, and has been done with unix since before the Mac or the Lisa were ever
>even thought of.
>
In unix those references would be softlinks I presume? It can be done
but in my opinion it's more messy since the logical assigns are not part
of the file system on the disk.
>>I'm not saying the unix way is bad, it's not, but I do say that other
>>solutions exist and they are not bad either.
>Of course the unix method is not bad, that is why it has been around longer
>that most other methods, and why it has already out lived so many of them as
>well.
>
Well, it hasn't outlived Windows, and that has the larger marketshare
and the worst system of all. Also, I think that the filesystem isn't
the main reason unix has been around for so long.
>> Both (indeed all) methods have problems, deal with it.
>I do deal with it, as a matter of fact I have dealt with each of these
>methods since around the time that they were first developed. I have also
>worked with other methods that have gone by the wayside and have been all
>but forgotten as well. I will work with whatever method I am required to,
>but with decades of experience with each of these methods, I find the unix
>method to be the best. What is the best filesystem, or the best file layout
>structure, may be debated. But in my opinion the unix method thet we are
>talking about here is the best method that yet exists.
>
It's good, but I don't think it has all the solutions. Neither does any
other system of course, but every system has solutions to things the others
don't.
/Stefan
--
[ Stefan Ohlsson ] · http://www.mds.mdh.se/~dal95son/ · [ ICQ# 17519554 ]
Lindsay Brigman: [about the Navy SEALS] These guys are about as
fun as a tax audit.
/The Abyss
------------------------------
From: [EMAIL PROTECTED]
Crossposted-To: comp.sys.mac.advocacy,comp.os.ms-windows.advocacy,comp.unix.advocacy
Subject: Re: Linsux as a desktop platform
Date: Fri, 16 Jun 2000 23:04:55 GMT
Try installing Mandrake and selecting anything other than Paranoid
(selecting this option causes virtually non of the installed programs
to function) and see what happens.
Check how many open ports you have.
Even Windows is not that bad....
On Fri, 16 Jun 2000 17:50:55 -0500, [EMAIL PROTECTED] wrote:
>On Fri, 16 Jun 2000 21:12:31 GMT, [EMAIL PROTECTED] (JEDIDIAH)
>wrote:
>
>>On Fri, 16 Jun 2000 15:47:02 -0500, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>>>On Fri, 16 Jun 2000 19:42:52 GMT, John Bode <[EMAIL PROTECTED]>
>>>wrote:
>>[deletia]
>>>>The general purpose desktop box won't go away completely, but I do think
>>>>that it will be less prominent in many people's lives as dedicated
>>>>information appliances become more common. People who just want email
>>>>and Web access and games can now get it without needing a PC.
>>>>
>>>>I don't see the PS2 as the future of surfing per se, but I think it
>>>>represents a major step in the evolution of this kind of appliance.
>>>>
>>>>I freely admit that my crystal ball is very hazy, and I may just be
>>>>misinterpreting some random patterns.
>>>
>>>I see the future as thin clients using technology like Microsoft
>>>Terminal Server. With a fast network (100BT, but soon gigabit
>>>ethernet will be affordable) it becomes more and more difficult, for
>>
>> You mean like Unix has been doing with X since the 80's?
>
>Yes, something like that. Except everyday people can set it up, use
>it, and work with it.
>
>What other security is there besides XHost +hostname for limiting who
>can redirect your X server or plug into your X server?
------------------------------
** 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.advocacy) 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-Advocacy Digest
******************************
