Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - djcaetano

Pages: 1 [2] 3 4 ... 14
Utilities / WARNING about WPTools3.3
« on: 2012.01.20, 19:17:29 »

  Hi there,

  I´ve uploaded a package called WPTools33.ZIP at hobbes ( Henk Kelder´s WPTools v3.2 + AssoEdit v2.1 plus an install script and a check script) but I have been warned by Doug Bisset that the check script may harm some working OS/2 or eCS (mainly non-english ones and on systems with more than one OS/2 installed).
  Since I had not added anything to the packaged (just thought I was sharing some convenient scripts) I have already asked Hobbes administrator to remove WPTOOLS33.ZIP file... but those that had already downloaded it, BE WARNED: do no use the CHECKALL.CMD ... or use it at your own risk.



Applications / Re: Error when opening OpenOffice 3.2
« on: 2012.01.18, 23:48:31 »

  Hi Melf,

just browsed the net for a moment. sal3 is a dll >> sal3.dll. Is to be found in \\ure\bin\sal3.dll . Different persons (on different platforms) report sudden such errors. Can't so far find any "one and only solution", but some talks about corrupt installations and accidently lost paths or associations. But better check yorself, you might find something out there.

  I'll take a look. Anyway, I reinstalled and the problem continues. Uninstalled it and installed OO 3.1... same problem. :(



Applications / Error when opening OpenOffice 3.2
« on: 2012.01.18, 03:55:40 »

  Hi All,

  Some weeks ago I formatted my System and installed eCS 2.1. One of the first things I installed was OpenOffice 3.2 from eCS 2.1 CD2... but I am not able to start any of OpenOffice applications. Whenever I double click one of the OO icons the following message box is displayed:

Unable to start!
Execution failed! Contact technical support.
Return code: 2
Failing module: SAL3

  Anyone had this problem? Which technical support should I contact?



USB / iPod Mini and eComStation
« on: 2012.01.17, 19:30:59 »

  I had just won an old iPod Mini and I am trying to use it under eComStation 2.1.
It has been formated by iTunes and eComStation recognizes it, assigning a drive letter;
on the other hand, no files are shown, I cannot write to it and the "Details" in the properties
notebook shows "UNKNOWN" filesystem.
  Anyone has been able to use an iPod attached to eCS / OS/2?

  I am using Lars' latest USB drivers (which are indeed great... no more traps when using USB
devices) and FAT32 driver supplied by eCS 2.1.



   This week I bought a new SATA 250GB harddrive and was able to install eCS2.0 RC7
after removing the IDE harddrive. But the install process was not without some sort of pain.
   The reason for the pain was the fact eCS is set up to boot at 800x600 and since SNAP
seems to not recognize my monitor on the first time it runs, 800x600 with some sort of
unsupported refresh rate is selected... causing an annoying "No Signal" message ("No

  Oddly enough, this problem *still* happens when installing eCS 2.1.

Networking / Re: Sloooooooooow Samba Server
« on: 2011.12.30, 19:39:21 »
It must be very large files, because it seems that things like directory listings take "forever" (roughly 50 KB/s, even on a 1 GB connection), and, if you have lots of small files, it spends more time looking up the directory entries, than it does transferring files.
Sadly, I find that I need to restart SAMBA every few minutes.

  Well, it is exactly what I´ve just discovered. One of harddisks had only large files, and it was transferred in almost no time.
  The most bizarre thing is the CPU usage when Samba Server is sending files to a client. It just doesn't make much sense to me.


  Daniel Caetano

Networking / Sloooooooooow Samba Server
« on: 2011.12.30, 04:19:42 »

  Hi There,

  I have been using Samba Server on eCS 2.0 for a while, but had never used it to transfer large amounts of data... until yesterday.
  I decided to make a backup using my local 100mbps network connection and mapped all OS/2 drives on the network so I could read them on another computer, which runs Windows 7.
  As expected, the drives are shown on Windows 7 "Network" and I am able to copy files ... but the copy is rather slow. The transfer rate is about 300KB/s... :/
  Also, my eCS box CPU goes 100% while transfers are being carried. Sometimes windows loses the connection also, and I am obligated to restart Samba Server so the copy may continue.

  Any clues on how to improve the transfer performance?


  Daniel Caetano


Hardware / Re: Intel H67 Motherboard - Here we go again
« on: 2011.10.20, 14:05:39 »


same results too...

I think I will wait to see if the bug 0003093 will be solved one day....

   I believe soon Mensys will release some fix to address this problem. On these new machines,
ACPI is obligatory and a new ACPI version is needed, since the version that comes with
eCS 2.1 doesn't support these systems.

   We must learn patience... or we will be dragged to the dark side... :)


Setup & Installation / Re: RPM packager
« on: 2011.09.02, 05:43:49 »

  I really *do* understand the reason to incorporate FHS into the system so it would simplify porting and management. And, in fact, as I had already said before, I *do* support it. I think it is perfect using RPM and YUM to install and maintain ports of Unix applications on eCS, all stored in a single FHS. It is a mess for the end user? Well, it is a mess in the original system (Linux), the developers and porters don´t have to be responsible to "correct" this... even more if the maintainers of the code do not accept our patches in the main tree because our system is "so different".
  Kudos for creating a Linux FHS and installing with RPM and YUM if this will bring more up-to-date software from Linux.

  What I *do not* understand is WHY convert the entire operating system into this FHS mess?
  No matter what is being ported, the base operating system and utilities will be ALWAYS specific software (unless there are secret plans to replace OS/2 base by a Linux base). No change on FHS will allow Linux drivers and installable filesystems to work "automagicaly" on eCS.
  Specific OS/2 programs will never be ported to Linux and creating an "eCS integrated Linux port" usually requires much more effort than converting file structures (like adding WPS integration and so on).
  Also, all the old software - I do not plan to let good old software bit the dust - will be installed in the same old fashioned way. FHS will have to live side by side with "old" organization.

   Most of die hard OS/2 users are fond to it because it DO preserves the users investment... many of the years of knowledge about the operating system will be wasted if all of a sudden every piece of software has been moved elsewhere. It may seem weird to you, but if I´ll have to "learn"  the entire Operating System again, maybe it´s time to learn something current, up to date and that is able to run on my i7 generation 2 (by the way, eCS doesn´t boot on it, and I am sure it´ll not boot even if ALL Linux applications have been ported to eCS 3.0 with Unix FHS).

   The only thing I think it is good for the general user on FHS is the "backup easiness". OTOH, everything else is just crap and mess. Spread application files into several directories is, on my PoV, far from a good idea, and it is an OLD idea when all the applications were composed of and executable and a help file. Oh, it makes development so easy?
   Remember, directories purpose should be to help the user on *organizing* its files, not to put handcuffs on them.


Setup & Installation / Re: RPM packager
« on: 2011.08.31, 20:26:34 »

  Hi Yuri,

just a few notes about RPM/YUM development, just to report here something that I showed at WSE Europe in Harleem (NL), and something more.
While FHS tree is actually used, probably it can be reduced. I say 'probably' because this will require testing.
The choice to point UNIXROOT to a root directory of a drive has been done to simplify initial work; pointing UNIXROOT to a subdirectory could already work, but most apps are not tested in this environment.
Installation of packages to FHS is only forced for core packages: nothing precludes using different paths or even relocatable packages for other apps.

  This is great news!

  I believe the oposition to a FHS would be reduced if it is
presented in a reduced form just like this:

sys (base os files, replacing /OS2 and /eCS)
   may include sub dirs like bin, lib and etc for system specific binaries,
   libraries and config
etc (system wide configurations, replacing /MPTN/etc and more widely used... maybe    including even CONFIG.SYS)
bin (programs, replacing /Programs)
   base dir for small apps and automatically added to PATH
   May include subdirs for each application, which may include /lib for
   non-shared libraries
lib (shared libraries, automatically aded to LIBPATH)
tmp (temporary files, already existis)
var (logs and other semi-temporary data, already exists)
home (user files, automatically loaded as %HOME% and added to DPATH)
   should include a subdir "etc" for configuration files

"usr" dir may be created on specific systems, when development applications are installed, and inside all those development directories (bin, include, and so on), which may be added to the specific path variable

I don't know if this is possible, because some Linux apps are so fond of /usr/bin for installation... but in the perfect world, we could have a FHS and, at the same time, be free from "fractal subdirectory hell" that plagues some Unix installments.

In fact, the more flexible way to do that would be defining every path to a system variable (%SYS%, %ETC%, %BIN%, %LIB%, %TMP%, %VAR%, %HOME%, %USR% and so on), but I think this is not really possible (unless the libc is "hacked" to do the trick... and even then, this may be somewhat error prone).

While release 00 is FHS structured, we can get release 01 to be more friendly, and it will update itself (at least I hope so, release 01 is still empty, so we can't test...). And then move to 02, 03, ...
We need only one thing: more resources (read developers) to work on it.
I hope you  will understand this work could give you a lot of features, please be patient.

   I understand that. And I wish you all succeed organizing the mess and making everything easy for everyone (developers and users).

  My kindest regards,

  Daniel Caetano

Setup & Installation / Re: RPM packager
« on: 2011.08.31, 16:19:23 »

Please, do not see this message as a challenge. I am not trying to prove you wrong or that I am right.
I am just trying to describe to you WHY some people rejects FHS... something that - at least in my case - has nothing to do with fear.

I apologize if my comments seemed obtuse, but I have a pretty good deal of knowledge over FHS. I have been using Debian distros (which follow almost strictly the FHS) for several years and I did not wanted to say "the only thing FHS has support is multi-user"... What I tried to say is "the only *good* reason to explain FHS is multi-user and security". Of course, that reflects my Point of View. On my PoV, all other "good things" obtained by FHS are simply a matter of standard... of course standards have benefits, but lets face it: not even Linux users agree when an /opt directory is needed or not! :)
(why the hell OpenOffice is/was installed inside /opt !?)

The reason for /bin, /sbin, /usr/bin, for instance, is pretty unclear, since a description like "/bin : Essential user command binaries (for use by all users)" is just pretty subjective and may be interpreted in a million of ways. What is an essential command to me may not be an essential command for you. /sbin is even more unclear... "/sbin : System binaries" What is a "system binary"? Executables provided which eCS? All of them? Should xWorkplace be placed there? Or only pmformat? A "system utility" created by an "user" should be placed there ... or only those that come with the system?
This is a lot unclear even for experienced Unix users - each sysadmin defines its own rules to decide... but in the end of the day, usually every command related to the filesystem and security goes to /sbin, everything installed by the sysadmin (small utils) goes to /bin and everything else goes to /usr/bin... what is this? An attempt to put some order in the complete mess that one finds *inside* these directories? (worst than bin is the share... why the hell someone needs a directory do place sgml files? Is really needed to place ALL help files in the same directory man? (specially when their names are cryptic and there is a multitude of them for each application)... is really this the easiest way or this was just decided to allow easier searches using grep? Is really interesting adding a "/usr/share/misc : Miscellaneous architecture-independent data" directory?
I know that using "etc", "home" and "tmp" are great ideas (they are even present on nowadays eCS systems) but this do no good if not all programmers use them (via %HOME%, %ETC% and %TMP% - I am somewhat against hard-coded path names).

But hey, it gets worst! We have drive letters on OS/2. That means repeated FHS on each drive, if everything is organized this way... at least if we continue to use OS/2 the way we have always had.

I understand the reasons to use the FHS (a simplified one, for God´s sake). I even have mine on my eCS: /bin, /lib, /tmp and /var ! Small utilities and shared libraries are always placed this way. I also understand that many Unix programs have hard-coded path names and would benefit from this structure. I also have no complains that some programmers should choose to program using this file structure.
My only complain is the "all your filesystem are belong to us" approach, which is being interpreted in the following way: "if you want an installer, you´ll have to live with FHS; if you want organize your filesystem, get the ZIP... so long, and thanks for all the fish".

You have said something that made me feel uneasy: you said there are two options... the user must know what happens inside its file system (in detail) or the user do not need to know anything. This bothered me because I have always thought in OS/2 and eCS as the middle path: it is not so dumb and limited as Windows... nor complex and "powerful" as Unix.
Basically, in my PoV, OS/2 removes all things you can configure with Linux (but you never will), but keeps the system several hundreds of times more flexible than Windows. It allows one to begin working without knowing nothing (like Windows), but has a light learning curve, allowing the user discover the system internals while he is using it (without the need to read all the how-tos). This is the opposite of Linux, where you should know the reason of every bit being at /etc/init.d just to change the damn %PATH%!

Force FHS (in opposite "of allow FHS") on eCS is perceived by me as a step towards Unix complexity... the opposite direction took by Apple with OSX - which indeed implements FHS, but hides it from the user in every possible way. Do not take me wrong: I believe the path took by Apple is even worse, I do not like my system fooling me around.

I have no problem with complexity. But I have no time to it either - and I do like to know where my printer files are, so I can adjust them when the printer fails... without the need for an internet connection and spending hours reading every single how-to ever published.

My kindest regards,
Daniel Caetano

Setup & Installation / Re: RPM packager
« on: 2011.08.30, 16:13:31 »

   Will WPS integration be added to RPM/YUM? AFAIR, one of the reasons behind WarpIn creation, back in the xWP days, was the need for easy support to object creation, destruction, WPS classes registration and deregistration... which an eCS installer MUST do (this function is simply a mess and not functional under Linux due to zillions of different user interfaces and desktop configurations).

   In my POV, the directory tree for Linux is a big organized mess... that is: it must be that way to cope with multiusers and several other details available on Linux FSs, which are not available on eCS (such as refined security with a ruthless FS security control and the need to add directories "on the fly" via mount command).

   I do agree, though, that porting any Unix software and make it work with OS/2 directory tree is quite a challenge sometimes... so I kind of can cope with that messy directory tree structure in order to ease the Linux ports... but the directory tree can be greatly simplified. There is absolutely no need to cope with dozens of "usr" or "bin" directories under OS/2. Maybe it would be interesting to have a single /root directory with a simplified Unix directory tree inside of it, and ported software could just be installed there. In fact, this would really solve a messy situation we have right now: many ported programs store data on different directories (/ecs/dll, /os2/dll, /mptn/etc, /%home%/%user%/appname and so on).
Remember, however, that many tasks that can be done easily on Linux (such as creating a directory symbolic link named "FireFox" for a cryptic "/usr/bin/" to ease the access) are not available under OS/2 (which makes VERY annoying the ever changing directory names for ported applications directories, such as FireFox).

   On the other hand, I believe this should be limited to *ported* software. eCS and OS/2 native software should keep things as they have been for "centuries" now. I liked the fact eCS comes with a predefined "home" and "programs" directory. This could be extended to "Libraries" (for Shared Libraries). The programs directory is expected to have subdirectories for each program, wich will include the exe file, specific libraries, and configuration.

   From a development point of view, since RPM/YUM is so flexible, this must not be difficult and/or impossible.
   Also, I would be nice if the RPM/YUM interface could be similar to that on WarpIn and work in a similar way.


   Daniel Caetano

PS: eCS directory tree is a mess just because a different but equally hell-like directory structure was started, replicating OS2 directory with ECS name to put different things in there. Also, nothing was made to change the IBM bad habit of installing all different sort of applications in the root directory... this is just as annoying as putting everything inside /usr/bin. The TCP/IP, for instance... it has its own directory tree, on root, but it stores its configuration on /MPTN/ETC! We also have different versions of IBMGSK, the related LAN software divided into dozens of directories (IBMLAN, IBMCOM, IBMLANLK, MUGLIB...).

Setup & Installation / Re: cups and hplip
« on: 2011.08.19, 05:07:15 »
I have 2 printers. One Samsung ML-1610 work just fine.
The second HP ColorLaserJet CP1215 doesn't work.
Here is the message I got:
HP_Color_LaserJet_CP1215 "/cups/lib/cups/filter/hpcups.exe failed"
Is there anything to do to resolve this problem?


  I could not make my HP CP1515n work with CUPS... but I was able to
use the PostScript PSD available at Linux driver package and convert
it to a valid eCS PostScript driver using the "Add printer drivers" provided
with eCS 2.x.


  Daniel Caetano

Applications / Re: Java for os2
« on: 2011.06.29, 05:59:07 »
OpenJDK Ga is now available for download:

Please post any Java software you are testing on this thread.

  I was able to run NetBeans 6.9.1 on it, but can't build / run; when I try "Build and Run"
I am receiving a "Java executable not found". When trying to build (only), after some
hard disk activity, an "error icon" is shown with the following message: "Unexpected
  LPino said he was able to run NetBeans 5 with Java 1.4.1 and 1.4.2; I was not (at
least I not reliably) but never received any answer when asking for correct CMD files.

  Anyone has had a better result?


Networking / Re: eCS Samba Client (EVFS) timeout problem
« on: 2011.06.09, 04:53:24 »
Hi Ivan,

In fact, it doesn't matter if I keep EVFSGUI opened or not. After some time without use, the network drive assigned to the remote share becomes "empty" (no files/dirs shown) until I re-open EVFSGUI and re-attach it. I have never had this problem when using IBM Peer to Peer, when connections were lost only when the remote host became unavailable.
If I keep using the network drive, it works as it should. The problem seems related to long inactivity times. But if your network drivers keep working after so much time, this is good news: there is a way to make it work.... it is just a matter of "how". :)

Pages: 1 [2] 3 4 ... 14