From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Sun, 1 Sep 2002 04:36:54 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 315 ************************************************** Saturday 31 August 2002 Number 315 ************************************************** Subjects for today 1 Re: FHS : Thomas Dickey 2 Re: FHS : Stefan Neis 3 Re: FHS : Stefan Neis 4 Re: Some packages : Stefan Neis 5 Re: Some packages : Andreas Buening 6 Re: FHS : Andreas Buening 7 Re: Linux setup newbie Q : Stefan Neis 8 Re: Some packages : Stefan Neis 9 Re: FHS : Stefan Neis 10 Re: Linux setup newbie Q : John Poltorak 11 Re: Some packages : Andreas Buening 12 Linux setup newbie Q : Voytek Eymont **= Email 1 ==========================** Date: Sun, 1 Sep 2002 11:10:46 -0400 From: Thomas Dickey Subject: Re: FHS On Sun, Sep 01, 2002 at 03:48:32PM +0200, Andreas Buening wrote: > Stefan Neis wrote: > > > > On Sat, 31 Aug 2002, John Poltorak wrote: > > > > > > tools have to be found because they'll be hardcoded in lots of > > > > scripts like #!/somewhere/perl. > > > > > > I would put perl.exe in /usr/bin and the rest of the perl distribution in > > > /usr/lib/perl. > > > > The big question IMHO is: what do existing perl scripts expect (e.g. > > latex2html)? They usually have the famous "#!/somewhere/perl" and if it > > isn't there, you have to manually "fix" it. > > My impression is that most scripts use "#!/usr/local/bin/foo". > > > > Whether it's /usr/bin/perl or /usr/local/bin/perl typically depends on > > whether or not it's included in the distribution, so for Linux, there's > > always /usr/bin/perl, for Solaris (at least newer versions) there's > > /usr/bin/perl (typically some older version, current versions might be > > installed somewhere else, e.g. /usr/local/bin/perl), don't know about > > others. > > AIX and IRIX seem to have /usr/local/bin/perl and a symbolic link > in /usr/bin. SGI's freeware packages don't go under /usr/local/bin, nor does Sun's. (configure scripts tend to put it there, but that's a different matter) It's likely that a symbolic link in /usr/bin to /usr/local/bin reflects a local modification rather than a widespread policy. -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net **= Email 2 ==========================** Date: Sun, 1 Sep 2002 11:45:28 +0200 (CEST) From: Stefan Neis Subject: Re: FHS On Sat, 31 Aug 2002, Andreas Buening wrote: > The question is what's usual? On most Unix systems shell > utilities like perl (and also awk, bash, tcsh) seem to be in > /usr/local/bin. We have to define once and forever where these > tools have to be found because they'll be hardcoded in lots of > scripts like #!/somewhere/perl. > > Btw. what do you think about docs in /usr/share/{man|info} > (FHS compliant, but requires > ./configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/man > for _all_ packages.) > versus /usr/{man|info} (not FHS compliant but we can drop two > extra configure options)? I like the /usr/share/{something} semantics: You can put /usr/share on its own partition and use it from every OS - and via NFS/SMB even from all machines in your local network, no matter whether it's a Sparc or Intel or something else. Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 3 ==========================** Date: Sun, 1 Sep 2002 11:58:17 +0200 (CEST) From: Stefan Neis Subject: Re: FHS On Sat, 31 Aug 2002, John Poltorak wrote: > > tools have to be found because they'll be hardcoded in lots of > > scripts like #!/somewhere/perl. > > I would put perl.exe in /usr/bin and the rest of the perl distribution in > /usr/lib/perl. The big question IMHO is: what do existing perl scripts expect (e.g. latex2html)? They usually have the famous "#!/somewhere/perl" and if it isn't there, you have to manually "fix" it. Whether it's /usr/bin/perl or /usr/local/bin/perl typically depends on whether or not it's included in the distribution, so for Linux, there's always /usr/bin/perl, for Solaris (at least newer versions) there's /usr/bin/perl (typically some older version, current versions might be installed somewhere else, e.g. /usr/local/bin/perl), don't know about others. The "problem" (for us) is, that on Unix it doesn't really matter as you can always add a link to point all scripts to the right location when they are searching for "/somewhere/perl", so nobody really cares... :-( Regards, Stefan P.S.: If we are willing to depend on Linux distribution instead of getting perl scripts immediately from authors/home pages/ whatever, /usr/bin/perl should be a safe choice as Linux distributors seem to always "fix" the scripts accordingly. -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 4 ==========================** Date: Sun, 1 Sep 2002 12:04:25 +0200 (CEST) From: Stefan Neis Subject: Re: Some packages On Sat, 31 Aug 2002, Andreas Buening wrote: > 1. gettext. I think we'll need two packages of it: One "normal" > > 2. iconv. Do we want to use Andrew Zabolotny's iconv that is I like your suggestions. > 3. The libc. Where do we want to put libc extensions like > GNU regex (or GNU glob)? Giving each of them their own > dll provides just chaos. They should either go directly > into the libc (i.e. emx) or go into one single additional > dll (e.g. ux2.dll). Why not link statically against POSIX/2's cExt.a for now and then switch over to linking against ux2.dll once it's ready? After all, we aren't talking about several MB per executable which could be saved by investing quite some work in those temporary DLLs. If you need additional GNU specific extensions, I'd suggest to link statically for now and integrate them into ux2.dll later. Regards, Stefan **= Email 5 ==========================** Date: Sun, 01 Sep 2002 15:48:14 +0200 From: Andreas Buening Subject: Re: Some packages Stefan Neis wrote: > > On Sat, 31 Aug 2002, Andreas Buening wrote: [snip] > > 3. The libc. Where do we want to put libc extensions like > > GNU regex (or GNU glob)? Giving each of them their own > > dll provides just chaos. They should either go directly > > into the libc (i.e. emx) or go into one single additional > > dll (e.g. ux2.dll). > > Why not link statically against POSIX/2's cExt.a for now and > then switch over to linking against ux2.dll once it's ready? > After all, we aren't talking about several MB per executable > which could be saved by investing quite some work in those > temporary DLLs. > If you need additional GNU specific extensions, I'd suggest > to link statically for now and integrate them into ux2.dll > later. I don't like the idea of polluting the ux2 tree by several "to be removed" dlls (or .a libs) or even compiler version dependent dlls (gcc?????.dll). Let's start from a clean and empty tree. If we think we'll need GNU blurb let's put that lib into ux2, if we think we'll need Posix foo(), let's grab that code from posix/2 or write a new implementation for foo() from scratch (if necessary) and put it into ux2. Of course, this implies that that this lib will be updated often, but I don't expect we'll get more than a monthly or even weekly update. If you have to update your system it's better to update only one system library instead of one of dozen mini libraries. Furthermore it's hard to keep track of which tool uses which GNU extension, using flags like LIBS="-lregex -lglob -lblurb -lgcc" is much harder to memorize than once and forever LIBS="-lux2 -lgcc". If I remember correctly you were a member of that Posix/2 group. Please, could you take over the maintainance of the ux2.dll because you might know better than most of us whether there already exist a certain Posix function foo() and where to find its code if we need foo() for a package. Another thing I've just recognized: All packages have to be compiled using the same emx version, otherwise some programs will display those nice warnings like "this program requires emx 0.9d". bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie. **= Email 6 ==========================** Date: Sun, 01 Sep 2002 15:48:32 +0200 From: Andreas Buening Subject: Re: FHS Stefan Neis wrote: > > On Sat, 31 Aug 2002, John Poltorak wrote: > > > > tools have to be found because they'll be hardcoded in lots of > > > scripts like #!/somewhere/perl. > > > > I would put perl.exe in /usr/bin and the rest of the perl distribution in > > /usr/lib/perl. > > The big question IMHO is: what do existing perl scripts expect (e.g. > latex2html)? They usually have the famous "#!/somewhere/perl" and if it > isn't there, you have to manually "fix" it. My impression is that most scripts use "#!/usr/local/bin/foo". > Whether it's /usr/bin/perl or /usr/local/bin/perl typically depends on > whether or not it's included in the distribution, so for Linux, there's > always /usr/bin/perl, for Solaris (at least newer versions) there's > /usr/bin/perl (typically some older version, current versions might be > installed somewhere else, e.g. /usr/local/bin/perl), don't know about > others. AIX and IRIX seem to have /usr/local/bin/perl and a symbolic link in /usr/bin. [snip] > P.S.: If we are willing to depend on Linux distribution instead of > getting perl scripts immediately from authors/home pages/ > whatever, /usr/bin/perl should be a safe choice as Linux > distributors seem to always "fix" the scripts accordingly. So you want to trust on Linux distributors? ;-) And what about bash and ksh? Also into /usr/bin? bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie. **= Email 7 ==========================** Date: Sun, 1 Sep 2002 17:38:12 +0200 (CEST) From: Stefan Neis Subject: Re: Linux setup newbie Q [ Sorry for the off-topic post, but a quick answer might be the best way to get rid of this thread... ] On Sun, 1 Sep 2002, Voytek Eymont wrote: > I've just installed RedHat 7.1/7.3; You got the wrong list, UnixOS2 is about porting Unix software to OS/2, _not_ about configuring Linux systems. > where do I set a Linux system to 'REIPL ON' ? You don't. > where do I alter default desktop fron gnome to kde ? Don't know, how that works on redhat... > where do I alter default logon from X to command line ? You change the standard runlevel from 5 to 3 in /etc/inittab. > mounting HPFS drives: what are limitations on it ? Don't know exactly. It works nicely for me, but due to Windows' limitations, I don't export HPFS partitions that are larger than 2GB to other operating systems. AFAIK, Linux doesn't have such restrictions. > I attempted to mount using man mount syntax, but, it told me I was 'out of > resources', sorry, don't have corrrect error message right here The directory indicating the mount point needs to exist, e.g. if you want to mount some partition as /os2/c and either directory /os2 or directory /os2/c doesn't exist (yet), it will fail. No idea if that's the source of your problem, but it might be. > where do I set aliased IP addresses ?, I'd like to add a few IP addresses to it No idea, this really looks more like a question for some linux/RedHat support group. Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 8 ==========================** Date: Sun, 1 Sep 2002 17:50:13 +0200 (CEST) From: Stefan Neis Subject: Re: Some packages On Sun, 1 Sep 2002, Andreas Buening wrote: > update. If you have to update your system it's better to > update only one system library instead of one of dozen mini > libraries. Agreed. But for the immediate future, I'd suggest to link statically against the version included in the GNUwhatever package you're compiling. 1 more minute (or less) of compile time and 20K larger executables shouldn't be a problem. > than once and forever LIBS="-lux2 -lgcc". Which the compiler should automatically append anyway, once there is an established distribution. > If I remember correctly you were a member of that Posix/2 > group. Exact. > Please, could you take over the maintainance of the > ux2.dll because you might know better than most of us whether > there already exist a certain Posix function foo() and where > to find its code if we need foo() for a package. AFAIK, Holger is creating ux2.dll(1), so what's the point in starting a concurring, incompatible version? Let's wait for some base version and then maybe add to it as needed - or even create an additional library with GNU extensions, e.g. GNU.dll as mixing BSD based libc with GNU specific C library extensions might be a bad idea for licence reasons... > Another thing I've just recognized: All packages have to be > compiled using the same emx version, otherwise some programs > will display those nice warnings like "this program requires > emx 0.9d". Well, you can't run programs compiled with newer EMX versions with the older DLL's, in the other direction it should (mostly) work - there are some strange exceptions, though. Anyway, why would anyone use any older emx version? Regards, Stefan (1) IIRC, the main problem is that providing unix base functionality (e.g. efficient fork) requires some very low level interaction with the kernel, so developping/testing/debugging just _needs_ time. Don't push too hard, or we will end up with a driver providing Windows-like system stability under OS/2. ;-) **= Email 9 ==========================** Date: Sun, 1 Sep 2002 17:55:07 +0200 (CEST) From: Stefan Neis Subject: Re: FHS On Sun, 1 Sep 2002, Andreas Buening wrote: > My impression is that most scripts use "#!/usr/local/bin/foo". Same impression here, unless we are reusing the linux-ified versions. > So you want to trust on Linux distributors? ;-) For lack of better alternatives: yes. They are trying (more or less) hard to provide packages that work with each other and add modifications as needed for interoperability. Why should we aim at redoing this work, especially, if there are much more people working/testing on Linux distribution (and being paid for it). That way, running the newest version of some software might be somewhat harder than it would be if we did everything from scratch, but in view of available man power, I suppose we can get newer version on average by following some Linux distribution's lead. Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 10 ==========================** Date: Sun, 1 Sep 2002 19:24:33 +0100 From: John Poltorak Subject: Re: Linux setup newbie Q On Sun, Sep 01, 2002 at 05:38:12PM +0200, Stefan Neis wrote: > [ Sorry for the off-topic post, but a quick answer might be the > best way to get rid of this thread... ] > > On Sun, 1 Sep 2002, Voytek Eymont wrote: > > > I've just installed RedHat 7.1/7.3; > > You got the wrong list, UnixOS2 is about porting Unix software to OS/2, > _not_ about configuring Linux systems. It's actually more than that, it help with learning how to use Unix-like commands and utils, but in an OS/2 environment. Many of the apps which come with Red Hat are available on OS/2, and we'd like to get as many of them as possible to work on OS/2. In essence, Red Hat is a collection of apps hosted on a Linux kernel. What we want to do is to use the OS/2 kernel as the host for the same apps. This would mean you can keep running OS/2 but have a whole lot of additional software available, so you don't need to mess about with any migration. > Regards, > Stefan > -- > Micro$oft is not an answer. It is a question. The answer is 'no'. > -- John **= Email 11 ==========================** Date: Sun, 01 Sep 2002 21:36:28 +0200 From: Andreas Buening Subject: Re: Some packages Stefan Neis wrote: > > On Sun, 1 Sep 2002, Andreas Buening wrote: > > > update. If you have to update your system it's better to > > update only one system library instead of one of dozen mini > > libraries. > > Agreed. But for the immediate future, I'd suggest to > link statically against the version included in the GNUwhatever > package you're compiling. 1 more minute (or less) of compile time > and 20K larger executables shouldn't be a problem. The problem isn't just the 20K per executable. What is missing is a rule which libraries we have, which libraries have to provide what, which libraries are optional, how these libraries have to be compiled and so on. Putting all GNU extensions into one library takes about 5 min. Creating a Makefile or a reasonable configure script takes much longer but this isn't really a problem. It becomes a problem as soon as it's unclear how to handle those extensions. If one uses -lregex, the next -lux2, the third -lposix and the last one -lgnu then we have a problem because we have chaos. If you say we don't have and don't use those extensions, fine. Then we'll have some larger executables but this won't really hurt us. I propose to use those extensions, put all of them into one lib ux2 and just use -lux2 for every package we have. If we can achieve some optimization for basically nothing let's do it. This won't interfere with Holger's lib because his BSD lib won't contain any of those GNU extensions. The real problems are all those posix functions that are not part of emx. I'm not talking about starting a concurrent development or reimplementing the wheel (fork). If we add a package that requires foo() to UnixOS/2 why not adding an existing uname() implementation? Is it better to put #ifdef __EMX__ into all source files? A lot of the Posix functions e.g. uname() don't require to hack the OS/2 kernel. > > than once and forever LIBS="-lux2 -lgcc". > > Which the compiler should automatically append anyway, once there is > an established distribution. We are far away from it. [snip] > > Please, could you take over the maintainance of the > > ux2.dll because you might know better than most of us whether > > there already exist a certain Posix function foo() and where > > to find its code if we need foo() for a package. > > AFAIK, Holger is creating ux2.dll(1), so what's the point in starting > a concurring, incompatible version? Let's wait for some base version > and then maybe add to it as needed - or even create an additional > library with GNU extensions, e.g. GNU.dll as mixing BSD based libc > with GNU specific C library extensions might be a bad idea for > licence reasons... One of the reasons why Linux is that successful is because of the philosophy "if there is a problem fix it". If a function /option is missing somebody adds this feature. End of story. There is no "oh, we cannot add that function because a) it has never been here or b) we have to reinvent the wheel first". Functions like uname() don't need anything else. They don't rely on any other fancy Posix functions, they may be implemented using Standard C and OS/2 API only. You could just add those functions to the emx dlls without hurting the backward compatibility. So why don't we do it? Why do we have to wait until Holger has reinvented fork()? [snip] bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie. **= Email 12 ==========================** Date: Sun, 1 Sep 2002 23:44:01 From: Voytek Eymont Subject: Linux setup newbie Q I've just installed RedHat 7.1/7.3; where do I set a Linux system to 'REIPL ON' ? where do I alter default desktop fron gnome to kde ? where do I alter default logon from X to command line ? mounting HPFS drives: what are limitations on it ? I attempted to mount using man mount syntax, but, it told me I was 'out of resources', sorry, don't have corrrect error message right here where do I set aliased IP addresses ?, I'd like to add a few IP addresses to it thanks, Voytek Eymont SBT Information Systems Pty Ltd http://www.sbt.net.au/links/ phone +61-2 9310-1144 fax +61-2 9310-1118