Searching \ for '[OT] ICD2 and USB' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devprogs.htm?key=icd
Search entire site for: 'ICD2 and USB'.

Exact match. Not showing close matches.
PICList Thread
'[OT] ICD2 and USB'
2005\10\19@174920 by Herbert Graf

flavicon
face
On Wed, 2005-10-19 at 17:26 -0400, Timothy J. Weber wrote:
> Harold Hallikainen wrote:
> >
> > Do Windows programs really have to spew stuff all over the hard drive? Can
> > they just work out a single install directory (and subdirectories)?
>
> There's almost always a way to avoid it, unless you're truly dependent
> on specific hardware drivers or other OS patches.
>
> Some development tools like to steer you toward shared DLLs that go in
> the system directory, though.  Personally I steer away from those tools.  :)


In the days when hard drive space was paramount there was actually a
good argument for putting stuff "everywhere": different programs could
share the same parts.

Unfortunately, what more often then not occurred was one program would
update a shared component that would break other programs that relied on
some special feature of the old shared component.

These days I don't really see ANY excuse for putting any of your files
in a place other then your own directory. I'm sure there are a small
number of reasons that are valid, probably forced on developers by
windows itself. But in the majority of cases I see NO reason for a
program to put it's files anywhere but it's own directory

Unfortunately, windows isn't alone. Linux has a similar problem where
some installs put there files in /usr/bin, others in /usr/local/bin,
others still in /usr/sbin or /usr/local/sbin, and I've even seen the odd
installer that puts stuff in /bin or /sbin!?!?

Don't know about Macs, is it still possible on a Mac to move a program
from one computer to another simply by copying it's directory over?

TTYL


-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

2005\10\19@181956 by Harold Hallikainen

face picon face

>
> Unfortunately, windows isn't alone. Linux has a similar problem where
> some installs put there files in /usr/bin, others in /usr/local/bin,
> others still in /usr/sbin or /usr/local/sbin, and I've even seen the odd
> installer that puts stuff in /bin or /sbin!?!?
>

I'm still trying to figure out the meaning of all the directories in
linux. bin makes sense for binaries... What's /usr mean? and /usr/local?
I'm thinking sbin is binaries for the superuser or root, right? Of course,
all the configs end up in /etc instead of in the directory where the
application is... And they log stuff to /var/log . So... stuff's scattered
somewhat. But what's the difference between /usr/local and /usr?

Harold


--
FCC Rules Updated Daily at http://www.hallikainen.com

2005\10\19@202359 by Herbert Graf

flavicon
face
On Wed, 2005-10-19 at 15:19 -0700, Harold Hallikainen wrote:
> >
> > Unfortunately, windows isn't alone. Linux has a similar problem where
> > some installs put there files in /usr/bin, others in /usr/local/bin,
> > others still in /usr/sbin or /usr/local/sbin, and I've even seen the odd
> > installer that puts stuff in /bin or /sbin!?!?
> >
>
> I'm still trying to figure out the meaning of all the directories in
> linux. bin makes sense for binaries... What's /usr mean? and /usr/local?
> I'm thinking sbin is binaries for the superuser or root, right? Of course,
> all the configs end up in /etc instead of in the directory where the
> application is... And they log stuff to /var/log . So... stuff's scattered
> somewhat. But what's the difference between /usr/local and /usr?

Well scattering isn't necessary bad, if all programs scatter what needs
to be scattered the exact same way. /etc is an example of this. All
programs should put their config files in this directory (or
subdirectory), and most good programs do. In a way the windows registry
is exactly the same concept: all programs put their config stuff in the
same place. There is an argument there that programs should keep their
configs in their own directories, I personally find a centralized
"config" directory a MUCH better idea.

As for the variations I can only guess. /usr/bin probably means "user
programs" (vs. "system" programs like ifconfig).

/sbin probably stands for either "system" binaries, or like you said,
superuser binaries.

local is probably reference to programs on your local machine,
vs. /usr/bin which could be on another machine over a network.

Again, all guesses on my part, I just wish there were more of a commonly
followed standard.

TTYL

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

2005\10\19@204311 by John Nall

picon face
On Wed, 2005-10-19 at 15:19 -0700, Harold Hallikainen wrote:

>>> I'm still trying to figure out the meaning of all the directories in
>>linux. bin makes sense for binaries... What's /usr mean? and /usr/local?
>>I'm thinking sbin is binaries for the superuser or root, right? Of course,
>>all the configs end up in /etc instead of in the directory where the
>>application is... And they log stuff to /var/log . So... stuff's scattered
>>somewhat. But what's the difference between /usr/local and /usr?
>>    
>>

A lot of that stuff is just historical (Unix background) and to some
degree defies any rational explanation.  ("We do it  that way because it
has always been done that way!")..  :-)  I feel sure that if you can
just manage to phrase a question to Google correctly, that you will get
an explanation of each and every directory..  But of course formulating
the correct question is easier said than done.  On the other hand,
though, it does make SOME sense, whereas Windoze makes no sense at all.  
IMHO.  Once you get beyond "My Documents" you are in Indian country.

John

2005\10\19@232209 by Tad Anhalt

picon face
Herbert Graf wrote:
> On Wed, 2005-10-19 at 15:19 -0700, Harold Hallikainen wrote:
>>I'm still trying to figure out the meaning of all the directories in
>>linux. bin makes sense for binaries... What's /usr mean? and /usr/local?
>>I'm thinking sbin is binaries for the superuser or root, right? Of course,
>>all the configs end up in /etc instead of in the directory where the
>>application is... And they log stuff to /var/log . So... stuff's scattered
>>somewhat. But what's the difference between /usr/local and /usr?

  There used to be a really good rundown of this in one of the Linux
HOWTOs.  I looked around a bit, but couldn't find it.

  Part of the problem is that different distros have different
interpretations of what goes where.  This is in addition to the
(usually) minor differences between different incarnations of *nix and
what the interpretations of those variants are.

  Keep in mind that I'm not claiming to be an expert at administration
on _any_ OS and this is from memory so take this with an appropriately
large grain of salt.

  /sbin - historically, this would contain statically linked versions
of  tools necessary for administration.  This would be handy when, say,
the system libraries are mounted over the network or are sitting on a
partition with disk errors/etc.  Clearly, these need to be on local
storage to be useful.  Lately, this seems to be turning into a catch-all
for useful system administration utils.

  /bin - binaries that are part of the os distribution.  Historically,
this would be the minimum set of system binaries that would get a
machine up and talking on the network.  Probably some of the same utils
as in /sbin, but not statically linked.

  /usr - static contents that could be shared across the environment.
  Probably network mounted, should be usable mounted read-only.
Probably changes very little unless there is an os upgrade or something
along those lines.

  /usr/local -  locally maintained contents.  Could be per-machine or
per-environment.  Sometimes both.  Generally used for things that didn't
come with the os distribution or things that do come with the
distribution but have been customized to fit the needs of the environment.

  /etc - configuration.  Unfortunately, this tends to be a mixture of
site-wide _and_ machine specific data.  In an ideal world, this would be
better separated.  Truly distributed enviroments employ various
techniques (of varying levels of hackishness) in order to hide this
somewhat.

  /var - dynamic content.  Logs/etc.  Things that change often, can
grow quickly, and are otherwise going to be the bane of whoever gets
stuck maintaining this mess.

  /opt - vendor provided content.  Sometimes optional packages provided
by the os vendor that are unsupported, sometimes commercial apps, very
similar in usage to /usr/local.

  /tmp - don't put anything here you want to keep.  World writable
scratch space.  May be memory mapped or even in ramdisk for speed.

  /home - boring user data.  Keep it small and delete it often ;)  May
be a slightly better place to store user data than /tmp but it's a
toss-up.  Historically, this would be a network resource and each user's
tiny portion of the hierarchy follows them around to any machine they
log in to.  Most applications will store user-level config here (within
the user's defined "home" directory) so that it will also follow them
wherever they may go.

  None of these are hard and fast rules and every os, every
distribution and every organization is going to have their own take on
what goes where in the hierarchy.  Similar, not identical.

  Clearly, a lot of this doesn't make as much sense outside of a
distributed environment.  PCs supporting and being maintained by a
single user weren't exactly taken into account.

  I wouldn't suggest entirely ignoring the lessons learned though.
Loosely following the structure laid out above when setting up a system
makes it a lot easier to back up the important stuff, upgrade the os,
lock things down,  migrate to a new machine (and keep all of your
settings), etc.

> Well scattering isn't necessary bad, if all programs scatter what needs
> to be scattered the exact same way. /etc is an example of this. All
> programs should put their config files in this directory (or
> subdirectory), and most good programs do. In a way the windows registry
> is exactly the same concept: all programs put their config stuff in the
> same place. There is an argument there that programs should keep their
> configs in their own directories, I personally find a centralized
> "config" directory a MUCH better idea.

  That depends on what you're trying to accomplish.  Storing in the
application directory can make installation and maintenance as simple as
moving a directory in place and adding the executables directory to the
system path.  It also makes it possible for ordinary users to install
and use the software without system permissions (provided the software
doesn't itself require additional permissions).

  You can even have the best of both worlds by linking the config files
(or config dir) into the /etc mount point.  Or even the executables to
/bin /usr/local/bin or wherever makes sense.

  Obviously there are trade offs to any approach, but IMHO making
software installation unnecessarily opaque to the user and/or
administrator causes as many problems as it solves.

Tad Anhalt

2005\10\20@082446 by Rolf

face picon face
Ok, some history...

back in the day ... when drives were smaller ;-)

/bin was mounted on the "root" partition
/usr was probably on another partition or disk.

Thus, you needed to have all the programs required to at least get to
mounting another filesystem in the /bin folder.
Once the /usr was mounted, it did not matter where the files were.

Another motivation for the seperate /usr mount point was that often, for
a number of reasons, the root filesystem was mounted as a read-only
filesystem... (you could never corrupt your core OS, and you could never
fill your root file-system, thus saving very embarrasing crashes....)

/sbin, as others have sais, is (normally)_ only accessible to the root
user, and are not programs runnable by regular users. Required only to
boot the machine.
/usr/sbin ... follows the same mount point logic as /usr/bin.

The standard is/was, that "official" programs went in to the /bin or
/usr/bin area, but locally compiled code went in to /usr/local/bin.
This is for a few reasons, but the primary one being that you can put
/usr/local/bin in front of /usr/bin in your $PATH, and thus, you can
"override" the default programs. This is especially useful with
"package" type installation mechanisms like solaris (with pkg), AIX with
it's own package installers, Linux with RPM, or deb, etc. Thus, the
"package" will install in to /usr/bin, and you can "extend or override"
the program in /usr/local/bin. The biggest benefit of this is that an
upgrade to the package will not delete your "upgrade".

Additionally, most users should have a $HOME/bin, which should be at the
front of the $PATH, making it override anything else.

Rolf

John Nall wrote:

{Quote hidden}

2005\10\20@084133 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Rolf" <spam_OUTlearrTakeThisOuTspamrogers.com>
Subject: Re: [OT] ICD2 and USB


> Additionally, most users should have a $HOME/bin, which should be at the
> front of the $PATH, making it override anything else.

Took me a long time to figure out how cool $HOME/bin is.  Nowadays with XP
you can pretty easily do a similar thing with Windoze, but there is no
convention.

--McD

2005\10\20@134832 by Peter
picon face

>>>> I'm still trying to figure out the meaning of all the directories in
>>> linux. bin makes sense for binaries... What's /usr mean? and /usr/local?
>>> I'm thinking sbin is binaries for the superuser or root, right? Of course,
>>> all the configs end up in /etc instead of in the directory where the
>>> application is... And they log stuff to /var/log . So... stuff's scattered
>>> somewhat. But what's the difference between /usr/local and /usr?

/ -> default system things (operating system, basic utilities, boot
system)

/usr -> application things to be used by user mode programs and
utilities

/usr/local/ -> as above, but customized to this machine installation
instance, sometimes moved to /opt or /var by certain distributions

/var/ -> all of the above, but especially files that must be open for
read-write (all of the directories above can be mounted read-only on a
properly configured system, as they will never be written to excepting
during software installations).

~/ -> per-user binaries, libraries and so on, specific to each user.

The basic structure of subdirectories /lib /bin /sbin /etc is repeated
under each of these as needed.

The same thing applies for configuration files. 'Default' libraries and
so for 'program' on are stored under /lib/program/... or
/usr/lib/program/..., the main (boot time) configuration files are in
/etc/ (and /usr/etc and /usr/local/etc) and the per-user configs are in
dot-files in the user's home directories (e.g. ~/.programrc).

Configuration files are slightly different. Typically, most 'properly'
written programs will look at configs in the order:

$PWD/.programrc -> a config file in the present directory
~/.programrc -> a config file in the user home directory
/etc/program.conf -> a system wide configuration file
/usr/local/lib/program/program.conf.default -> the default configuration

This allows for a lot of flexibility in configuration. The exact names
and the meaning of reading another, superseding, config file depend on
the program.

Also the environment variables PATH and MANPATH would be set
differently during various tasks. PATH sets the serach order for
directories with executables and MANPATH the same for manual pages.

So f.ex. a user who uses the ~/bin ~/man  system to install binaries for
himself (not requiring admin privileges for this) would set
PATH=~/bin:$PATH and MANPATH=~/man:$MANPATH for most operations.

Peter

2005\10\21@212426 by olin piclist

face picon face
Herbert Graf wrote:
> There is an argument there that programs should keep their
> configs in their own directories, I personally find a centralized
> "config" directory a MUCH better idea.

I don't use the OS "standard" directories for the various files of one of my
software installations for two main reasons:

1 - Keeping it in one place is more portable.  Portable in this case meaning
easier for me to create versions for other operating systems.  The official
places to put stuff are totally different accross different operating
systems.  It would be a nightmare tracking all this and making sure each
release for each OS did the right thing.

2 - It avoids name collisions.  All my stuff goes into a directory called
embedinc which is reasonably unlikely for anyone else to use.  All my
program and other files now only need to be unique within embedinc, not
within the system.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\10\21@214206 by Herbert Graf

flavicon
face
On Fri, 2005-10-21 at 21:24 -0400, Olin Lathrop wrote:
> Herbert Graf wrote:
> > There is an argument there that programs should keep their
> > configs in their own directories, I personally find a centralized
> > "config" directory a MUCH better idea.
>
> I don't use the OS "standard" directories for the various files of one of my
> software installations for two main reasons:

Actually, as you've quoted that text above it was more relevant for *nix
type OSs (and perhaps the new MacOS, which is based on BSD?)

{Quote hidden}

In windows I'd actually prefer if ALL programs put their stuff in the
registry, which is basically the same idea as the /etc directory for
Linux.

Of course, the registry has it's problems, and it's far from a perfect
solution, but it's about the only thing I'll tolerate programs fiddling
with, other then stuff in their own directory.

You are correct though, to be completely OS independent storing config
in a program's own directory is the most universal solution. But it sure
can make configuring a new system a pain in the rear.

TTYL

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

2005\10\22@123323 by olin piclist

face picon face
Herbert Graf wrote:
> In windows I'd actually prefer if ALL programs put their stuff in the
> registry,

But that makes it Windows-specific.

> which is basically the same idea as the /etc directory for
> Linux.

Or Unix specific.

This is why static configuration information for my programs are kept in
"environment files" in the ENV directory within the installation directory.
That gives me one mechanism that works on any system.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\10\22@165359 by William Chops Westfield

face picon face
On Oct 22, 2005, at 9:33 AM, Olin Lathrop wrote:

> This is why static configuration information for my programs are kept
> in
> "environment files" in the ENV directory within the installation
> directory.

This has its advantages, but one of the "problems" with windows (that
tends
to be less prevalent on unix) is the use of system-wide directories for
configuration info that SHOULD be created on a per-user basis.  Most of
the microcontroller tools we're talking about should count as
"individual
use" programs for the most part, and really ought to have config info
stored in the per-user area (perhaps in addition to system-wide
configs.)

It's too bad that the per-user areas for config info tends to be so
platform specific :-(  dot-files in the home directory for unix, files
in ~/Library/Application Support for MacOS, somewhere apparently
indirectly
located via My Documents on modern windows, and ... not available on
older
windows.

BillW

2005\10\22@181043 by olin piclist

face picon face
William Chops Westfield wrote:
> This has its advantages, but one of the "problems" with windows (that
> tends
> to be less prevalent on unix) is the use of system-wide directories for
> configuration info that SHOULD be created on a per-user basis.  Most of
> the microcontroller tools we're talking about should count as
> "individual
> use" programs for the most part, and really ought to have config info
> stored in the per-user area (perhaps in addition to system-wide
> configs.)

Actually my software supports this too.  The root environment file
(GLOBAL.ENV) defines a search path for environment files.  At startup the
root environment file is processed iteratively, each time taking into
account the search path produced by the last path.  The default GLOBAL.ENV
contains path entries for the site, node, and user.  These don't have to
exist of course, but the mechanism is there for creating custom environment
files that override the defaults in the global ENV directory.  Most
environment files are structured in such a way that the specific files need
only contain the incremental customizations, with the ones in the standard
ENV directory acting as defaults.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

More... (looser matching)
- Last day of these posts
- In 2005 , 2006 only
- Today
- New search...