Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!think.com!spool.mu.edu!samsung!zaphod.mps.ohio-state.edu!usc!ucla-cs!math.ucla.edu!pico!barry From: barry@pico.math.ucla.edu (Barry Merriman) Newsgroups: comp.sys.next Subject: Re: Novel Software Distribution Ideas Message-ID: <1045@kaos.MATH.UCLA.EDU> Date: 5 Feb 91 20:07:07 GMT References: <1037@kaos.MATH.UCLA.EDU> <8847@hub.ucsb.edu> <1991Feb5.084512.26648@Neon.Stanford.EDU> Sender: news@MATH.UCLA.EDU Organization: UCLA Dept. of Math, UCLA Inst. for Fusion and Plasma Research Lines: 80 In article <1991Feb5.084512.26648@Neon.Stanford.EDU> zimmer@calvin.stanford.edu (Andrew Zimmerman) writes: > >I really don't consider that [meter runs out at worst possible time] >a flaw, I consider that to be stupidity >on the part of the user. :-) >there are some flaws to it. > > Flaw 1. Lets say the timer runs out. What is to prevent me from >finding that 'dump' I did when the timer still had a lot of time left >on it? And you can't tie it to the date on the system, ie the software >fails after, oh lets say one month. As I said, some OS hooks might be required: Here's one quick scenario. The OS has a central ``time clock'' that provides metering services to metered Apps (i.e. those with a meter object inserted via the Interface Builder). When the meter object is dropped into an app, it can take with it a randomly generated ID#. At run time, it will ``punch-in'' with the central time clock with this ID #. The central clock keeps the apps onboard meter updated, and requires consistency between its records and the apps on board records, to avoid any machine switching tricks. The central clock could run across NetInfo nets, so that apps are properly metered across networks (instead of the luddite practice of tying apps to CPUs). The only ways around this sort of setup involve an evil superuser who carries around spare copies of the fresh app _and_ OS, and is willing to replace his OS to squeeze more use from his spent apps. Since this is a pretty small fraction of all users, I think the scheme could be of practical use. > > I do like the idea of software testing though, and I hope that >software people do make demo versions of their software. I agree---this is a crude approximation to the metering scheme (with two prices on the meter: full and free). But it is currently not done uniformly, and requires special programming on the part of each vendor. NeXT schould provide tools to add this to software with no effort, and in a consistent manner. >I also really appreciate what Diagram is >going to be doing for students (of course the students have to convenience >their bookstores to participate in such a program.) Yes---big problem here. For example, ay UCLA we won't get the low prices because the local authorities won't pay the site license fee. So you see, their approach to pricing---though progressive and well intentioned---doesn't work. Net result: very few, if any, copies of diagram will sell to UCLA people. (Though some pirated ones will show up, no doubt). > The best policy though, is to deal with a good store (or friends) that >will let you test software. (After borrowing a copy of Windows 3.0 from >a friend, I thought it was worth the price of $70-$80.) No, this doesn't solve the problem. For one, NeXT software will never be discounted as much as PC software, because the installed base will be an order of magnitude smaller for the foreseeable future. But more to the point: there is lots of software that I would use, _but not enough to justify the full price_. For example, the excellent kerning software TouchType. I could use it, but only a couple times per year, max. Its not critical for my work or play. So even though it is of the highest quality, I simply can't pay the _full_ price on economic grounds. So what should I do? Pirate it? Maybe, but how can I even find someone who has such an esoteric piece of software in the _personal possesion_? If I could pay $30 for a limited use version, I would. >zimmer@calvin.stanford.edu -- Barry Merriman UCLA Dept. of Math UCLA Inst. for Fusion and Plasma Research barry@math.ucla.edu (Internet)