|
On 07/25/2011 01:52 PM, Thorsten Alteholz wrote: [KSB2] I am glad to answer them! Sometimes answering questions forces me to think about why we do what we do. [KSB2] Historically, GT.M was installed as owned by user and group bin. Over the years (GT.M first went into production in 1986) and over the POSIX platforms to which it has been ported (including GNU/Linux, proprietary UNIXes and z/OS), there is no single standard user and group id that the standard installation script (configure) can use (not all platforms have root, and not all platforms have 0 as the super user). To keep our maintenance costs low, we aim for maximum code commonality across the platforms. The gtmstart, gtmstop, gtcm* scripts have not been touched in a long time. While they should probably be looked at, we will probably not do much with them for the sake of maintaining compatibility with existing applications. Meanwhile, we are creating new alternative scripts. For example, the gtminstall, gtmprofile and gtm scripts are all new. The scripts in the encryption plugin are new. That is an evolutionary direction. I would be very interested in what you think of them. Nobody creates their own userid for GT.M. Occasionally some high security production sites may restrict the execution of GT.M to a group, under the philosophy of minimizing what the system can do to only that which is required. For Linux, root.root is preferred and bin.bin is acceptable. Also, the norm should be to allow world execution of GT.M.
[KSB2] I don't understand the part about calling the configure script twice. Even though they are compiled from the same source code, the 32- and 64-bit binaries of GT.M are different and packaged & installed separately. I can think of several reasons to keep 32-bit GT.M binaries on a 64-bit Linux. A proprietary library required by an application may be available in only in a 32-bit flavor. The 32-bit object code being smaller probably starts up slightly faster in CGI scripts for web applications. If a GT.M environment is located on a server for distribution to other machines, it may make sense to keep it 32-bits for greater flexibility. I keep both versions on my laptop for testing purposes, and because I create VistA+GT.M packages for distribution. [KSB2] When porting GT.M to a new architecture, as a one-of step, we run the bootstrap on another platform and move the files to the target platform. Once we have that first GT.M build on a platform, we can use it. It's not that different from cross-compiling gcc with gcc until you get that first gcc on a platform. Why do you say that you don't expect anyone to run GT.M on arm? Considering the small footprint of GT.M on disk, considering its ability to scale to TB databases, I would say that the arm architecture and GT.M are ready for each other - we just need to find someone willing to do (or fund) a port. I know of cash registers and restaurant point of sale systems that run GT.M on x86 - arm is a great fit for the future. There are existing GT.M implementations for GNU/Linux on ia64 and s390x, but they are currently not released under a FOSS license. The subject is periodically discussed internally, but so far we do not have a decision to release them as FOSS. [KSB2] Someone installing a new version would choose the latest release. But we have users who distribute applications on top of GT.M. They may have a periodic repackage / release cycle, and if they are running stably, there is less work for them to do to continue using an existing GT.M version until their next cycle. I realize that one thing may not be clear - although we tend to call them GT.M versions, in practice, the upward compatibility means that GT.M in the terminology of other packages is more like a single version with a series of releases. In that sense, we have had one GT.M version and 23 releases over 5 years. [KSB2] As discussed above, we may just leave the old scripts as-is and create a set of alternative scripts. We have not done that for the GT.CM scripts. [KSB2] I would not say that we deny other UTF8 locales - GT.M is used in many countries with other locales. But our development environment is US-centric, and we all have en_US.utf8 on our workstations. So, we probably default to en_US.utf8 for locales. I was not aware that configure requires it (I have not read that bit personally) - it may just be that it requires a UTF8 locale to compile the utility programs, and en_US.utf8 is the safest one to assume / default to. This is probably the result of a historical accident - IT is / was dominated by US companies - but we are where we are because of history. If GT.M is unfriendly to other UTF-8 locales, I definitelyt want to know so that we can fix it. If GT.M requires en_US.utf8 that may be unfriendly, and we'll consider what we can do about it. Where GT.M uses en_US.utf8 as a default, it will continue. Regards -- Bhaskar -- GT.M - Rock solid. Lightning fast. Secure. No compromises.
_____________
The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _____________ |