On 07/25/2011 01:52 PM, Thorsten Alteholz wrote: > > Hi Bhaskar, > > sorry that I have so much questions, but I really want to understand your > philosophy. I copied paragraphs from some of your latest mails and put my > question/comment below: > [KSB2] I am glad to answer them! Sometimes answering questions forces me to think about why we do what we do. > > > > [KSB] I am not sure what you mean by "what other people choose". > > (...) > > So, there is no special GT.M user. Period. > > I understand your statement, but on the other side there is your configure > script. > You added some code to input different userid and groupid. So there must > be at least somebody who wanted to have such feature. Further there are > your $rscripts (gtmstart gtmstop gtcm_run gtcm_slist) that always belong > to root independent of your input. > I might be a bit annoying, but I am full of curiosity why you implemented > it this way and for example don't always give ownership to root or any > other uid 0. > By my original question I just wanted to know whether other people keep > the default or create their own user/group although that is not > necessarily needed. > [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. > > > One wrinkle is that it is possible for users to have 32- and 64-bit > > versions of GT.M to exist on the same system. So, the recommended > > practice is to put _x86 or _x86_64 in the directory name under > > /usr/lib/fis-gtm. Here is a listing from my laptop: > > Hmm, is there any good reason why someone wants to have both versions > on a 64-bit processor? I have no problem to call the configure script > twice, but if nobody has any need for it, we could save some CPU cylces > on the buildd. > [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. > > > It > > would also be good to have a way select the preferred GT.M version > > (defaulting to the latest) through /etc/alternatives. > > Yes, that is a good idea. > > > > > > [KSB] If we can get GT.M into the repositories using the existing MUMPS > > bootstrap, that will probably be less work than completing the Python > > scripts. > > But the existing bootstrap is only available for i386 and amd64. > Although I don't expect anybody to run GT.M on arm, there are other Debian > architectures being very appropriate for GT.M. Especially s390 seems to be > a good candidate, right? > [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. > > > > [KSB] I am not sure where you get the idea of hundreds of releases. > > Sometimes I exaggerate a bit :-). > > > Our > > history over the last five years is that one series of releases went to > > D. A couple went to B. Three went to A. The rest stopped at the base. > > I just did a quick eyeball check - we have had 23 releases of GT.M over > > five years. > > Ok, even this seems to be quite a number. I guess currently the package > with the most versions is python (?) with about 4 versions in any > Debian release. > I understand that someone wants to install a special version that for > example has been certified by somebody. But why does one want to install a > B-version if there is a C-version available? As this is "only" a patch > version, everybody should spring at that version immediately!? With all > your tests you do before release, there should be no problem with an > upgrade. > [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. > > > There are scripts gtcm_server and gtmstart in which $logdir is set to > $gtm_dist/log. Do you plan to separate $logdir from $gtm_dist in some > future version? In Debian binaries and logfiles should not be in the same > directory. > [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. > > > Further, in your configure script you explicitly test for en_US.UTF8. Is > there any reason to deny all other UTF8 locales? > [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. _____________
