Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!ut-sally!utah-cs!utah-gr!stride!l5comp!scotty From: scotty@l5comp.UUCP (Scott Turner) Newsgroups: comp.sys.amiga Subject: Re: Re: Wishlist for 1.3 Executive. Message-ID: <301@l5comp.UUCP> Date: Thu, 23-Jul-87 18:13:37 EDT Article-I.D.: l5comp.301 Posted: Thu Jul 23 18:13:37 1987 Date-Received: Sat, 25-Jul-87 16:40:49 EDT References: <8707220001.AA01966@cogsci.berkeley.edu> Reply-To: scotty@l5comp.UUCP (Scott Turner) Organization: L5 Computing, Edmonds, WA Lines: 138 Summary: Thoughts on shutdown command. In article <8707220001.AA01966@cogsci.berkeley.edu> bryce@COGSCI.BERKELEY.EDU (Bryce Nesbitt) writes: >I agree!!! Anything hanging off that sequence is vulnerable to corruption, >anything it does is suspect. I said that I was not debating the merits of >the idea itself, but rather poiting out how it could be done. If I was The fact that you were discussing "how to" is what raised my concern. Someone might say "Gee that sounds neat lets do it!" without understanding any flip side issues. >god-of-all-things there would be Ctrl-Amiga-Amiga and Ctrl-Amiga-Amiga-Alt. >One would be "safe" and flush all buffers. One would be dirty for use >in emergencies. A workbench menu item could verify things with the user, give What I think is needed is a shutdown command. One for the CLI and a menu item for the Workbench. Having it as a Ctrl-Amiga-Amiga-Alt (or whatever key sequence you wish to use) could lead people to try the safe reboot in places where things are really screwed up. ie if you don't have a working CLI or workbench to run a shutdown from then it might be a real good idea to not try flushing anything out to disk. :) Remember, no MMU means wild code can wack ANYTHING including data about to get flushed. >people want a "official" shutdown, turning the machine off seems crude >and dangerous to them. If they have a harddisk, I agree with them. Even with just a floppy system it's dangerous to just power off. Hackers are smart enough to know to wait 2-3 seconds for the auto-flush before doing anything drastic but most of John Q Public isn't. And the golden rule "Don't do nothin with the red drive light on" isn't a good rule either. I've seen the light go out and then the auto-flush kick in and it come back on 2-3 seconds after it went out. Hard disks just have it rougher. As an aside, it sure would be neat if the Amiga knew the difference between a floppy and a harddisk. My hard disk gets motor off commands all the time! For a system that's so flexible I don't seem to be able to say "I'll take the periodic flush calls, but please hold the motor offs, they give me gas." ;) But then again the whole motor on/off thing was a MAJOR kludge to begin with. >Also I'd define some keys to selectivly disable parts of the auto-config >process. Press CTRL-F1 and restrict yourself to 256K of CHIP ram. If >CTRL-F3 is held down then $C00000 memory is not sized, etc. More thought >is needed as to the keystrokes, but the idea has merit. What is needed is better software. I don't see why the C-A folks should put time into this to benifit those who wish to use defective software. My skyfox no longer works with my memory expanded system. I don't blame C-A or expect THEM to fix it, I blame EA. Software that doesn't allocate ram correctly is just plain BROKE, it hits the trash can around here. >Terminology... Terminology. There are a number of things on the Amiga that >have multiple names and a number of things that share a common name. YOU ARE Terminology is important though in this forum. Tons of people read it from different backgrouds and Amiga experience levels. If those of us that DO know the difference between device drivers and device handlers don't keep it straight how can we expect those that DON'T know the difference to get it straight? I know the difference and you know the difference which is what concerned me about your statement. The thought "Maybe Bryce forgot about handler caching" ran through my mind. >What the validator does is unimportant. Even if the file is left open, and >this bitmap is marked as pending... no sweat. Obviously you haven't spent alot of time waiting for the validator to run its course. On a 20 meg hard disk it's like watching glaciers form. Sure there's no permanent data loss, but it's still a royal pain plus VERY alarming to those who don't know what the hell is going on. Witness recent messages here. As a side note, I think that C-A should have the validator at least print a message saying something like "Validating disk XXXX", followed by the infamous "This may take a few minutes". :-) I hope this can be slid into 1.3, the current non-talkative validator does seem to be alarming people. >What is important is that what has already been written, but is sitting is >cache, is flushed. Care needs to be taken that the DEVICE (exec device such >as trackdisk.device) has completed writing, turned off the drive, and is >generally ready for doomesday. Catching it in the middle of a cache update I think this whole topic falls into another one of those nitty gritty details that the C-A crowd has yet to deal with. It took Apple a while to figure out the details on this feature for the Mac family as well. The problem I see is that the hooks were there from day one to shutdown a Mac, but I don't see some of the crucial hooks in the Amiga. Otherwise I'd craft a shutdown program. Having a Mac here on a daily basis has infected me with the desire to have a real shutdown rather than risk my patience at 03:00. It's very comforting to know that if I yank restart or shutdown on the Mac everything will get flushed/shutdown A-OK. >If there was a better programmers definition of ALL the dos packets, there would >be a better chance that you could cause a HANDLER to do the right_stuff before >a forced powerdown. ACTION_FLUSH is documented, but whats that ACTION_DIE >packet meant for anyway? Even "nothing" would be reassuring to those of >use writing handlers. Nothing is what the ram disk does for ACTION_DIE. The best dox I have on dog packets was gleaned from ripping ram-handler apart. But even it doesn't handle some packets that I know the disk handler handles (Like add cache). This has been one of things I've been curious about under the new developer's program. No one replied to my query regarding the new program so I can still only guess. But it seems that they get the same dox that we've always gotten. And sure you can save a few bux on hardware but with Amiga dealers as scarce as they are doesn't it make sense to prop the local ones up? Given the choice of buying my goodies from C-A or my local dealer I'd pick my local dealer. They're nice folks and I'd like to see them stay in the business, even if only so they can sell my commercial products. :) And when it comes to time for service it sure feels good to be able to say "YES!" when they ask if you bought the machine from them. Every dealer I know has a "They bought it here" program in their service departments. If two machines need the last disk drive in stock, the machine bought from that store is going to get it over a developer machine bought from C-A. I think C-A's current program of not documenting the COMPLETE set of ACTION packets is going to just cause more trouble down stream. People are already starting to write more and more handlers. I'm about to write a HUGE handler, Arthur a whole new file system, and as these handlers start catching on it'll be damn hard for C-A to pop up and say "Well now we're going to document those packets and by the way you've all be using them the wrong way!" >Note to scott on scottdisk.device. You mentioned bad documentation... >well what better documentation than source code, and that's in the Rom Kernal >Manual. Or perhaphs your troubles related to trackdisk-type devices?? >Otherwise the sample source works just fine with a little tweaking and >not much adding... The RKM's driver is missing tons of stuff for those that wish to do a disk driver. It's also missing crucial code concepts for those that wish to do serial or parallel devices. It's great if all you want is yet another ram disk. Also, people like to say source code is great dox. It just isn't so. Working source code just shows you how to make something work as it does. It very often doesn't tell you how to make tweak A or tweak B or don't do this because the machine will vaporize. "DEMO SOURCE" is even worse because it doesn't even work. You always have that nagging doubt in the back of your mind, when your code based on the demo code doesn't work, as to wether it's your code or the code in the demo that's screwed. Source code is to documentation as pictures are to a text book. PERIOD. A picture in a text book is not entirely useless without text to describe it but it's not nearly as useful. Same goes for source code and documentation. Scott Turner -- UUCP-stick: stride!l5comp!scotty | If you want to injure my goldfish just make UUCP-auto: scotty@l5comp.UUCP | sure I don't run up a vet bill. GEnie: JST | "The bombs drop in 5 minutes" R. Reagan Disclaimer? I own L5 Computing. Isn't that enough?