Попытки сделать из оси недоюникс выглядят крайне смешно..

...., ...-.... ... .... .... ........ ............

Yuri Prokushev: . ..... ..... . .... ......... .... .. ........? .. ....... .... .. ........... ..... eCS ... ... ..... ......, ... . ibm'...... OS/2. ......., ... ..... ....... *.. .........*..

........... ...... ..... ....., ... ....... ...... ............, ... ............. .... ....... .. ......... ............ . .... - ... ... ....... .. ..... .... .............. ...... .............. ............ ......., . ........... .. .... ....... ...

What about compatibility with

\os2

\mptn\etc

etc. ?

.. ..., ......... ... .... ........ .. ......... ........... . .. .. ..... ...... ........ ..... ............ . ........... ........... .. ......... ......... ......... (unixos2 project, etc). ........., ... ....... . ...... ... .............

. ...... ........... ..... ... ...... ....... .. ........, ... ..... . .... .......... . ......... ... ... .... ......, ......... .... ......... ;)

2Eugene Gorbunoff: ....., ... .. ........ .., ... . _......_ ........ ....... . .:\ecs, . .. d:\hachu_tak.. ... .. ........ .. .. . ... ........ var. .. .. .... . .. ....... .. ....... ....... . ....

... ..., ... ........

. ... .. ....... .... . ....... unixos2? ... .... .... .... var/etc/home. ....... . ............ .... . .......

"........" ...... ......

..., ......, ... ... ......, .... . .... ............ .......... ..... ... ...... ......? ..... ........ .... ......?

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.

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.

>> 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.

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.

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....

......... ...... - ..... ..... .... ........ ........ ..........? ... .. ..... ............ . ANSI ... ISO? ...... ...... .... ....... ............?

>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?

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.

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.

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%.

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).

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)!

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.

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 ;-)

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.

- 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 !!!

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.

> 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 ;-)

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! :)

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.

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.

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 ;-)

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 !! ;-)

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

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

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

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.

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

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.

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.

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.