|
ArcaOS 5.0 Russian
Russian ARCAOS exists and it's available since the middle of 2017.
All versions are supported: 5.0, 5.0.1, 5.0.2.
eCo Software is able release OS/2 LIP packages for any other language
(German, Dutch, Brazilian Portuguese, Spanish, Sweden, etc)
|
eCS File and Directory Standard (eFDS) |
TITLE: eCS File and Directory Standard (eFDS)
DATE: 2003-08-26 01:19:18
AUTHOR: Nick Morrow
Version 1
2003 May 18
Edited by Nick Morrow
Approved for release by Mensys on 2003 May 18
SUMMARY
This standard consists of a set of requirements and guidelines for file
and directory placement under the eCS operating system. The guidelines
are intended to support interoperability of applications, system
administration tools, development tools, and REXX or batch scripts as
well as greater uniformity of documentation. This standard is written
with simplicity and ease of use in mind. This document should not be
expected to answer all questions at this point as it is a work in
progress. You, the eCS user and developer are invited to provide
feedback concerning this document. Please contact your eCS supplier
with comments concerning this document.
1. Introduction
1.1. Purpose
This standard enables
- Software to predict the location of installed files and
directories, and
- Users to predict the location of installed files and
directories.
We do this by
- Specifying guiding principles for each area of the
filesystem,
- Specifying the files and directories that are required,
- Enumerating exceptions to the principles, and
- Enumerating specific cases where there has been historical
conflict.
The document is used by
- Independent software suppliers to create applications
which are eFDS compliant,
- OS maintainers to maintain eFDS compliance, and
- Users to understand and maintain the eFDS compliance of a
system.
1.2. Conventions
Components that vary are represented by a description of the contents
enclosed in "<" and ">" characters.
Optional components are enclosed in "[" and "]" characters and may be
combined with the "<" and ">" convention.
Variable substrings of directory names and filenames are indicated by
"*".
2. The Filesystem
It is possible to define two independent categories of files:
shareable vs unshareable and variable vs static. There is a simple
and easily understandable logic to understanding the reason for
defining these categories:
Why are we separating directories into shareable and nonshareable?
Primarily for ease of administration. If a system administrator must
search many locations in the file system because of a lack of clear
guidelines or adherance to guidelines then a lot of time is wasted
and the effort is more pron to errors.
Why are we separating directories into variable and static?
We need to take into consideration which directories should be
read-only and which should be read-write. Static directories should
be read only except to the system administrator while variable
directories should be read-write for more users than the system
administrator.
Shareable files are those which can be shared between different
hosts.
Unshareable files are those which are specific to a particular host.
Static files consist of files that do not change without system
administrator intervention. Examples include binaries, libraries,
and documentation.
Variable files consist of files that do change without system
administrator intervention. Examples include data files.
- In a networked environment (i.e., more than one host at a site),
there is a good deal of data that can be shared between different
hosts to save space and ease the task of maintenance. If shareable
files are grouped together in a logical manner a significant
reduction in administrator workload can be realized.
- In a networked environment, certain files contain information
specific to a single host. Therefore these filesystems cannot be
shared (without taking special measures).
- Interspersing shareable and unshareable data in the same hierarchy
makes it difficult to share large portions of the filesystem.
- Interspersing variable and static data in the same hierarchy makes
it difficult to implement a data backup plan.
Summarizing chart:
Note: eCS will contain the following minimum directories to meet
eFDS-1 guidelines. Additional root directories will be needed and
used on current releases of eCS due to the requirements of the
supporting OS/2 operating system. The goal is to consistantly
reduce until finally eliminating all directories not listed
below.
|
shareable |
unshareable |
static |
\programs |
\ecs, \etc |
variable |
\home |
\var, \etc |
- \ecs
- similar to root (/) in Linux
- static, nonshareable files
- read-only
- will not be made available on the lan
- must be located on host system
- must be on the boot volume
- must be one instance and no more on host system
- \etc
- similar to /etc in Linux
- variable and static, nonshareable files
- read-write
- will not be made available on the lan
- must be located on host system
- must be on the boot volume
- contains variable and static data requiring backup
- \home
- similar to /home in Linux
- variable, shareable files
- read-write
- may be made available on the lan
- does not need to be located on the host system
- does not need to be on the boot volume
- may be more than one instance on host system
- contains variable data requiring backup
- \programs
- similar to /usr in Linux
- static, shareable files
- read-only
- may be made available on the lan
- does not need to be located on the host system
- does not need to be on the boot volume
- may be more than one instance on host system
- \var
- similar to /var in Linux
- variable, nonshareable files
- read-write
- will not be made available on the lan
- must be located on host system
- does not need to be on the boot volume
- must be one instance and no more on host system
Note: While there are similarities to the directory system in Linux
one should not view this to mean that eCS is a re-implementation
of Linux. eCS will implement a file and directory structure that
best meets the needs of users and developers.
3. The Boot Volume
3.1 Purpose
The contents of the boot volume must be adequate to boot, restore,
recover, and/or repair the system.
- To boot a system, enough must be present on the boot volume to
mount other filesystems. This includes utilities to modify, move
and delete files in order to restore a satisfactory configuration.
Required system utilities shall be contained in the appropriate
directories in \ecs (or for now in \OS2). \ecs must be located on
the boot volume on the host system. \home and \programs are
designed such that they may be located on volumes other than the
boot volume and may, in fact, be located on systems in the network
other that the host system. \var is not required to be located on
the boot volume but it must be located on the host system as the
data contained in /var is non-shareable.
The primary concern used to balance these considerations, which favor
placing many things on the boot volume, is the goal of keeping boot
volume as small as reasonably possible. For several reasons, it is
desirable to keep the boot volume small:
- The boot volume contains many system-specific configuration
files. This means that the boot volume isn't always shareable
between networked systems. Keeping it small on servers in networked
systems minimizes the amount of lost space for areas of unshareable
files. It also allows workstations with smaller local hard drives.
- Disk errors that corrupt data on the boot volume are a greater
problem than errors on any other partition. A small root
filesystem is less prone to corruption as the result of a system
crash.
- Smaller boot volumes permit greater flexibility in system setup
and maintenance to include the use of bootable memory disks, remote
boot volumes, and "universal" boot volumes customised to fit a
particular line of identical systems.
Software must never create or require files or subdirectories in the root
directory. Other locations in the eFDS hierarchy provide more than enough
flexibility for any package.
There are several reasons why introducing a new subdirectory in the root
directory is prohibited:
- It demands space on a root partition which the system administrator
may want kept small and simple for either performance or security
reasons.
- It evades whatever discipline the system administrator may have set
up for distributing standard file hierarchies across mountable
volumes.
3.2 Requirements
The following directories are required to meet eFDS standards:
- \ecs operating system related directories
- unshareable static files
- \etc variable data files
- unshareable variable and static files
- \home user home directories
- shareable variable files
- \programs application directories
- shareable static files
- \var variable data files
- unshareable variable files
3.3 Specific Options
The \ecs directory shall contain the following directories:
- \ecs\bin essential command binaries (no subdirectories allowed)
- \ecs\book .inf files
- \ecs\boot device drivers
- \ecs\dll essential shared libraries
- \ecs\doc documentation files (contains only subdirectories)
- \ecs\help .hlp files
- \ecs\install installation files (contains subdirectories)
- \ecs\lang national language support
- \ecs\system essential system binaries (contains only subdirectories)
NOTE: \ecs\bin and \ecs\system both contain essential binaries but they
are for very different purposes. \ecs\system contains only directories
that hold files related to large complex packages, while \ecs\bin is for
standalone system utilities. There is no implied GUI/CLI split; a CLI
ini file editor and backup program can be a large complex package which
should be located in \ecs\system, while a GUI volume manager could be a
standalone binary located in \ecs\bin.
The \etc directory shall contain the following directories:
The \programs directory shall contain only subdirectories which in turn
will contain the files and subdirectories specific to a particular
application. As an example:
- \programs\browser would contain the static executable files required to
run an internet browser.
The \home directory shall contain only subdirectories which in turn
will contain the files and subdirectories specific to a particular
user. As an example:
- \home\\ would contain the directories which contain variable
configuration and data files created, owned and
maintained by . Another to view this directory
is that if needs to back up his/her work
then this is the only directory he/she should need
to back up.
The \var directory shall contain the following directories:
- \var\cache intended for cached data from applications. Such data
is locally generated as a result of time-consuming I/O
or calculation. The application must be able to
regenerate or restore the data. Unlike /var/spool, the
cached files can be deleted without data loss. The data
must remain valid between invocations of the application
and rebooting the system.
- \var\spool contains data which is awaiting some kind of later
processing. Data in \var\spool represents work to be
done in the future (by a program, user, or administrator);
often data is deleted after it has been processed.
- \var\temp temporary files and directories
Each directory listed above is specified in detail in separate
subsections below.
3.4 \ecs\bin : Essential user command binaries (for use by all users)
3.4.1 Purpose
\ecs\bin contains commands that may be used by both the system administrator
and by users. It may also contain commands which are used indirectly by
scripts or batch files.
3.4.2 Requirements
There must be no subdirectories in \ecs\bin.
\ecs\bin must be included in the SET PATH statement in CONFIG.SYS.
The following commands are required in \ecs\bin.
- cpu.exe Utility to report the number of processors installed
- mem.exe Utility to report the amount of memory installed
- unzip.exe The unzip unarchiving utility
- zip.exe The zip archiving utility
Note: This list needs to be updated prior to the next release of this
document.
The requirement for a minumum set of system utilities to perform
various maintenance and troubleshooting functions is vital to the
capability to keep the system operating as desired.
3.5 ecs\boot : Static device driver files
3.5.1 Purpose
This directory contains device drivers with the exception of device
drivers that must be located elsewhere such as BASEDEV drivers which
must be located in "\" or "\os2\boot" in current releases of eCS.
3.5.2 Requirements
Device driver loading:
A clean boot is desirable. Default driver operation will be
Quiet mode (/Q).
There are three situations where a driver may temporarily
pause the boot process and/or post a message:
- If registration is pending.
- If the driver detects a problem during boot and needs to
post a warning or error message.
- If the user tells the driver to post information by adding the
/V (Verbose) parameter to the driver in the config.sys
file.
4. CONFIG.SYS : Host-specific system configuration
4.1 Purpose
CONFIG.SYS contains much of the basic configuration information that is
specific to a system. It is necessary that we define certain mandatory
entries:
SET ETC=X:\etc
|
SET ETC sets the environment variable ETC so that programs and
utilities may determine the directory to be used for variable
and static system configuration files.
|
SET TMP=X:\var\temp
SET TEMP=X:\var\temp
|
SET TMP and SET TEMP set environment variables so that programs and
utility may determine the directory to be used for temporary files.
|
SET HOME=X:\home\
|
SET HOME sets the environment variable HOME so that programs and
utilities may determine the directory which is currently designated
as the HOME directory.
|
SET PROGRAMS=X:\programs
|
SET PROGRAMS sets the environment variable PROGRAMS so that programs,
utilities and software installers may determine the directory which is
designated as the directory where all non-system programs and
utilities should be installed.
|
SET LOGFILES=X:\etc\log |
SET LOGFILES sets the environment variable LOGFILES so that programs,
utilities and software installers may determine the directory which is
designated as the directory where all log files should be stored.
utilities should be installed.
|
It is also necessary that we define certain programming guidelines:
- Programs/utilities that create log files should check to see if
LOGFILES is set and use it if it is. If LOGFILES is not set or the
directory doesn't exist then log files should not be created. Log
file names should follow this example:
.log - estyler.log
- Programs/utilities that use ini files to store user specific
configuration information should check SET USER_INI= and use this
directory to store ini files. Ini files should follow this example:
.ini - estyler.ini
An example of the location:
SET USER_INI=x:\home\stjohnb\etc\user.ini
eStyler would then locate estyler.ini as such:
x:\home\stjohnb\etc\estyler.ini
- Programs/utilities that use ini files to store system wide
configuration information should check SET SYSTEM_INI= and use this
directory to store ini files. Ini files should follow this example:
.ini - estyler.ini
An example of the location:
SET SYSTEM_INI=X:\etc\system.ini
eStyler would then locate estyler.ini as such:
X:\etc\estyler.ini
- Programs/utilities should always check to see if their ini exists and
if it doesn't exist then a new one with reasonable defaults should be
created. INI files should be standard OS/2 style binary INI files.
- Programs/utilities should not make modifications to CONFIG.SYS with
the exception of adding required device drivers nor should they use
the user.ini or system.ini to store settings.
Additional information:
Comments: samm 2003-08-26 19:34:02 | Попытки сделать из оси недоюникс выглядят крайне смешно.. | Yuri Prokushev 2003-08-26 20:11:13 | ...., ...-.... ... .... .... ........ ............ | Eugene Gorbunoff 2003-08-26 20:28:39 | Yuri Prokushev: . ..... ..... . .... ......... .... .. ........? .. ....... .... .. ........... ..... eCS ... ... ..... ......, ... . ibm'...... OS/2. ......., ... ..... ....... *.. .........*..
........... ...... ..... ....., ... ....... ...... ............, ... ............. .... ....... .. ......... ............ . .... - ... ... ....... .. ..... .... .............. ...... .............. ............ ......., . ........... .. .... ....... ... | Evgen 2003-08-26 22:24:29 | What about compatibility with
\os2
\mptn\etc
etc. ? | ........... 2003-08-26 22:30:11 | .. ..., ......... ... .... ........ .. ......... ........... . .. .. ..... ...... ........ ..... ............ . ........... ........... .. ......... ......... ......... (unixos2 project, etc). ........., ... ....... . ...... ... .............
. ...... ........... ..... ... ...... ....... .. ........, ... ..... . .... .......... . ......... ... ... .... ......, ......... .... ......... ;) | Yuri Prokushev 2003-08-26 22:40:17 | 2Eugene Gorbunoff: ....., ... .. ........ .., ... . _......_ ........ ....... . .:\ecs, . .. d:\hachu_tak.. ... .. ........ .. .. . ... ........ var. .. .. .... . .. ....... .. ....... ....... . ....
... ..., ... ........
. ... .. ....... .... . ....... unixos2? ... .... .... .... var/etc/home. ....... . ............ .... . .......
"........" ...... ...... | Yuri Prokushev 2003-08-26 22:41:20 | ..., ......, ... ... ......, .... . .... ............ .......... ..... ... ...... ......? ..... ........ .... ......? | Nicky Morrow 2003-08-27 10:32:02 | 2 Evgen: Since eCS uses the OS/2 kernel and much of the current OS/2 distribution as its core we must retain many of the existing OS/2 directories for now. As time passes the intention is to eliminate many of the OS/2 directories so as to simplify the directory structure. The \OS2 directory cannot be removed currently and may not be removed for a long time due to hardcoding in current editions of the OS/2 kernel. The current shipping v1.1en still contains \OS2 as well as \ecs. No compatibility problems have been noted. Concerning \MPTN\ETC: Adding SET ETC=X:\ETC to config.sys as noted in eFDS-1 has not been emplemented in eCS yet. If you see any potential problems please bring them to our attention and we'll address the issue.
2 Yuri Prokushev:
> 1) I don't want hold eCS directories on boot drive.
eFDS only requires that 2 os related directories be on the boot volume: \ecs and \etc. Both of these directories are critical system directories that can reduce the functionality of the system or totally prevent the system from operating correctly if the kernel is unable to access them. If these directories could be placed on alternate volumes which could be on alternate drives then you are now look at a situation where a failure in either of two drives can take your system totally out whereas if they are located on the boot volume then the system with still be functional unless the drive the os is on goes out. I'd be interested in the specific reasons why you don't want these 2 directories on the boot drive.
>I don't like that i am obligated to place system files in c:\ecs, can I place system files in d:\hachu_tak ?
You can manually but a good argument can be made that consistancy in certain areas is more advantageous than flexibility.
>(and don't like the same situation with var directory)
I don't follow this. Please be specific.
> 2) What about compatibility with unixos2 project? This subsystem uses var/etc/home directory too.
Over a period of months last year I subscribed to the unixos2 newsgroup specifically to try to ensure there were no conflicts. I have used all of the input from this group that they made available to me. Compatibility should be good. If you have specific situations please bring them to my attention so they can be tested.
> 3) IMHO, the standard seems "raw"
It is "raw." It is very hard to find time to code and document. I'm taking time away from coding to help in the documentation. I currently have several documents in progress. This document so far contains issues that have needed to be addressed internally. Programmers and users are very welcome to submit additional items they feel should be included. The document needs to grow and mature.
> 4) I have created an application and want install help files on different languages. Where to place this help files? I don't see instructions in this standard.
I'll research the issue and get back to you. The answer to this should be in this document.
| Andrew Belov 2003-08-27 13:22:39 | It would be advantageous if separate directories for "miscellaneous" executables and "shared" 3rd-party libraries are stipulated. That is, we need to tell /bin (\OS2) from /usr/bin (e.g. \Programs\BIN), and /lib (\OS2\DLL) from /usr/lib (\Programs\DLL).
What has to be "shared"? Archivers, stand-alone 3rd-party utilities (like GO.EXE), and command-line utility sets are not worth wasting separate directories for them. The user may decide to dump them into \Programs\BIN (or whatever); but it's better this location is standardized so installers can benefit too.
The "shared" DLLs are good for exactly the same reason: to prevent pollution of \OS2\DLL; to facilitate backups and after all, they are helpful if multiple versions of OS/2 coexist on the same PC. On the system I'm typing this from, there is a similar directory that hosts the OpenGL runtime, VROBJ.DLL, VAC runtimes, NCurses DLL, OpenSSL DLLs, etc. - totaling 121 files.
Overall, the specification looks promising. If \MPTN, \IBMCOM, \IBMLAN, \MUGLIB and other "obstacles" are taken out from the root directory, personally I would call the eCS installer a success. | Yuri Prokushev 2003-08-27 13:44:02 | >> 1) I don't want hold eCS directories on boot drive.
>eFDS only requires that 2 os related directories be on the boot volume: \ecs and \etc.
Do you mean \var? \etc controlled by ETC envar
>I'd be interested in the specific reasons why you don't want these 2 directories on the boot drive.
Ok. Let's talk about \var. I don't see any reason to have \var hardcoded. Let's imagine following situation: I have some software installed with lot of log output. Having \var directory on boot partition requires or use some scripts to reduce log size (aka additional resources usage) or make boot partition bigger. Same situation with huge temporary files. With \var at boot partition I can easely have problems with free space. According \ecs. Having system files hardcoded opens gateway for destructive programs. It's can be security issue. Another issue is possibility to have boot volume as small as possible.
>>I don't like that i am obligated to place system files in c:\ecs, can I place system files in d:\hachu_tak ?
>You can manually but a good argument can be made that consistancy in certain areas is more advantageous than flexibility.
Well, I understand you can't change os2krnl much (instead of binary patching), But I'm prefer to have control over whole system, not only parts of them.
>>(and don't like the same situation with var directory)
>I don't follow this. Please be specific.
Most probably, you must think about \var, not \etc ;)
>Over a period of months last year I subscribed to the unixos2 newsgroup specifically to try to ensure there were no conflicts.
Yes, I seen.
>I have used all of the input from this group that they made available to me. Compatibility should be good. If you have specific situations please bring them to my attention so they can be tested.
None yet.
> The document needs to grow and mature.
Well. Then having mark DRAFT will be good answer for lot of questions.
>> 4) I have created an application and want install help files on different languages. Where to place this help files? I don't see instructions in this standard.
>I'll research the issue and get back to you. The answer to this should be in this document.
Really, at the present time we have many various 'standards' about support of national languages. None of them are complete. I know only two standards for messages. It is original OS/2 *.MSG files and *nix gettext.
| Isaac Leung 2003-08-27 23:53:16 | Let me first say that I'm glad this initiative is taking place. A standardized file structure is a Good Thing, in my opinion.
I have some comments about the document just released:
(BTW, I am not a computer newbie. It's my "job" and I've been at this from C64 to mainframes for something like 18 years now)
=> \etc and \var : Why? We are not trying to emulate Linux/UNIX. These names are meaningless to most average users, and we have the capability to use more than 3 letters for directories! Please, PLEASE consider getting rid of this.
If you are looking for some sort of *NIX/Linux compatibility, let these exist as an option.
Have a look at what OS X does. Even though these directories exist (for compatibilty), they are "pointed" at by a more meaningful name.
We don't have a soft-link option (do we?) and we don't need compatibility so let's make the system USER friendly. As in a common computer user, not a computer science guy. | Samm 2003-08-28 01:16:20 | i think that we dont need such system. One of the main os2 benefits is possibility to realy fast move programs from one locaion (or os) to another. because all is in one directory. If log will be in var/log and ini in other dir we well have many garbage . BTW, why not to leave os2 directory structure as is ? Only because c00l ecs huackers (which even have no sources, hehe) want to do smth. ? Better think about PM problems, or try to port openoffice. I think, that changing tree is very stupid time spending.... | Kirov Igor 2003-08-28 07:52:17 | ......... ...... - ..... ..... .... ........ ........ ..........? ... .. ..... ............ . ANSI ... ISO? ...... ...... .... ....... ............? | Matt Bear 2003-08-28 08:39:03 | >3.3 Specific Options
>The \ecs directory shall contain the following directories:
[cut to save space]
>* \ecs\book .inf files
*> \ecs\doc documentation files (contains only subdirectories)
>* \ecs\help .hlp files
[cut to save space]
Having three different subdirectories for documentation in different formats strikes me as strange. Is there a compelling reason to seperate the content this way instead of creating a single directory?
>We don't have a soft-link option (do we?)
Could TVFS provide the soft-link capability?
| Dave Saville 2003-08-28 10:35:44 | Log files: What about the style of logfile that includes the date? Some programs produce logfiles of the form yyyddmmhhmmss.log in their own dir and keep several versions. What about using *nix style cycle log programs that produce prog.log, prog.log.1 prog.log.2 prog.log.3.Z etc.? ie they keep n generations, m of which are compressed. Some programs can produce *huge* log files - having log in .etc which is tied to the boot volume conflicts with trying to keep the boot volume small. The original of /var /log is much more sensible. Think of a server rather than a workstation that is up 24*7 OK I know ECS is supposed to be a workstation but with nothing else available people are going to use it for a server - I will be. | Nicky Morrow 2003-08-28 10:44:52 | 2 Andrew Belov:
>The "shared" DLLs are good for exactly the same reason: to prevent pollution of \OS2\DLL;
Adding \programs\bin and \programs\dll is a good idea. Two things come to mind:
1) ..\bin will need to be added to the PATH and ..\dll will need to be added to the LIBPATH. It would be good to be reducing the size of the PATH and LIBPATH statements instead of growing them. Do you see any offsetting ways to reduce the sizes?
2) What about \programs\help? See the \ecs\ directory structure: We need to be consistant.
>Overall, the specification looks promising. If \MPTN, \IBMCOM, \IBMLAN, \MUGLIB and other "obstacles" are taken out from the root directory, personally I would call the eCS installer a success.
I'm pushing as hard as I can to convince the administration at Serenity that this needs to happen soonest.
2 Isaac Leung:
> Let me first say that I'm glad this initiative is taking place. A standardized file structure is a Good Thing, in my opinion.
I agree. Hopefully we are headed in the right direction.
>(BTW, I am not a computer newbie. It's my "job" and I've been at this from C64 to mainframes for something like 18 years now)
Good. Then we can count on you to sent additional items that need to be included in the document :)
>=> \etc and \var : Why? We are not trying to emulate Linux/UNIX.
It is true that we are not trying to emulate Linux/Unix. \var has been implemented in eCS v1.1en but with a very convincing case it could be changed. \etc is a more recent edition to eFDS and is not yet included in eFDS. I welcome your suggestions and reasoning behind the suggestions.
>Have a look at what OS X does. Even though these directories exist (for compatibilty), they are "pointed" at by a more meaningful name.
I have never seen OS X nor do I have access to a box running OS X. Please explain.
>We don't have a soft-link option (do we?) and we don't need compatibility so let's make the system USER friendly.
I understand. Actually a lot of what is going on here is to make things better for the user and sysadmin. That is not to say that we are doing a good job in all areas. Like I said above, please spell out the better way. I am simply the editor of the document. If I am given a better idea and a good justification it will make it easy for me to get approval for the change or addition from the eCS DevGroup.
2 Samm:
I can understand the desire not to change the exiting OS/2 directory structure, however, the current structure does not serve us well as far as where the operating system must go in order to stay competitive. In order to add capabilities such as multi-user or reduce the sysadmin burden we must have a more orderly file and directory system. Mixing applications, application data, configuration files and system files is a very poor practice and makes the product more difficult to sell and use.
In regards to your statement about locating log files and ini files in specific locations: I submit that this is a very very good practice that will enhance usability and maintainabily.
| Andrew Belov 2003-08-28 12:41:14 | To Nicky Morrow:
(1) comprises a solution by itself. Without \programs\bin, we would expect a bunch of scattered directories like \programs\cdutils\bin, \programs\archivers\bin, etc.; which are effectively eliminated by a proposed "common" path. Same for DLLs.
(2) is definitely required if we expect PM utilities to be there, and for *.MSG, if any. Can't estimate if we need a separate directory, though. On my system, I see very little utilities using a *.HLP/*.MSG file, so I've ended up placing them altogether into \programs\bin, so that \programs\bin is among %HELP%. | samm 2003-08-28 17:21:11 | I think that any user can change OS/2 fs structure as he want (using path, libpath end dpath).
Multiuser support can be perfectly added without this (see SSES project). I think, that directory structure is not real problem of os/2. Better try to rewrite PM, heh ;-)
P.S. Webmaster of this c00l site denied acces to my ip ;) (heh, anonimous proxies are so slowwww). | Thorolf 2003-08-29 01:37:36 | Sorry, but not OK at all!
- /ecs seems to be the same as the /os2-directory - do you want to make eCS-apps incompatible to OS/2????
- /etc on Linux is or settings, not for any changing data so for logs the wrong place - put it to /var/log (as in Linux)! | Nicky Morrow 2003-08-30 14:04:04 | 2 Kirov Igor:
The document is an effort to bring efficiency into the operating system by establishing standards or normal methods in several areas where standards have either not been identified by IBM or the methods identified are poor or outdated.
2 Matt Bear:
> Having three different subdirectories for documentation in different formats strikes me as strange. Is there a compelling reason to seperate the content this way instead of creating a single directory?
There was a long detailed discussion about this area amoung the members of the eCS DevGroup last year and this was what was decided at the time. The members of the group can be very flexible if somebody comes along with a better idea so please tell me how you would do it and why.
> We don't have a soft-link option (do we?)
Not that I'm aware of. Do we need one?
2 Dave Saville:
> What about the style of logfile that includes the date?
I see your point. Give me a chance to rehash this issue as I can't find the info on why the change was made right now.
> The original of /var/log is much more sensible.
Let me get back to you on this issue.
2 Thorolf:
> do you want to make eCS-apps incompatible to OS/2????
I don't understand this statement.
> /etc on Linux is for settings, not for any changing data
Settings can be in changing (variable) data files...see system.ini and user.ini as examples.
> so for logs the wrong place - put it to /var/log (as in Linux)!
I'll relook this issue. Thanks for the input.
| Stefan Milcke 2003-08-30 14:55:41 | I totally disagree with this "standard". I think we don't need such system. Please don't rename/replace old directories with this standard. I'm using and developing for OS/2 for a long time and i don't want a "new directory structure". This makes live difficult for "OS/2 Gurus".
MfG Stefan Milcke
42 ;-)
| Andreas Schnellbacher 2003-08-31 04:17:48 | Hi Nick,
creating a general dir standard is a really important thing. I concidered much about the TeX DS and before shipping NEPMD 1.00, we made a lot of considerations, too.
In details:
OS/2 program packages are different from Linux things: E.g. for the SuSE TeX dist, I hate it to have one config file 3 times on disk, not knowing which one counts. I hope, we 're not going to port this to eCS. For many existing OS/2 apps it's not possible to fit them in a Unix-like dir standard (e.g. because their development has stopped.)
So, we have to make the dir standard more flexible. I know, that current apps don't fit multi user envs. But instead of making those apps unable to be used anymore, we should find a flexible way. I know, this sucks, because it's not easy to find a standard at all. But we need a way to integrate most of the common apps (that are _not_ developed any further) and apps with current releases, where the develepor should meet the multi-user affords.
Here's the problem, I see (a 'fast shoot') with the NEPMD env.: There are many config files. The 'MYEPM' dir maybe consist only of configs. They are not subdivided according to system or user, because the main goal of our NEPMD dir standard is to fit for multiple users, not to distinguish between systems and user settings. (Almost everything is a user setting.)
I think the TeX DS might be a good example to get this goal while being flexible. In your planning you have no flexibility (but I agree with almost all your thoughts). We need flexibility, because current apps are not designed to fit into a Unix-like structure nor to a LAN env. Sorry, no more details so far. | Hendrik 2003-08-31 14:35:28 | - too much Linux
- too rigid
- the files of a program package would be too scattered
- The OS and the applications would inevitable mixed
So burn this paper, bury it and forget it !
What a total waste of time !!!
| Nicky Morrow 2003-08-31 21:28:44 | 2 Hendrik:
> too much Linux, too rigid
What would you change? Please be specific. Any particular developer can choose whatever road he/she wants to travel as the flexibility is there, however, if said developer wants to advertise "eFDS compliant" then he/she should follow the guidance in this document.
> the files of a program package would be too scattered
For a end user application package eFDS provides one place for the application files to go:
\programs\<myapp>
How is it that this is going to scatter files?
> The OS and the applications would inevitable mixed
I don't follow this statement. See above answer.
2 Stefan Milcke:
> I totally disagree with this "standard".
I've been using and developing for OS/2 since v1.3 myself. Please understand that this document is not a one person creation but rather a document that contains ideas from many in the development community. I have acted as editor. Some ideas are mine but most have been taken from others. There are at least a couple of items in the document that I don't care for but am willing to tollerate in the interest of having a standard. Please tell me specifically what you feel should be changed or added.
>and i don't want a "new directory structure". This makes live difficult for "OS/2 Gurus".
We can just agree to disagree on this point. Much of this standard is already in eCS v1.1en and I am not seeing any developer complaints so far.
| Stefan Milcke 2003-08-31 23:31:18 | > I've been using and developing for OS/2
> since v1.3 myself. Please understand
> that this document is not a one person
> creation but rather a document that contains
> ideas from many in the development community.
> I have acted as editor. Some ideas are mine
> but most have been taken from others. There
> are at least a couple of items in the document
> that I don't care for but am willing to
> tollerate in the interest of having a standard.
> Please tell me specifically what you feel
> should be changed or added.
Nothing should be added.
If you plan to replace/move \OS2, \MMOS2, \TCPIP, \MPTN etc. then please
think of all old installtions that are incompatible with this standard.
Not all old machines with Warp 3 or Warp 4 will be updated to eCS. I've two
machines with OS/2 here. One is for remote debugging device drivers and it's
at the level of Warp 4. The other machine is eCS. Working on two machines
can be confusing (where to search for device drivers, etc.) And because the
\OS2 directory is hardcoded in the kernel it is difficult to get the newest
release from testcase.
So if you really plan to replace/move these directories please let it be!
Your "Standard" is good for new applications, but not for the system.
>> and i don't want a "new directory structure".
>> This makes live difficult for "OS/2 Gurus".
> We can just agree to disagree on this point.
> Much of this standard is already in eCS v1.1en
Oh. Nice to hear this. I've already ordered 1.1DE. I think i should stop
this order or find a way to reintroduce the old directory structure.
MfG Stefan Milcke
42 ;-)
| Eugene Gorbunoff 2003-09-01 03:03:36 | 2 Stefan Milcke:
1) Your main argument - you care about compatibility with OS/2 machines in neighbourhood. Please, don't worry! eCS doesn't limit OS/2 user. Remember, that IBM OS/2 Warp was developed many years ago .. then there was a long pause.. Now the dynamics of operating system development increase and old structure doesn't correspond to current requirements of OS producer, independent developers and users. Example: old Warp3 notebook became obsolete in 1996 so Merlin was equipped with more flexible "Lotus" notebook ready to hold dosenz of pages. The functionality of old notebook was preserved (press RMB and you see tabs of old notebook).
Every eCS standard follows the same way: OS/2 developer may use the standard OS/2 structure, but If he is interested to embed his product to eCS and care about users from different countries and from different OSes then he can do this because eFDS document describes all necessary aspects: where to keep language specific stuff, where to keep user's data, etc.
I see a nice positive opportunity for BTTV subsystem! I am confused now, where to keep user's data? Imagine that I am going install new version of OS and update old software (I have old stable FileCommander, old stable BTTV, old stable cdrtools, etc). What I have to do? copy hundreds of .ini, .cfg files from the directories to temporal dir then move this files back? As I understand, eCS offers keep user's data in one place. *Every* user knows that all his custom data is located in directory ABC on disk X: There are many other simple but visual advantages of eCS.
2) The second argument - "This makes live difficult for OS/2 Gurus". You don't have troubles here.. Every guru goes to URL with eFDS standard and immediately finds necessary information. You are right, it's difficult research and accumulate OS/2 tips.. eCS team cares about you - all changes are documented and will be published.
3) Don't stop your order else eComStation.Ru will be charged as anti-eCS site :) You have came into contact with eCS developers.. and you have power to adjust changes or indicate danger. Nicky Morrow mentioned that eCS 1.1 was tested to compatibility with different subsystems and don't forget that eCS uses OS/2 Warp components. eCS is unable to break peace os OS/2 users - imagine that thousands of eCS users have installed new incompatible/incomprehensible/uncontrollable version of OS! The Earth planet will fall off from axis! :) | Nicky Morrow 2003-09-01 11:51:03 | 2 Andreas Schnellbacher:
>creating a general dir standard is a really important thing.
Yes, I think so too.
It appears that this document is giving the impression to some that it will break backward compatibility. This is not the idea at all. If an OS/2 developer wants to continue coding exactly like he/she has done for years, he/she should have no problems with eCS maintaining OS/2 compatibility. If, on the other hand, developers want to step up to a higher standard that should make the os simplier and easier to maintain and trouble shoot then they should code in accordance with eFDS and advertise that their proggy is eFDS compliant.
>So, we have to make the dir standard more flexible.
I hear you. Make specific recommendations and we'll hash out whether they should be included in eFDS.
>We need flexibility, because current apps are not designed to fit into a Unix-like structure nor to a LAN env.
I understand. As you have time to ponder and develop ideas please let me know.
2 Stefan Milcke:
The change in the traditional OS/2 directory structure is going to be very slow as we must extensively test for compatibility issues. Example: For the next release of eCS (the one after v1.1) there are currently only 3 changes being considered and scheduled for testing:
- Move: \SDD to \programs\SDD
- Delete: \IBMVESA
- Move: \SPOOL to \var\spool
I think this should show just how much care is being taken. Do you see problems with these changes? Progress will be made but not at the expense of creating chaos.
| Andrew Belov 2003-09-01 12:38:18 | To Nicky Morrow: you are exceedingly cautious. :-)
The SDD executables can rest anywhere on the system - it has no path dependencies built in.
\IBMVESA was only required for WD90C24 (the famous VLB "Windows Accelerator" video card from 1993), and it surely can be placed anywhere as well. But better if it gets purged.
Can't comment on the \SPOOL issue right now (seems to be detachable too).
However, I strongly encourage to take the issue of \MPTN, \IBMCOM, \IBMLAN and \MUGLIB into consideration for the next release of eCS, as more time will get wasted on testing the things incrementally, and from my personal view, eCS v 1.1 is already behind its schedule. | Stefan Milcke 2003-09-01 12:38:51 | 2 Eugene Gorbunoff
> 1) Your main argument - you care about compatibility with OS/2
> machines in neighbourhood. Please, don't worry! eCS doesn't limit
> OS/2 user. Remember, that IBM OS/2 Warp was developed many years
> ago .. then there was a long pause.. Now the dynamics of operating
> system development increase and old structure doesn't correspond to
> current requirements of OS producer, independent developers and users.
> Example: old Warp3 notebook became obsolete in 1996 so Merlin was
> equipped with more flexible "Lotus" notebook ready to hold dosenz
> of pages. The functionality of old notebook was preserved (press RMB
> and you see tabs of old notebook).
> Every eCS standard follows the same way: OS/2 developer may use the
> standard OS/2 structure, but If he is interested to embed his product
> to eCS and care about users from different countries and from different
> OSes then he can do this because eFDS document describes all necessary
> aspects: where to keep language specific stuff, where to keep user's
> data, etc. I see a nice positive opportunity for BTTV subsystem! I am
> confused now, where to keep user's data? Imagine that I am going install
> new version of OS and update old software (I have old stable FileCommander,
> old stable BTTV, old stable cdrtools, etc). What I have to do? copy hundreds
> of .ini, .cfg files from the directories to temporal dir then move this
> files back? As I understand, eCS offers keep user's data in one place.
> *Every* user knows that all his custom data is located in directory ABC on
> disk X: There are many other simple but visual advantages of eCS.
**************************
This is all true. But only at application level, not at operating system level.
Nicky Morrow wrote "As time passes the intention is to eliminate many of the OS/2 directories so as to simplify the directory structure.". And this is the reason why i disagree with this "standard". Why looking for BASEDEV's in \ECS\BOOT on one machine and in \OS2\BOOT on an other machine? Why change contents of \MMOS2, \TCPIP, etc?
BTTV stores it's INI's where all MMOS2's INI files are stored: in \MMOS2.
So a better way is to document the status quo for the OS and define this standard for applikation level.
> 2) The second argument - "This makes live difficult for OS/2 Gurus". You
> don't have troubles here.. Every guru goes to URL with eFDS standard and
> immediately finds necessary information. You are right, it's difficult
> research and accumulate OS/2 tips.. eCS team cares about you - all changes
> are documented and will be published.
**************************
Nice. Looking for a file in \OS2. It doesn't exist. So search in \ECS. And vice versa. Well, there are documents about this, but you have to know...
This is "trouble"!
> 3) Don't stop your order else eComStation.Ru will be charged as anti-eCS site :)
> You have came into contact with eCS developers.. and you have power to adjust
> changes or indicate danger. Nicky Morrow mentioned that eCS 1.1 was tested to
> compatibility with different subsystems and don't forget that eCS uses OS/2 Warp
> components. eCS is unable to break peace os OS/2 users - imagine that thousands
> of eCS users have installed new incompatible/incomprehensible/uncontrollable
> version of OS! The Earth planet will fall off from axis! :)
**************************
Please keep in mind what Nicky Morrow wrote: "As time passes the intention is to eliminate many of the OS/2 directories so as to simplify the directory structure."
This will break something.
MfG Stefan Milcke
42 ;-)
| Richard Gelderblom 2003-09-02 16:23:49 | Hi all,
This is my shot at a standardized tree.
My reasoning is this : have a flexible yet easy to adapt setup, not leaning on legacy
setups like *nix.
It might be a bit technical setup but OTOH you can find stuff easily and strip anything
out for a super-slim setup without having to worry about dozens of files floating about
of which you don't know what they're doing.
Also for maintaining more identical machines the \dev is what will make the difference
between them since the rest is fairly independent of that (ok a CDFS is useless if you
don't have a cd-drive in a particular machine...).
Fixes and updates can be done by using xcopy of a (partial) tree.
I know that a couple of things might not work right now since things are hardcoded
(like \os2\boot to find BASEDEVs) but that might get changed if we want to.
It's also a draft with big enough holes to drive a truck through but it might inspire ppl.
to take a different look at it and expand on what's here.
Another thing I would like to change from current installs is the vast amount of unused
drivers/protocols and such.
I have only 1 NIC in this machine, it has found and installed the corresponding driver
during install, so I don't have a need for all the other .NIFs and .OS2s in there !
Let's keep it very simple and straightforward : if I add another NIC I'll only want to
install it's drivers (and the latest version) anyway.
Same goes for SCSI, video (SDD should be the only one anyway :-) ), protocols and
whatever there is left that I'm not aware about.
And another thing : NO MORE HARDCODED PATHS !
If current os/2 is smart enough to find it's BASEDEVs in os2\boot it can also find them
using a command-line option.
Changing the BASEDEV loading from BASEDEV=IBMKBD.SYS to BASEDEV=\OS2\BOOT\IBMKBD.SYS
shouldn't impose a massive problem and would make the change to something like below
much easier.
Always on bootdrive :
\ifs (hidden for user)
\hpfs
\cdfs
\udf
\ntfs
\fat32
\ext2
\nfs
\ntwksta
\dev (hidden for user)
\ide
\scsi
\storage
\fixed
\optical
\floppy
\tape
\NIC
\Video
\audio
\usb
\serial
\firewire
\APM
\Printer
\os (r/o for user)
\os2
\bin
\dll
\book
\dos
\unix
\odin
\java
\emx
\shell (r/o for user)
\CLI
\os2
\dos
\bash
\GUI
\wps
\xfree
\network
\protocols
\netbios
\tcpip
\bin
\dll
\dev
\locale (r/o for user)
\I18N
\L10N
\Language
could be on other drive but machine related :
\logs (r/o for user)
\temp (r/o for user)
could be on other drive but shared
\apps (r/o for user)
\app1\
\bin
\dll
\app2
\bin
\dll
\users
\admin (r/w admin)
\desktop
\app1
\app2
\user (r/w user)
\desktop
\app1
\app2
It should be great if specific settings (like dos settings in config.sys) could be
taken out and put in \os\dos\boot\config.sys
The setup is so that it's fairly easy to find an IFS with _all_ it's files or a
device with _all_ it's files.
To add or remove a device or IFS or app or protocol it should only be a
self-contained tree to worry about; no files scattered all over the place.
\os should be seen as an operating environment !
\shell is a human-machine interface; it's a point of discussion whether bash (a *nix shell)
should be under \os\unix as it's not dependent on *nix per se.
It's like being able to get an os2-command prompt under xfree : os2 is too flexible !! ;-)
| Richard Gelderblom 2003-09-02 16:28:17 | Right !
The formatting got lost :-(
The main dirs are :
\ifs
\dev
\os
\shell
\network
\locale
\logs
\temp
\apps
\users
in \dev\storage are the following four subdirs.
in\os\os2 are the following three subdirs
in \shell\cli are the following three subdirst
in \shell\gui the following 2
you'll get the idea...
BTW as long as there's no real way to create symbolic links we might get by with creating wrappers around executables.
rg,rg
| Charles R. Hunter 2003-09-08 07:39:05 | Excellent work. This
should have been done ages ago.
Personally I think there are a couple of areas you should be more strict on though:
a) eCS eDFS certified programs should
not be allowed to install in \ecs directories
PERIOD. An exception should be made for
utlities that patch DLLs, but I think some
one shoudl thing *LONG AND HARD* before doing this. 99% of the time there's a better way.
b) programmers should NOT put their own entry in DLLPATH. (or path for that matter)
Make your program smarter than that. It's not tough. Any commandline programs
should be put in Programs\bin or something approriate.
c) I should also comment that you've got the right idea about \ecs being the only thing required for boot. I think that's great.
I suggest you keep the contents of that dir
as small as possible though. It used to dive
me crazy that IBM always assumed a bunch of its dirs were on the 1st boot device, haning off the root directory.
and Finally, I too have to vote for \log going in \var rather than \etc.
\etc is supposed to be user editable
config files, but programs are never supposed to write to anythign on /etc
( unless they are proporting to be on the user's behalf, ala GUI config clients )
My $0.02.
Charles
| Wendy Krieger 2003-09-09 09:31:50 | I am trying to make the boot partition as small as possible, not make it home to come what may.
Ideally, we should be heading for the direction where we could run the OS and major apps from 'read-only' directories or partitions, and consolidate user applications and data separately.
The advantage of having a tiny bootable system is that the same thing can be used to load, eg the base system and/or a maintanence system, the latter could be home to install/update/fdisk type stuff that is not required for day-to-day running.
That is, the boot sector should load enough to figure out where the user home and the operating system home is, and then continue from there. Some action from the user could activate the minimal maintanence setup, which would allow the user to do things like run an system update or run fdisk. One could do this through a program manager style interface, including a command prompt.
This same thingie could form the basis of a bootable OS/2 off the cdrom, so that one could set up a boot block separately to the program. Hey, the thing could live in the boot-manager, even....
Going for a smaller boot partition allows more operating systems, and the operating system to live anywhere.
wendy | Nicky Morrow 2003-09-12 01:20:49 | To Charles:
Thank you for the comments. I understand and will try to include as many of your suggestions as possible in the next release of eFDS.
| Teijo Kaakinen 2003-09-29 08:16:41 | I'm no expert, but after rereading both FHS 2.2 and EFDS, I would suggest including at least the concepts of /usr and /usr/local to increase modularity and facilitate disaster recovery.
According to fhs 2.2 both /usr and /usr/local contain items used by a non-sysadm, and neither is necessary just to boot the system without a GUI and do basic maintenance work. The basic VIO root system should be bootable and independently functional for maintenance (and sufficient to mount the complete system from eg. a CD-ROM).
/usr and /usr/local differ in that while /usr is designed to contain (partially optional) components and programs which are packaged as part of the distribution, /usr/local contains components which are modified or installed locally. Consequently, while there is flexibility regarding the final contetnts of /usr, it can be recreated without resorting to sources other than the original installation package, leaving /usr/local as the main branch to back up.
This arrangement also has the benefit of making it easy to bypass default components without overwriting them by placing replacement components in /usr/local, and positioning the /usr/local/<directory> entries before other entries in the various config.sys path statements.
Where the /opt (apps) directory is the right location for larger program packages (often with proprietary subdirectories), smaller binaries don't usually need a directory of their own.
Again, those included in the distribution belong in the /usr hierarchy, and additional binaries within the /usr/local hierarchy.
An example would be:
(oot+dll+in+sbin+dev) A bootable basic VIO system.
bootdrive:ecs Other operating system related directories, including WPS. Analogous to /usr.
bootdrive:etc Unsharable configuration files not modified without user/administrator intervention.
somedrive:local Analogous to /usr/local.
somedrive:home User home directories - sharable variable files. (Data produced by users.)
somedrive:programs - Application directories - sharable static files. Analogous to /opt.
somedrive:var Variable data files - unsharable variable files.
somedrive: mp Temporary files
FHS 2.2 initially looks complicated, but despite the compromises necessitated by legacy code it is well thought out. Utilizing it to a greater extent and using the same nomenclature would have benefits when porting applications. Since WPS objects can be named arbitrarily, the "Applications" folder, for example, doesn't care whether the binaries reside in the opt, programs or f00- directory.
Personally, working in an international environment I would also welcome some <man>-like rule for placing of multilingual inf and hlp files, with a compulsory index eg. in the Assistance Center folder. (It's cumbersome to have to rename multilingual .hlp and .inf files to prevent overwriting, and then later try to find them manually.)
I hope this is of some use.
Teijo | Andreas Schnellbacher 2003-10-03 23:13:34 | Some questions and suggestions:
1) estyler.ini looks more like holding user settings. It should better
be placed in \home\<user>\etc\estyler.ini.
2) I would have preferred \apps against \programs, but I can live with
it.
3) \programs\book and \programs\doc is missing, if \programs\bin should
become standard. \programs\help may be omitted, but it makes sence
in cases, where a .hlp file, but no .inf file exists: It's much
faster for .inf viewers and other help tools to search in
%bookshelf%;%help% then in %bookshelf%;%path%.
4) Do we really need an \etc dir? The user ini os2.ini is useless
without the handles from system ini os2sys.ini.
What can be put into \etc? Maybe the os2sys.ini should be put into
the user's etc dir as well: \home\<user>\etc\user.ini and
\home\<user>\etc\system.ini, because I (as a user) like to clean-up
my own inis and don't want to use polluted inis by anyone else.
5) I would agree with Thorolf, that log files should be placed in
\var\log.
6) I would like to see the order, main pathes occur in PATH, LIBPATH,
DPATH, HELP and BOOKSHELF, become standardized as well. Should e.g.
\ecs\bin come before \programs\bin or should all user extensions
come first to load the user's files first?
7) Should we get sometimes rid of DPATH, that's required only in some
rare cases?
8) I would like 1 or 2 subdirectory levels of \programs standardized as
well. That would help every user to find applications. We should
not e.g. overtake the Hobbes standard, but discuss this quite well
before realize it.
The subdirs, defined in the standard, should only be a suggestion.
Any user should be allowed to place his applications anywhere he has
write access to (if he knows what he does). The subdirs may differ
extremely on different systems, depending on the user's interests,
supposing the user has admin rights.
9) I would like to see the OS/2 network install dirs removed from root
dir as soon as possible.
10) Where should java, xfree86, emx be installed to? xfree86 must be
placed to a root dir. The emx tree must not be overwritten by emx
runtime files. Therefore the emxrt install should be made
compatible to the full emx install.
11) Should applications write their install pathes to the user.ini or
which other ways are suggested? I think, we should keep this.
| Frank Ambacher 2004-11-25 22:38:51 | 2 all
Someone wrote:
> We don't have a soft-link option (do we?) and
> we don't need compatibility so let's make the
> system USER friendly. As in a common
> computer user, not a computer science guy.
I'm not shure, but I think tvfs can do this. On os level JFS should be able. See Linux JFS.
I would prefer new directory structure on JFS, the old structure can stay on hpfs.
| tk 2005-02-15 17:13:52 | If anyone still reads this thread this is bound to stir things up, but taking into consideration the fact that gnuish software ports will increase, it might make sense to adopt the FHS in its entirety as a part of the EFDS.
The required root directories would then be:
ecs - static system files (containis all system files in appropriate subdirectories)
programs - bin dll help book doc and other systemish subdirectories for user installed additional files/programs. Analogous to the fhs usr/local directory.
opt - program packages that require their own directory or directory structure
home - user home directories - shareable variable files
etc - unshareable static system settings etc. files
var - unshareable variable settings & other system generated files
tmp - temporary files
...and the rest of the FHS directories:
bin
boot
dev
lib
media
mnt
sbin
srv
If the end user doesn't use unixish programs the redundant directories don't matter, but if he does they make porting software easier.
BTW, I also cast my vote for reserving the etc for static files only. Ideally the boot disk should be completely static. |
Comment this article.
|
|
IBM OS/2 Warp
|