rxcob@minyos.xx.rmit.oz (Owen Baker) (10/11/90)
As I wrote the utilities that are being commented on here I felt I should respond to some of them to at least give another view. I hope no one is offended and I welcome further comments: >ts@uwasa.fi (Timo Salmi) writes: >I have taken a slightly closer look at some of the wares distributed >in the binaries, admittedly partly because I have written and >distributed a similar programs myself in a couple of instances. >Here are some of my observations on four programs all by the same >author. Perhaps I'm too harsh, but in my opinion (with one >exception) they fail to reach a fair quality limit for >comp.binaries.ibm.pc. Hmmmmmmm, I am not really sure what you mean by "fair quality limit". Maybe you should give us some guidelines? As regards the relability of programs I could not agree more but as to the "usefullness" I feel that is up to the end users. I can only say that I have had many postive responses as well as negative about the programs. >ALARM > A simple, but useful TSR alarm to remind the user at times >prerecorded in a text file. Slightly inaccurate, because wakes up >only once in a minute. When I set two alarms go off at minute >intervals, I only got one, but might have made a mistake in my >experiment. One of the nice features is that alarm can remove >itself from the memory. I would rate this definitely useful. Yes it does only wake up once a minute and I would be surprised if anyone needs an alarm more accurate than that or if their system clock is that set that precisely! I chose also to wake it up once a minute to avoid unnecessary interuptions to the system every few seconds. The program does work at one minute intervals so try the experiment again and if it still does not work please mail me and I will look into it. >CHECKTD > Is one of many potential a batch enhancer commands. It returns an >errorlevel to make a comparison whether we are at, before, or past >a given date/time. This is potentially useful as a part of a batch >package. But distributed as a standalone program I fail to see any >merit in it. Sorry I dont agree, what is wrong with it as a standalone program? The advantages as I see it are that it is quick to load being so small and can be included in a standard DOS batch file without the need to use a batch enhancer. I have steered away from the batch enhancer programs becuase most of them load on top of DOS's own command processor which reduces the available memory, and in some environments (such as networking) they run fowl of login programs and other non-standard DOS operations. >CURSOR > Can be used to change the cursor size and location, or hide the >cursor temporarily (that is it is not a TSR). I've written the same >utility to work with the additional TSR and size-selection options >myself. It is in my /pc/ts/tsutld18.arc package that was recently >distributed in the binaries and is also available from >chyde.uwasa.fi. Yes, I have tried your program and its very good but I do not always want TSR's loaded for various reasons. I also like to be able to unload them without resorting to rebooting or MARK and RELEASE and I was unable to find a way to do this quickly. ENCRYPT > Here is yet another program with a great number of precedents >including mine in /pc/ts/tsfcom23.arc. I can't find anything novel >in this new addition to the bunch. >It is always nice to have new programs available, but I would >definitely have tied these utilities together in a single package. >With the positive the exception of ALARM the utilities are either >far too trivial or too common to warrant a separate distribution. >These programs are simply not yet up to what shareware is about. >But this is just my opinion. As previously stated I (any many others I know) do not like batch enhancers or one program that "tries" to do it all. I see nothing at all wrong with "little" programs other than if you use lots of them then you have to wait a little longer perhaps for them to load. If its against the norm for c.p.i.b. then fair enough. BUT I appreciate your opinion, it's nice to get some constructive feedback for a change, thanks. +-------------------------------+-------------------------------------------+ | Owen Baker | Communication Services Unit | | rxcob@minyos.xx.rmit.oz.au | RMIT - Victoria University of Technology | | (61) (3) 660-2038 | Melbourne, Victoria, Australia | +-------------------------------+-------------------------------------------+
ts@uwasa.fi (Timo Salmi) (10/12/90)
In article <5996@minyos.xx.rmit.oz> rxcob@minyos.xx.rmit.oz (Owen Baker) writes: >As I wrote the utilities that are being commented on here I felt I should >respond to some of them to at least give another view. I hope no one is Since this may have some general interest, I'll post instead of emailing. >>ts@uwasa.fi (Timo Salmi) writes: >>author. Perhaps I'm too harsh, but in my opinion (with one >>exception) they fail to reach a fair quality limit for >>comp.binaries.ibm.pc. > >Hmmmmmmm, I am not really sure what you mean by "fair quality limit". >Maybe you should give us some guidelines? As regards the relability of >programs I could not agree more but as to the "usefullness" I feel that is up >to the end users. I can only say that I have had many postive responses Very difficult. This is where a moderator's judgement (AND time) is needed. The binaries are, of course, up to Bill, but at chyde.uwasa.fi submissions (those which I moderate) I look at the user interface, documentation, the program's principal task and how the program achieves it, and a very subjective feel of general usefulness. It's a little like refereeing a scientific journal, but much much more subjective. I cannot give any strict quantitative guidelines. > >>CHECKTD : >Sorry I dont agree, what is wrong with it as a standalone program? The >advantages as I see it are that it is quick to load being so small and Here may have a misunderstanding. There is nothing wrong with a standalone program per se. Rather it is the distribution of such a standalone program separately, which obviously would be better at home in a collection of similar utilities. This one was (in my opinion) too trivial for separate distribution. Some users were obviously also peeved (to use your verb) about the shareware idea for a program that can be written in "ten minutes" (to quote one email) by anyone with a fair MsDos programming background. >>CURSOR : > >Yes, I have tried your program and its very good but I do not always want >TSR's loaded for various reasons. I also like to be able to unload them >without resorting to rebooting or MARK and RELEASE and I was unable to find >a way to do this quickly. This doesn't concern your programs, but mine. I'll comment anyway. Here you obviously failed to notice that the package /pc/ts/tsutld18.arc also contains a nonresident version of cursor adjustment. >BUT I appreciate your opinion, it's nice to get some constructive feedback >for a change, thanks. I am very pleased to see that you take it this way. And my purpose was trying to be constructive, both from the point of the binary postings, and yours. Invective never gets us anywhere, anyway. ................................................................... Prof. Timo Salmi (Moderating at anon. ftp site 128.214.12.3) School of Business Studies, University of Vaasa, SF-65101, Finland Internet: ts@chyde.uwasa.fi Funet: gado::salmi Bitnet: salmi@finfun
emv@math.lsa.umich.edu (Edward Vielmetti) (10/13/90)
In article <1990Oct12.105211.21451@uwasa.fi> ts@uwasa.fi (Timo Salmi) writes:
Very difficult. This is where a moderator's judgement (AND time) is
needed. The binaries are, of course, up to Bill, but at
chyde.uwasa.fi submissions (those which I moderate) I look at the
user interface, documentation, the program's principal task and how
the program achieves it, and a very subjective feel of general
usefulness. It's a little like refereeing a scientific journal, but
much much more subjective. I cannot give any strict quantitative
guidelines.
In general there are many more programs which accomplish a given task
than one would need. In an extreme example I recall going through an
entire disk full of programs which would change the color of the
screen. This is clearly many more that you would want to keep around
in any sort of selective archive.
When I was organizing the collection on um.cc.umich.edu (now on
msdos.archive.umich.edu) back in the days before the collection had
internet FTP access and a hierarchical file system, it was imperative to
get rid of old programs as much as it was to bring new ones in. From
five different fast disk copiers, you would test them all, and maybe
keep two on line. And if a radically better one came along, you might
drop those two and keep only the one.
Software changes quickly. Timo, perhaps you could say, but the useful
half life of a piece of software is under a year before a new version is
expected or a better program is found to accomplish the same task.
Comments by mail, or put the word "ftp" in the article (I ignore
the rest...)
--Ed
Edward Vielmetti, U of Michigan math dept <emv@math.lsa.umich.edu>
moderator, comp.archives
formerly organizer of um.cc.umich.edu PC1:
after 1 November <emv@ox.com>