[Coco] looking for latest toolshed location

[Gene Heskett]

On Friday 29 November 2019 18:34:55 Robert Gault wrote:

> That 4.4.4e was a typo on my part. I meant 4.3.4e. In any case, at
> https://sourceforge.net/projects/drivewireserver/files/
> it says that "Linux and *BSD users can double click DW4UI.sh (You may
> need to edit the permissions to make this file executable)."
>
> I assume that file is included in the DriveWire4.zip file on the site.
> If not, I have a copy of that file.
>
I've long since made it executable from a bash shell.

What I am upset about is not drivewire, but sourceforge's hiding of the 
src for nitros9.  And I'm not talking about that dated tarball 
sourceforge shows you, but won't let you have but the tarball those 
dsk's were made from. At 3.3.0, all the disk descriptors are broken so 
those I use are copied over the built ones, so my mb script just works, 
so thats one set of wheels I don't have to re-invent everytime I update 
whats on the 2 hard drives on my coco.  I might add that the mb script 
itself is a special for my system, erasing a disk clean since I haven't 
been able to format a floppy in 2 decades or more, so I just clean up 
the already formattted disk and make it look like a freshly formatted 
disk to os9gen.  This includes running KRNL-2-DIR and deleting the 
resultant boot track file since os9gen checks the FAT and won't write a 
new boot track unless it is cleared. I fought that bug for 5 years 
trying to make an autoboot from the hard drive boot, but os9gen skips 
that in total silence. I only confirmed it was not being rewritten after 
I wrote KRNL-2-DIR, and then vfy, and found that after os9gen had made 
me a shiny new boot with the scsi boot code and found the floppy version 
of boot was still in my new boot.

Comments from that discovery weren't for public viewing, and definitely 
not safe for work.  TBT, os9gen is just reacting to finding it can't 
allocate those sectors, but it would have been nice if it reported 
that "error".

But I don't publish those descriptors because to anyone else with 
non-identical drives, they would be just as broken as the distro 
versions at their default settings.

Basically, accurate descriptors for your system disks is the users 
responsibility. And I don't see a way around that since 90% of us with 
hard drives simply used what we had.

Me, I had a pair of 1GB seagate barracuda's in scsi-II flavor left from a 
failed amiga system. Both are still spinning, must have 220k + spinning 
hours on them by now. They were new in '89, 30 years ago, had about a 
years rest until I bought a new scsi controller from Mark, and about 2 
years rest while my basement was ankle deep in demo hammer debris from 
installing a drainage system that actually works.

Lesson to the folks watching power consumption: Drives that get powered 
down are drives that die. Which is worth more, the 2 watt hours to spin 
the drive, or your lost data...

Thanks Robert.

[...]

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
If we desire respect for the law, we must first make the law respectable.
 - Louis D. Brandeis
Genes Web page <http://geneslinuxbox.net:6309/gene>