Reviews / articles about OS/2 |
Operating systems: ArcaOS, eComStation, IBM OS/2 Warp |
|
|
|
|
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
SUMMARYThis 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. Introduction1.1. PurposeThis standard enables
We do this by
The document is used by
1.2. ConventionsComponents 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 FilesystemIt 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.
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.
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 Volume3.1 PurposeThe contents of the boot volume must be adequate to boot, restore, recover, and/or repair the system.
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:
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:
3.2 RequirementsThe following directories are required to meet eFDS standards:
3.3 Specific OptionsThe \ecs directory shall contain the following directories:
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:
The \home directory shall contain only subdirectories which in turn will contain the files and subdirectories specific to a particular user. As an example:
The \var directory shall contain the following 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)
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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:
.log - estyler.log
.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
.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
Additional information:
| Test the program: |
|
 |
Komentarze:
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.
>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 ?
>>(and don't like the same situation with var directory)
>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.
> 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.
|
| 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. |
|
(C) OS2.GURU 2001-2021
