Local vs Network

Local vs Network

Post by Chuck Swige » Sat, 23 Sep 2000 04:00:00



Is there a convention under FreeBSD to distinguish between per-machine and
shared resources in the filesystem?

For example, under Solaris, I generally install things like emacs and so forth
under /usr/local, which is an NFS share or otherwise duplicated (rsync) to all
machines.  Per-machine stuff, like an Oracle DB or apache, goes under
/opt.

The forthcoming MacOS X has standardized trees of resources under /Network,
/Local, and /System to do the same thing.  What about FreeBSD?

-Chuck


           -------------+-------------------+-----------
           "Diplomacy is the art of saying 'Nice doggy',
            while searching for a rock."  -- Talleyrand

 
 
 

Local vs Network

Post by Roger Marqui » Sat, 23 Sep 2000 04:00:00



>The forthcoming MacOS X has standardized trees of resources under /Network,
>/Local, and /System to do the same thing.  What about FreeBSD?

Yet another filesystem convention which differs from every other
version Unix.  Leave it to Apple, home of "not invented here", to
A) not use /usr/local and /opt, B) locate these directories on /,
and by extension C) limit their audience to a small group of
die-hards (same as they've done with the Mac).

--
Roger Marquis
Roble Systems Consulting
http://www.roble.com/

 
 
 

Local vs Network

Post by Alexander Vi » Sat, 23 Sep 2000 04:00:00





>>The forthcoming MacOS X has standardized trees of resources under /Network,
>>/Local, and /System to do the same thing.  What about FreeBSD?

>Yet another filesystem convention which differs from every other
>version Unix.  Leave it to Apple, home of "not invented here", to
>A) not use /usr/local and /opt, B) locate these directories on /,
>and by extension C) limit their audience to a small group of
>die-hards (same as they've done with the Mac).

D) use Silly Capitalization Just Because It Sounds More Profound That Way.
Yuck.

--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid.  Get yourself a better computer" - Dilbert.

 
 
 

Local vs Network

Post by Alexander Vi » Sat, 23 Sep 2000 04:00:00





>> D) use Silly Capitalization Just Because It Sounds More Profound That Way.
>> Yuck.

>Which is easier to read:

>Object *aFancyVariableName;

>Object *afancyvariablename;

Object *concise_name;

--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid.  Get yourself a better computer" - Dilbert.

 
 
 

Local vs Network

Post by Alexander Vi » Sat, 23 Sep 2000 04:00:00



>    Are you so sure?  In a world of GUIs and file managers where it's a
>    rare day indeed when a user actually types out the filename
>    explicitly...what does it even matter? -The same of course, can also
>    be said for file name expanding CLI tools like shells.

I'll say... What is the case anyway? en_US is not the only locale, after all,
and nobody said that all users have the same LC_CTYPE/LC_COLLATE.

--
"You're one of those condescending Unix computer users!"
"Here's a nickel, kid.  Get yourself a better computer" - Dilbert.

 
 
 

Local vs Network

Post by Chuck Swige » Sun, 24 Sep 2000 10:40:09




>> The forthcoming MacOS X has standardized trees of resources under /Network,
>> /Local, and /System to do the same thing.  What about FreeBSD?

> Yet another filesystem convention which differs from every other
> version Unix.  Leave it to Apple, home of "not invented here", to
> A) not use /usr/local and /opt, B) locate these directories on /,
> and by extension C) limit their audience to a small group of
> die-hards (same as they've done with the Mac).

This response was remarkably silly.

A) You can still use /usr/local; for us, it's simply a symlink into
/Network/Servers/_server_/export/OSX/usr_local.  Our main internal fileserver
(a Sun box) has lots of OS-specific trees under /export, platforms like WinNT,
Solaris, Linux, FreeBSD, and so forth.

B) /Network is intended as a placeholder for network mounts; no real content
is going to be stored on the local filesystem there.  And nothing prevents you
from making other partitions and mounting on on /Local.

C) I have some criticisms of Apple too, but you need a reality check.  Once
the final version comes out and Apple starts bundling OS X by default with all
new Macs, how long do you think it'd take for them to have more seats than
there are FreeBSD installations?

Not that numbers prove much-- I'd rather have quality that quantity.  That's
one of the reasons I admire and use FreeBSD, and I hope to see and work on
mutually benefical exchanges of ideas between FreeBSD and Darwin.

-Chuck


           -------------+-------------------+-----------
           "Diplomacy is the art of saying 'Nice doggy',
            while searching for a rock."  -- Talleyrand

 
 
 

Local vs Network

Post by Chuck Swige » Sun, 24 Sep 2000 10:55:47



> D) use Silly Capitalization Just Because It Sounds More Profound That Way.
> Yuck.

Which is easier to read:

Object *aFancyVariableName;

Object *afancyvariablename;

...?

Unix propellorheads (*) would rather sweat * than admit this simple truth,
but the fact is that most normal computer users use and _prefer_
case-insensitive filesystems.  For that matter, they also like to use spaces
in filenames too.

For me, what I'd find ideal is a case-preserving, case-intolerant filesystem
that prefers exact matches.

In other words, if there is only one file named "README" in a directory,
return it for an open()/fstat()/whatever syscall against "README", or
"readme", or even "ReAdMe".  However, you should also be able to create two
files in one directory, one named "README" and the other named "ReadMe" if you
like.  In which case, you'd return the file which matched the requested
capitalization if possible.

Funny, that sounds just about like what Samba does!  Do you think someone may
have had excellent reason to write such code?  :-)

-Chuck

-------
(*) I'm one of these, by the way.  But I don't permit myself the luxury
of catering to my personal preference for Unix, or let it get in the way of
understanding and supporting my users and clients.


           -------------+-------------------+-----------
           "Diplomacy is the art of saying 'Nice doggy',
            while searching for a rock."  -- Talleyrand

 
 
 

Local vs Network

Post by Zeni » Sun, 24 Sep 2000 11:26:39



:> D) use Silly Capitalization Just Because It Sounds More Profound That Way.
:> Yuck.
:
: Which is easier to read:
:
: Object *aFancyVariableName;
:
: Object *afancyvariablename;

        a_fancy_variable_name

        I bet you also think it's a "good idea" that MS SQL Server allows
        spaces in column and table names, because it's "easier to read"?

: Unix propellorheads (*) would rather sweat * than admit this simple
: truth, but the fact is that most normal computer users use and _prefer_
: case-insensitive filesystems.

        Are you so sure?  In a world of GUIs and file managers where it's a
        rare day indeed when a user actually types out the filename
        explicitly...what does it even matter? -The same of course, can also
        be said for file name expanding CLI tools like shells.

: For that matter, they also like to use spaces in filenames too.

        This I'll grant you, for GUI desktop users.  Traditional CLI users
        however, I'd highly doubt, for they know and feel the problems with
        them first hand.  If they weren't a problem for such users, unix has
        AFAIK always supported spaces in file names, so I'd expect to see
        far more of such files generated by common unix users, yes?

: For me, what I'd find ideal is a case-preserving, case-intolerant
: filesystem that prefers exact matches.

        If you want Windows, you know where to find it.

: In other words, if there is only one file named "README" in a directory,
: return it for an open()/fstat()/whatever syscall against "README", or
: "readme", or even "ReAdMe".  However, you should also be able to create
: two files in one directory, one named "README" and the other named
: "ReadMe" if you like.  In which case, you'd return the file which matched
: the requested capitalization if possible.

        Much like our local pseudo reverend, ambiguity is a child of Satan.
        Just say no.

: Funny, that sounds just about like what Samba does!  Do you think someone
: may have had excellent reason to write such code?  :-)

        Samba does it because it *HAS* to do it (read: emulating a networked
        Windows filesystem), not because it's a good idea.

--

BSD:  A psychoactive drug, popular in the 80s, probably developed at UC
Berkeley or thereabouts.  Similar in many ways to the prescription-only
medication called "System V", but infinitely more useful. (Or, at least,
more fun.)  The full chemical name is "Berkeley Standard Distribution".

 
 
 

Local vs Network

Post by Zeni » Sun, 24 Sep 2000 11:36:04



:>The forthcoming MacOS X has standardized trees of resources under /Network,
:>/Local, and /System to do the same thing.  What about FreeBSD?
:
: Yet another filesystem convention which differs from every other version
: Unix.  Leave it to Apple, home of "not invented here", to A) not use
: /usr/local and /opt, B) locate these directories on /, and by extension C)
: limit their audience to a small group of die-hards (same as they've done
: with the Mac).

        Hmm...IIRC the Mac OS X conventions are NeXT inspired if not lifted
        verbatim...but I can't check offhand as I haven't had my NeXT box
        running for years.  I don't think it's a question of "not invented
        here", I think it's a question of user base and the good practice of
        "path of least surprise".

        "/usr", "/opt", "/export" etc are going to mean nothing to anyone
        that isn't familiar and instructed in unix.  The words "Local",
        "System", "Network", etc should make instance sense for anyone with
        the most basic and general of computer understanding.  They also do
        not detract from the system other then cosmetically not "feeling"
        quite as much like a "unix" system.

        And for a common desktop system, the absolute last thing you want
        the system to "feel" like is a "unix" system.

--

BSD:  A psychoactive drug, popular in the 80s, probably developed at UC
Berkeley or thereabouts.  Similar in many ways to the prescription-only
medication called "System V", but infinitely more useful. (Or, at least,
more fun.)  The full chemical name is "Berkeley Standard Distribution".

 
 
 

Local vs Network

Post by Bill Vermilli » Sun, 24 Sep 2000 11:20:21





>>The forthcoming MacOS X has standardized trees of resources under
>>/Network, /Local, and /System to do the same thing. What about
>>FreeBSD?
>Yet another filesystem convention which differs from every other
>version Unix. Leave it to Apple, home of "not invented here", to A)
>not use /usr/local and /opt, B) locate these directories on /, and
>by extension C) limit their audience to a small group of die-hards
>(same as they've done with the Mac).

In case you are wondering this is what / looks like.

total 5634
drwxr-xr-x  14 root  wheel     1024 Sep  5 08:22 .
drwxr-xr-x  14 root  wheel     1024 Sep  5 08:22 ..
-rw-r--r--   1 root  wheel       90 Feb 20  1999 .hidden
dr--r--r--   2 root  wheel       96 Dec 31  1969 .vol
drwxr-xr-x   3 root  wheel     1024 Feb 28  2000 Library
drwxr-xr-x   9 root  wheel     1024 Mar  3  1999 Local
lrwxr-xr-x   1 root  wheel       15 Sep  5 08:22 Net -> Network/Servers
drwxr-xr-x  10 root  wheel     1024 Nov 15  1999 Network
drwxr-xr-x   8 root  wheel     1024 Jul  2  1999 System
drwxr-xr-x   3 root  wheel     1024 Feb 28  2000 WebObjects
drwxr-xr-x   2 root  wheel     1024 Jul 20  1999 bin
lrwxr-xr-x   1 root  wheel       13 Sep  5 08:22 cores -> private/cores
lrwxr-xr-x   1 root  wheel       11 Sep  5 08:22 dev -> private/dev
lrwxr-xr-x   1 root  wheel       11 Sep  5 08:22 etc -> private/etc
drwxrwxr-x   1 root  staff     1584 Jan 20  2000 files
drwxr-xr-x   2 root  wheel     1024 Feb 20  1999 lib
lrwxr-xr-x   1 root  wheel       11 Sep  5 08:22 mach -> mach_kernel
-r--r--r--   2 root  wheel  2867008 Jul  2  1999 mach_kernel
drwxr-xr-x   9 root  wheel     1024 Sep  5 08:22 private
drwxr-xr-x   2 root  wheel     1024 Mar  3  1999 sbin
lrwxr-xr-x   1 root  wheel       11 Sep  5 08:22 tmp -> private/tmp
drwxr-xr-x  12 root  10        1024 Dec 23  1999 usr
lrwxr-xr-x   1 root  wheel       11 Sep  5 08:22 var -> private/var

Bill
--

 
 
 

Local vs Network

Post by Chuck Swige » Sun, 24 Sep 2000 12:10:02





>:> D) use Silly Capitalization Just Because It Sounds More Profound That Way.
>:> Yuck.
>:
>: Which is easier to read:
>:
>: Object *aFancyVariableName;
>:
>: Object *afancyvariablename;

>    a_fancy_variable_name

That's okay, as well.

Can we at least agree that this is a matter of personal preference?  I'm not
motivated enough to look up the articles about word recognition performance
from cognitive psych right now.

Quote:>    I bet you also think it's a "good idea" that MS SQL Server allows
>    spaces in column and table names, because it's "easier to read"?

Stipulating for the sake of argument that the userbase of SQLServer prefers to
use spaces, then yes, I do think it's a good idea for Microsoft to write
software which caters to the stated preferences of those users.

Or do you think that software shouldn't be written to please the user rather
than just the developer?

Quote:>: Unix propellorheads (*) would rather sweat * than admit this simple
>: truth, but the fact is that most normal computer users use and _prefer_
>: case-insensitive filesystems.

>    Are you so sure?

Yes.  I'd be willing to listen to a counterargument, but I'd also like to know
what your backgound in terms of supporting large userbases is?

Quote:> In a world of GUIs and file managers where it's a
>    rare day indeed when a user actually types out the filename
>    explicitly...what does it even matter?
[ ... ]
>: For that matter, they also like to use spaces in filenames too.

>    This I'll grant you, for GUI desktop users.  Traditional CLI users
>    however, I'd highly doubt, for they know and feel the problems with
>    them first hand.  If they weren't a problem for such users, unix has
>    AFAIK always supported spaces in file names, so I'd expect to see
>    far more of such files generated by common unix users, yes?

Computer software should permit users to do reasonable things without
frustrating them with arbitrary restrictions.  And I'll bet you a good beer
that you have never had to explain to 50+ year old secretaries why they can't
save a document named "Meeting Notes".

Quote:>: For me, what I'd find ideal is a case-preserving, case-intolerant
>: filesystem that prefers exact matches.

>    If you want Windows, you know where to find it.

Correct.  So do my users and most of our clients, regardless of my personal
preferences, which is the reason why I, like most sysadmins, need to interact
with Windows from time to time.

Quote:>: In other words, if there is only one file named "README" in a directory,
>: return it for an open()/fstat()/whatever syscall against "README", or
>: "readme", or even "ReAdMe".  However, you should also be able to create
>: two files in one directory, one named "README" and the other named
>: "ReadMe" if you like.  In which case, you'd return the file which matched
>: the requested capitalization if possible.

>    Much like our local pseudo reverend, ambiguity is a child of Satan.
>    Just say no.

Umm.  Just say no to bringing either religion or the unmentionable one into
this thread, please.  :-)

Second, what ambiguity?  If you want to use mixed case, ask for it by name and
you will get an exact match without fail, exactly the way the traditional
Berkeley FFS works.

Frankly, you don't seem to understand the scope of the problem.  Do you
actually think it is useful to spend time fixing someone else's code because
their developers were coding under Windows or the Mac...and they didn't bother
to get the case right in Makefiles, #include statements, and other file
references?

Quote:>: Funny, that sounds just about like what Samba does!  Do you think someone
>: may have had excellent reason to write such code?  :-)

>    Samba does it because it *HAS* to do it (read: emulating a networked
>    Windows filesystem), not because it's a good idea.

Is the fact that Samba interoperates better with CIFS by providing
case-tolerance a good thing or a bad thing?

-Chuck


           -------------+-------------------+-----------
           "Diplomacy is the art of saying 'Nice doggy',
            while searching for a rock."  -- Talleyrand

 
 
 

Local vs Network

Post by Chuck Swige » Sun, 24 Sep 2000 12:19:27




>>        Are you so sure?  In a world of GUIs and file managers where it's a
>>        rare day indeed when a user actually types out the filename
>>        explicitly...what does it even matter? -The same of course, can also
>>        be said for file name expanding CLI tools like shells.

> I'll say... What is the case anyway? en_US is not the only locale, after all,
> and nobody said that all users have the same LC_CTYPE/LC_COLLATE.

NEXTSTEP, which is where much of the new technology in OS X came from, is one
of the very best systems ever designed in terms of localization and
International support.  And the classic MacOS is also well about the average
in this area as well.

Perhaps FreeBSD is decent here as well, but I've never had a reason to
evaluate this.  Does FreeBSD come with a filesystem that handles Unicode
filenames?

What is the standard way for the user to run programs in his "most preferred"
language, given their stated order of preference?

What is the standard system and development facilities to support
localization?

Are these interfaces actually used by most of the system code, or does most of
the system's source code assume 8-bit characters and use (char *)'s?

-Chuck


           -------------+-------------------+-----------
           "Diplomacy is the art of saying 'Nice doggy',
            while searching for a rock."  -- Talleyrand

 
 
 

Local vs Network

Post by Chuck Swige » Sun, 24 Sep 2000 12:33:12


[ ...OS X '/' listing... ]

Yep.  About the only difference is that /etc/ is a symlink to /private/etc
(which was done to facilitate handling diskless clients network-mounting
/etc), and the /Network and /Local normal-human-readable directories
previously mentioned.

-Chuck


           -------------+-------------------+-----------
           "Diplomacy is the art of saying 'Nice doggy',
            while searching for a rock."  -- Talleyrand

 
 
 

Local vs Network

Post by Timothy J. L » Sun, 24 Sep 2000 13:00:08





>> D) use Silly Capitalization Just Because It Sounds More Profound That Way.
>> Yuck.

>Which is easier to read:

>Object *aFancyVariableName;

>Object *afancyvariablename;

>...?

How about:

object *a_fancy_variable_name;

--
------------------------------------------------------------------------
Timothy J. Lee
Unsolicited bulk or commercial email is not welcome.
No warranty of any kind is provided with this message.

 
 
 

1. Local vs. Networked bootup

It seems that there is no easy way to tell Slackware weather to use
networking.

Here's how I solved this:

- modify lilo.conf so it has two linux bootup.  One with "append = 5"
  and one with "append = 3"

- modify rc.M to detect the runlevel and copy the appropriate password
  and group file into place

- modify rc.M to detect the runlevel and run rc.inet* if the runlevel
  is 5

If anyone else has another solution please let me know.  Mine is very
specific.

--
William York

2. Diamond Stealth 32 Xconfig?

3. Clustering - Network Speed vs Local Bus Speed

4. System hangs at "VFS: mounted root ..."

5. newbie question, telnet on local network vs ssh & security

6. RH 6.2 claims "partition table corrupt"

7. telnet vs. rlogin on local network

8. Ports question?

9. Linux vs OS2 vs NT vs Win95 vs Multics vs PDP11 vs BSD geeks

10. remote vs local vs NFS kernel compile (long)

11. Problem with network(connecting to internet via local network)

12. Setup sendmail for local home-network AND uucp global network

13. Local Network Over 200ft cable network disappearing