• Welcome to OS2World OLD-STATIC-BACKUP Forum.
 

News:

This is an old OS2World backup forum for reference only. IT IS READ ONLY!!!

If you need help with OS/2 - eComStation visit http://www.os2world.com/forum

Main Menu

Accessing Linux JFS partitions on OS/2

Started by djcaetano, 2008.09.01, 23:13:38

Previous topic - Next topic

djcaetano


   Last week I installed Ubuntu Linux 8.04 in my machine, in the place of the old Debian Etch.
Since Ubuntu gave me the option, I formated Linux partitions as JFS.

   When I restarted OS/2 (Warp 4.52, release 2) I launched Logical Volume Manager and
found out that the Linux formated partitions are presented just as "Linux" and filesystem
unknown. I was able to select a drive letter for them, but OS/2 cannot read those drives.

  I noticed that every Linux partition is maked as "Type 83". Should I modify it's number to
type 35? Or should I reformat those partitions with OS/2 and tell Linux to not touch their
partition structure?

  Also, anyone has any experience on mounting OS/2 JFS partitions on Linux? I was
not able to mount them on Linux either.

  After all, Linux JFS and OS/2 JFS are compatible or not? :P

  Thanks in advance.

Saijin_Naib

#1
Well DJ, I had a similar issue as well when I tried gOS in place of eCS. Turns out that OS/2 Bootable JFS is structured differently than Linux JFS (DFSEE author has explained at length in the newsgroup) but yeah. I as well could not mount OS/2 JFS volumes properly, nor use Linux JFS derived tools to read OS/2 JFS volumes under windows for data recovery purposes. I'd say make a shared volume of HPFS or FAT32 so that both can play nice without being destructive to the other.

El Vato

#2
Quote from: djcaetano on 2008.09.01, 23:13:38

   Last week I installed Ubuntu Linux 8.04 in my machine, in the place of the old Debian Etch.
Since Ubuntu gave me the option, I formated Linux partitions as JFS.

   When I restarted OS/2 (Warp 4.52, release 2) I launched Logical Volume Manager and
found out that the Linux formated partitions are presented just as "Linux" and filesystem
unknown. I was able to select a drive letter for them, but OS/2 cannot read those drives.

It is the other way around, i.e., you create the JFS partitions (or volumes) with OS/2's LVM and and mount them under your GNU/Linux operating system (for data backup/recovery, for example).

Quote from: djcaetano on 2008.09.01, 23:13:38
  I noticed that every Linux partition is maked as "Type 83". Should I modify it's number to
type 35? Or should I reformat those partitions with OS/2 and tell Linux to not touch their
partition structure?

You could modify the partition's file system type to (unknown) 35 and still OS/2 will likely not be able to read its data --even if it can assign a drive letter to the partition.  Further, attempting a (JFS) file system check on the partition with the OS/2 appropriate  JFS utility inside an OS/2 command prompt window:

[WSeB]:/: jfschk32  n:  /f

(where n is the drive letter assigned by OS/2 to your GNU/Linux JFS formatted partition)

will spit out the following complaint:

JFS0068: CHKDSK  Superblock is corrupt and cannot be repaired because both
primary and secondary copies are corrupt.  CHKDSK CANNOT CONTINUE.

On the other hand, under Ubuntu (based on Debian) all you have to do is specify the partition's*  file system type (if at all) when you mount it on a given Ubuntu directory. For instance, assuming that you are the root user under Ubuntu (type sudo passwd root and provide an new root or super user password; subsequently type su root and provide your newly created root password) and assuming that you have an directory mount point under /mnt/sdax

...when we specify the type (-t) as jfs:

Huitzilopochtli:/home/jose# mount -t jfs /dev/sdax /mnt/sdax
Huitzilopochtli:/home/jose#

...and the partition is mounted and can be accessed at /mnt/sdax

(see relevant past thread link)

Note that once you (re)format the partition under OS/2 with JFS, you can write and copy data (to and from, respectively) from within your GNU/Linux environment.

Quote from: djcaetano on 2008.09.01, 23:13:38
  Also, anyone has any experience on mounting OS/2 JFS partitions on Linux? I was
not able to mount them on Linux either.

The information is provided AS-IS.  I am using GNU/Linux Debian unstable on a daily basis and mount and umount OS/2-Linux JFS formatted partitions regularly.  And, of course, I copy and put data into those volumes as the need arises.  Two idiosyncracies that you may want to be aware of are:

  • Files that you copy from OS/2 JFS formatted volumes onto you GNU/Linux file system will have all attributes null.  Accordingly, in order for those to be readable the root user should modify those attributes accordingly.  For instance, use chmod a+r <file from OS/2's LVM> to have the regular user accounts be able to read the file copied from the OS/2's LVM JFS volume.  IF you copy a whole directory structure over onto your Ubuntu file system, then use the -R switch for recursive setting  of read property to all the directory and files under it as: chmod -R a+r <directory from OS/2's LVM>. etc., etc.
  • As the super user or root in your Ubuntu, you can access all files in OS/2 LVM JFS formatted volumes.  Notwithstanding, an regular user will possibly be denied access to those partitions.

Quote from: djcaetano on 2008.09.01, 23:13:38
  After all, Linux JFS and OS/2 JFS are compatible or not? :P

...not exactly.  As you can see when attempting an file system check on an GNU/Linux JFS formatted partition.

[...]

* GNU/Linux apparently does not have the volume concept of OS/2's LVM, hence OS/2 volumes are seen as partitions on the hard disk.  Evidently, it follows logically that OS/2's LVM volumes spanned across multiple physical hard disks and/or partitions will not be able to be accessed by enabled GNU/Linux JFS utilities. 

Addendum:  Note what happens on an OS/2 LVM JFS formatted volume/partition when its file system is checked with the Debian GNU/Linux utility jfs_fsck operating on an unmounted partition/volume in read or reporting only mode (as specified by the switch -n):

Huitzilopochtli:/home/jose# jfs_fsck -n /dev/hdax
jfs_fsck version 1.1.12, 24-Aug-2007
processing started: 9/2/2008 0.55.58
The current device is:  /dev/hdax
Block size in bytes:  4096
Filesystem size in blocks:  769104
**Phase 1 - Check Blocks, Files/Directories, and  Directory Entries
**Phase 2 - Count links
**Phase 3 - Duplicate Block Rescan and Directory Connectedness
**Phase 4 - Report Problems
**Phase 5 - Check Connectivity
**Phase 6 - Perform Approved Corrections
**Phase 7 - Verify File/Directory Allocation Maps
**Phase 8 - Verify Disk Allocation Maps
  3076416 kilobytes total disk space.
      731 kilobytes in 550 directories.
  1932542 kilobytes in 2757 user files.
        0 kilobytes in extended attributes
    15337 kilobytes reserved for system use.
  1129268 kilobytes are available for use.
File system checked READ ONLY.
Filesystem is clean.

That is, it checks and reports on an OS/2 LVM JFS formatted partition/volume  --something that the OS/2 equivalent utility could not do (as illustrated priorly) on an Debian JFS formatted partition.  Keep in mind that this partition is relatively small (around 3GB) and that your "mileage" may vary on larger partitions. 

Keep in mind, also, that whereas the above was a passive operation, to actually fix the OS/2 LVM JFS formatted partition under GNU/Linux, you must make sure that,

  • The partition is unmounted --very important!
  • (adapted from the man jfs_fsck: Check the xrd partition on the 1st hard disk, print extended information to stdout, replay the transaction  log, force complete jfs_fsck checking, and give permission to repair all errors:
      jfs_fsck -v -f /dev/hdax

    Huitzilopochtli:/home/jose# jfs_fsck -v -f /dev/hdax
    jfs_fsck version 1.1.12, 24-Aug-2007
    processing started: 9/2/2008 1.17.33
    The current device is:  /dev/hdax
    Open(...READ/WRITE EXCLUSIVE...) returned rc = 0
    Primary superblock is valid.
    The type of file system for the device is JFS.
    Block size in bytes:  4096
    Filesystem size in blocks:  769104
    **Phase 0 - Replay Journal Log
    LOGREDO:  Log already redone!
    logredo returned rc = 0
    **Phase 1 - Check Blocks, Files/Directories, and  Directory Entries
    **Phase 2 - Count links
    **Phase 3 - Duplicate Block Rescan and Directory Connectedness
    **Phase 4 - Report Problems
    **Phase 5 - Check Connectivity
    **Phase 6 - Perform Approved Corrections
    **Phase 7 - Rebuild File/Directory Allocation Maps
    **Phase 8 - Rebuild Disk Allocation Maps
    Filesystem Summary:
    Blocks in use for inodes:  588
    Inode count:  4704
    File count:  2757
    Directory count:  550
    Block count:  769104
    Free block count:  282317
      3076416 kilobytes total disk space.
          731 kilobytes in 550 directories.
      1932542 kilobytes in 2757 user files.
            0 kilobytes in extended attributes
            0 kilobytes in access control lists
        15337 kilobytes reserved for system use.
      1129268 kilobytes are available for use.
    Filesystem is clean.
    All observed inconsistencies have been repaired.
    Filesystem has been marked clean.
    **** Filesystem was modified. ****
    processing terminated:  9/2/2008 1:17:35  with return code: 0  exit code: 0.
    Huitzilopochtli:/home/jose#

Accordingly, quite likely you will be able to recover your data on an unclean OS/2 LVM JFS partition.  The example above was performed on an clean OS/2 LVM JFS formated partition/volume; hence, my use of the option -f to force the check and corrections on the file system.  Sorry, I have not had the opportunity to actually have an dirty JFS partition as of late.

Well, assume that (after the correction operations by the GNU/Linux jfs_fsck utilitiy) your OS/2 can not read the volume/partition; all you have to do is to either bring over the data to your GNU/Linux side with tar (for  instance) into an archive, reformat your partition/volume with OS/2 LVM JFS utility and subsequently put the archived data back into the OS/2 LVM JFS formatted partition.

Or you could create with your OS/2 another LVM JFS partition, format it, and subsequently reboot to your GNU/Linux and rewrite your data.

Notwithstanding, your OS/2 LVM JFS formatted partition, jfs_fscked under GNU/Linux JFS utility will be accessible from within your OS/2 environment --as I have verified in my limited testing.  In summary checking (and fixing) an OS/2 LVM JFS formatted partition with appropriately enabled GNU/Linux JFS utilities retains compatibility with OS/2 later accessing those partitions --as initially hinted during the OS/2 boot procedure when the OS/2 LVM check is done and printed to the screen.  The opposite is not true, i.e., OS/2 can not access GNU/Linux JFS formatted partitions --much less operate on them with jfschk32 to attempt to repair an damaged file system.

WARNING:
Again, the information is provided AS-IS --based on my limited testing.  Should anyone desire to use it, s/he, it (if Fido uses OS/2  :D ), or them, do so at her, his, its, or their, own risk.

Regarding the
Quote from: Saijin_Naib on 2008.09.02, 00:39:46

The use of the term enabled is because not all GNU/Linux distributions, out of the box, are capable of reading/writing JFS partitions  --much less mounting them.   Those that I know that have the desired feature out-of-the-box are GNU/Linux Debian and some (all?) derivatives like Ubuntu, and Novell's SuSE up to at least 10.3 both --OpenSuSE and SLES/SLED.

The OS/2 that DC is referring to does not appear to be bootable JFS.  As mentioned in another (possibly quite old) thread, and if I recall correctly the name of the OS/2 file being OS2BOOT, I will venture forward the following:

The common denominator file that actually changes(its internal structure) when formatting an bootable OS/2 file system, such as FAT versus HPFS (have not tried 386hpfs) is the OS2BOOT.  That is, all other files in an pristine OS/2 installations remain the same --except the OS2BOOT.  Although those two file systems structure might be different, the only file that needs to be changed to accommodate those differences is the OS2BOOT file.

The change can be effectuated by the formally indicated way of typing:

SYSINSTX  Y:

to modify the OS2BOOT.  Or it could be done by overwriting the OS2BOOT file with an equivalent in the desired file system.

If we use the above analogy and apply it to the so called bootable JFS, OS2BOOT would be the only file that I would expect to be added and/or different.  Again, I would expect the rest of the file system structure to remain the same.  And I would see no reason to not be able to mount an OS/2 bootable JFS volume under an GNU/Linux JFS enabled system.  But of course, the experiment will have to delayed (likely indefinitely) and done when --and if-- the OS/2 strategy changes course, at least from my perspective.

Andrew Lee

In Linux, you can format a JFS partition as case-sensitive (the default), or case-insensitive.  OS/2 will only use case-insensitive JFS partitions, as far as I can tell.  I regularly mount JFS partitions created in OS/2 under Linux, and have mounted case-insensitive JFS partitions created in Linux under OS/2.  It's probably not a good idea to install Linux to a case-insensitive partition.

Andrew

Ben

Well, you are close.

OS/2 & JFS are case-retentive, though OS/2 does not differentiate between Upper and lower case with respect to usage.

That is to say, if you capitalize something, it stays Capitalized, but with respect to execution, there is no differentiation.

El Vato

Quote from: Ben on 2008.09.03, 02:35:35
Well, you are close.

OS/2 & JFS are case-retentive, though OS/2 does not differentiate between Upper and lower case with respect to usage.

That is to say, if you capitalize something, it stays Capitalized, but with respect to execution, there is no differentiation.


I think that Andrew did not hit the target too low, Ben.  There is an option -O to pass to the enabled GNU/Linux's jfs_mkfs utility when creating a JFS file system on an unmounted device that purportedly provides compatibility with OS/2.

From the vantage point of an GNU/Linux user, it is odd that data in those OS/2 LVM JFS formatted partitions/volumes do not obey the case sensitiveness of other Linux file systems, like XFS, RaiserFS, Extx, etc., even though the lower and upper case is retained in that data.

Ben

There should be nomenclature that differentiates the two, (are there more?), versions of JFS; Linux vs OS/2, JFS doesn't seem to be enough.

Being named the same does give one the expectation, (albeit an unfulfilled one), that they are the same.

Too bad.

When IBM released the JFS source code it seems that the OS/2 and Linux versions have gone on different paths.

(I do not use Linux myself, though I'm trying to find the time to do a VPC'd version... for which file systems will not be a problem. However, I'm planning for the possibility of having to control a separate, dual-booted Linux machine from OS/2 using HobX11 on a different machine.)

Do the OS/2 vs Linux" versions of HPFS suffer with similar divergences?

That aside...

Is there a file system that is completely transparent across both OSs? yet retain the advantages of both?

That is, in particular, useful case retention and EAs? as well as possessing the basics?(LFNs etc.).

klipp

Is there a file system that is completely transparent across both OSs? yet retain the advantages of both?

Ben , that is a problem I've been trying to resolve off and on, for over a year now (and have gotten nowhere!). Hopefully someone out there  has a usable solution that will allow us users of both OS's to interchange files & directories with ease. 
********************************************************************
Windoz Free! eCS 2.0 serving Linux, Windoz & OS2
rklipp@megared.net.mx
********************************************************************

ddan

Ben, klipp:
"Is there a file system that is _completely_transparent_ across both OSs?"

Whew. That's a HIGH requirement, when all you need to do is SOME exchange of
file DATA, not duplicate every last OS-specific detail.

Whatever. I have two solutions, my usual DULL practical kind that let one
proceed NOW instead of wishing for some exotic in the future:

1. FTP using FTPServer127 on the OS/2 system (I can't advise 130 because it
has garbage characters on its VIO setup screen, though seems to be the only
version available now on Hobbes). This works FINE, 10M bytes/S over 100Mbit
Ethernet. Set FTPServer for all permissions and you can copy / paste from the
Linux system as you wish. [That's if using KDE or other file manager on Linux
that has built in FTP.]

2. Use a version of Linux that has HPFS bound into the kernel. I'm happy with
PCLinuxOS 2007 Final from http://www.pclinuxos.com/ which, so far as I can
tell, doesn't disturb an HPFS volume at all, can be swapped (physically, for
large transfers) back and forth as needed. Obvious limitations are 2G file
size and 64G volume size, but how often does anyone hold 2G files in RAM? ──
Not often, just pieces of it, so is >2G a REAL requirement, either?

Andrew Lee

Quote from: El Vato on 2008.09.03, 17:48:01
Quote from: Ben on 2008.09.03, 02:35:35
Well, you are close.

OS/2 & JFS are case-retentive, though OS/2 does not differentiate between Upper and lower case with respect to usage.

That is to say, if you capitalize something, it stays Capitalized, but with respect to execution, there is no differentiation.


I think that Andrew did not hit the target too low, Ben.  There is an option -O to pass to the enabled GNU/Linux's jfs_mkfs utility when creating a JFS file system on an unmounted device that purportedly provides compatibility with OS/2.

From the vantage point of an GNU/Linux user, it is odd that data in those OS/2 LVM JFS formatted partitions/volumes do not obey the case sensitiveness of other Linux file systems, like XFS, RaiserFS, Extx, etc., even though the lower and upper case is retained in that data.

I've used jfs_mkfs -O to format case-insensitive JFS partitions in Linux that I could mount in OS/2.  These were compatibility volumes, and using them in OS/2 took a little work, and I didn't try test this extensively.  When I didn't use -O, so that the partitions were case-sensitive, I was unable to mount them in OS/2.

From the Linux side, what really matters is case-sensitivity.  The best-known example is that the make command will use 'Makefile' before 'makefile'.  You might be able to use a case-insensitive partition for the main Linux directories, such as /bin, /etc, /usr/..., etc., but you might very well run into trouble.  I just use JFS in Linux to access my OS/2 JFS partitions.  The file ownership and permissions being set to all 0 when a file is created in OS/2 is a nuisance (that I could fix if I wasn't using an extremely out-of-date Linux version, particularly the kernel.)  Another minor nuisance is that OS/2 uses local time for all file modification times, while Linux uses UTC in JFS.  The Linux HPFS driver converts to local time.

I don't know why IBM made OS/2 unable to access case-sensitive JFS partitions.  If you look at the documentation for the old ext_os2 IFS, there's something about problems when you have filenames that differ only by case.

It would be nice if someone could update ext2_os2 so that
1. It can work with LVM.  ext2_os2 uses a filter, ext2_flt.flt, to assign drive letters to ext2 partitions.
2. It can work with ext2/ext3 partitions that weren't formatted for compatibility with 2.0 (2.2?) or earlier Linux kernels.

Something that might be easier than an IFS, but still quite useful, would be if someone ported LTOOLS (http://www.it.fht-esslingen.de/~zimmerma/software/ltools.html) to OS/2.

El Vato

Quote from: Ben on 2008.09.03, 18:40:24
There should be nomenclature that differentiates the two, (are there more?), versions of JFS; Linux vs OS/2, JFS doesn't seem to be enough.

Being named the same does give one the expectation, (albeit an unfulfilled one), that they are the same.

I think it is a matter of perspective, Ben.  JFS first was available for AIX, a Unix implementation.  Subsequently it was adapted to the OS/2.  Hence, in its adaptation to the OS/2, JFS lost the group/user properties and the case sensitivity that it had under Unix; but maintained the case retention in data –and more important, it retained the resiliency for which it is used in enterprises where IBM Unix systems are the norm.

Seen from that perspective, OS/2ers are only observing the limitations of their particular operating system implementation of the JFS file system, as likely did the enterprise users of the OS/2 in heterogeneous environments where AIX systems were involved.  This is an glaring argument in pro of the need for change and evolution if the OS/2 is to remain relevant in multi-user, multi-group, multi-operating system scenarios, and a more flexible and efficient (think case sensitivity) Unix/Linux environments.  Those are here to stay.

The denial that I see from old timers, understandably or not, and those who refuse to acknowledge change is required, not only of the OS/2 itself but also of themselves as users of that system, is the equivalent of shoveling smoke and believing that they see clearly.

Context ???

If JFS was designed initially for IBM Unix systems, then GNU/Linux –a clone of Unix-- is actually implementing JFS as it was originally designed for AIX; that is, at the minimum an OS/2er needs to learn a few concepts if s/he desires to use JFS in the face of change brought upon by the proliferation of GNU/Linux.

Hence, an OS/2er needs to learn those properties of the JFS under GNU/Linux which are necessary to leverage JFS partitions/volumes under a multi-boot operating environment.

So we could start with the very first restatement of an observation above mentioned:


  • 1.The OS/2 implementation of JFS is a subset of that of the GNU/Linux equivalent --and not the other way around.
  • 2.Because of 1 above, an OS/2er should become familiar with the notions of root (or super user), regular user, other users, and group to which the former(s) may belong to.
  • 3.To exercise 2 above, the OS/2er needs to know what basic commands are needed to display and change root, user, and other, properties in the JFS file system implementation under GNU/Linux.
  • 4.To exercise 3 above, the OS/2er needs to have an mounted JFS file system; hence s/he should master the commands to mount those as well as learn how to make meaningful directory mount points (as root user).
  • 5.For compatibility reasons, the non-spanned JFS partitions/volumes should be created and formatted under OS/2.
  • 6.JFS Enabled GNU/Linux distributions are able to mount, check and fix the OS/2 created JFS file systems (as shown in previous post).
  • 7.Data written by OS/2 to partitions/volumes created in 5 will be accessed by enabled GNU/Linux as case insensitive, seen as case retentive, but with null attributes and root ownership.  The same will hold if GNU/Linux copies that OS/2 created data onto its own file systems.

Quote from: Ben on 2008.09.03, 18:40:24
[...]
Is there a file system that is completely transparent across both OSs? yet retain the advantages of both?

That is, in particular, useful case retention and EAs? as well as possessing the basics?(LFNs etc.).


The reason for MS huge NTFS volumes and its standardization on that file system represents their WinXX-only proprietary solution to address the problem that you pose.  It is inflexible because it forces that closed technology and a subsequent acquisition of at least one of their os products to exercise that "transparency" and convert (by the ignorance factor) their bubble-gum-chewing system administrators to no other file technologies.

Notwithstanding, virtualization has even touched the multiplicity of file systems in use today.  Accordingly, there are virtualization-based layered solutions out there that will hide the implementation details of accessing different file system types and will present an abstract layer of "transparency" to the user.  The question is, can the current technology status of the OS/2 support those kinds of virtualized file sytem/storage infrastructures ???  Can these sort of different and/or new technologies make the case for the need of true evolution of the OS/2 ???  What kind of core architecture changes are required of the OS/2 to be an active participator in those ???

Or will the old guard argue with their usual cliché of "...being secure through  obscurity [of technology] ???"   On my part, I do not like living under a rock repeating self-serving arguments over and over until I believe them (or attempt to make others believe).  I would much like to take advantage of current technological developments/implementations from the OS/2 side as well.

I have lost friends, some by death... others through sheer inability to cross the street.
  - Virginia Woolf


Ben

Greetings, El Vato.

Thanks for the additional information.

i think that everyone knows that OS/2 is long-in-the-tooth.

All we can really do is keep our fingers crossed and hope that those-hard-at-work can keep the wolves at bay.

I won't go Windows.

I learned everything about M$ back with MSDOS 5.0. And I learned it well.

Linux is a step down from my vantage point. However, if OS/2 does at some point, (and I don't see that point coming, for me, any time soon), it will be the best pick of the OS' available at that time. And I expect that there will be more, not less, options.

One thing for sure, my choice will definitely not be an online OS.

I'll stop computing first.


El Vato

Quote from: Andrew Lee on 2008.09.05, 02:57:08
[...]
I've used jfs_mkfs -O to format case-insensitive JFS partitions in Linux that I could mount in OS/2.  These were compatibility volumes, and using them in OS/2 took a little work, and I didn't try test this extensively.  When I didn't use -O, so that the partitions were case-sensitive, I was unable to mount them in OS/2.

Andrew,

Under OS/2, I had an LVM Volume/partition and had a drive letter assigned to it.  I rebooted to my GNU/Linux Lenny/Sid unstable distribution and created an OS/2 compatible JFS structure passing the -O option to jfs_mkfs --following the man page directives.  Subsequently I rebooted to OS/2 and, oddly, during the OS/2 booting phase, I saw other OS/2 LVM existing JFS volumes being checked but not the newly formatted with Debian GNU/Linux.

After OS/2 booted fully, I proceeded to (again) assign a drive letter to the Debian JFS formatted partition.  Rebooted the OS/2 and LVM JFS checking skipped the just reassigned volume drive letter.  My attempt to check the purportedly OS/2 JFS compatible volume/partition with:

jfschk32  n:  /f

printed an error similar to:

JFS0068: CHKDSK  Superblock is corrupt and cannot be repaired because both
primary and secondary copies are corrupt.  CHKDSK CANNOT CONTINUE.

...that I experienced when JFS formatting without the -O option.

Accordingly, from a pragmatic point of  view, OS/2's LVM/JFS utilities should create and format the partitions and not the other way around.

ddan

El Vato: "The denial that I see from old timers, understandably or not, and
those who refuse to acknowledge change is required, not only of the OS/2
itself but also of themselves as users of that system, is the equivalent of
shoveling smoke and believing that they see clearly."

Gee, I hardly know where to peg myself in there, old timer or Luddite. Hmm.

I'll start by mentioning that I'm rich enough to afford my very own desktop
computer, and selfish enough that I keep it my PERSONAL system for my sole
exclusive use. Back in my day [pause to wheeze], we thought that was the goal
with these new-fangled "microcomputers", to get away from relying on the high
priests of UNIX and time-sharing on some vast remote system, fairly literally
a liberation. But in your view I'm now going to become a mere "user of that
system", and forced to adapt myself to it ── instead of having mine as I wish.

Second, what exactly is this new _OS/2_ system, and where is it going to come
from? I've been wondering that for some time, and unless there's work going on
in secret and fairly lavishly funded, I doubt that a new version of anything
that's even called "OS/2" is coming out.

Third, what you outline will so change OS/2 that I might as well just go ahead
and sample Linuxes until I find one with a shell that's good at HIDING the
worst of Unix practice and traditions, and put a little work into learning how
to customize it (and then re-master). In marketing terms, a "new" OS/2 gives
up product differentiation and becomes Yet Another Linux.

Fourth, since when was OS/2 ever intended to operate a major server? (Though
part of the internal turf battles were precisely because it's powerful enough
to cut into the "big iron" market.) That's for the priest class to worry
about, and they aren't going to use desktop hardware, even though my now
antique 2800 ── lest we forget ── would have been classed a "supercomputer"
not all that long ago.

Fifth, the revolt against Vista is real and widespread. I don't consider XP or
Apple good alternatives, but people ARE seeking them. I still say that the
market niche of OS/2 is simplicity, and so should be left pretty much as is,
just a few applications updated. I'm impressed with the number of updated and
ported applications coming out, compared to 2006 when os2world rarely changed,
so it may be that sanity will break out, after all.

Sixth, to all the "OS/2 is showing its age" argument: seriously, just what do
you wish to do in it such that an application CAN'T be written? You're merely
stating that development has largely ceased ── or wishing for more eye candy
── not accurately critiquing OS/2. Its quirks and peculiarities are NOTHING
next to the maddening nagging and ceaseless stupidity of XP that I suffered
this week on a new installation (that _I_ will NOT be using). Ran out of
energy and patience before looking up how to turn off balloon tips, but that's
next. ── OS/2 was designed "from the ground up" guided by considerable
experience on mainframes. Other operating systems show their IMMATURITY, are
still flailing around trying to find the right way to operate a computer.

To sum up, here's an updated cliche: don't throw the hard drive out with the
data.

Saijin_Naib

http://www.winbookcorp.com/_technote/WBTA20000834.htm

Google is good.

Also, I've never experienced frustration until I tried to install eCS on a computer. There is much room for improvement. That said, I too do not wish for Yet Another Linux Distro, and again I turn to Windows as it's the only OS that can do what I need. Perhaps when Haiku comes out I can stop my search for a hobby OS that is not my second job.