By tightly coupled, I mean that Telcom has inside knowledge of the rest of the system.
The tpdd does not. (nor the dvi, and I'd put money on the chipmunk too) The only reason you can produce examples of other software and systems doing things like that, is because it's something that used to be very common, and even today every new programmer takes some time to learn better, and some never do. But by now it is recognized as an antipattern. After Joe-self-taught-teenager-programmer-from-the-70s-80s writes a bunch of such stuff, it's all fine at first, and only later he discovers that he has written an unmaintainable and unportable brick. Customer wants the tiniest change and it's practically impossible, because the code is riddled with assumptions that should never have been made. John did raise some points that no tpdd emulator to date has emulated the drive *really* though, else they would use disk images instead of files. And the knitting machines don't use files either. I personally don't think that's a strong enough argument, but it is at least an argument. I think that just means a tpdd emulator is a filesystem instead of a disk. OK, so I would not tolerate a filesystem that modified the files either. As to Mikes point about causing harm: Preserving data is never causing harm. If there is harmful data, then the harm was caused by the thing that created that harmful data. I see that as "two wrongs don't make a right". If a text editor added eof, that was a bad text editor, and it's more helpful to the user to have the bad data and thus indirectly the cause of the bad data, be exposed and corrected, rather than silently allowed to persist and even propagate over time. So that you go on thinking you actually have good data when you don't and it just fails tomorrow in any other context. -- bkw On Fri, Feb 15, 2019, 2:44 PM Gary Weber <g...@web8201.com wrote: > GW>> Since when is it NOT wrong for TELCOM to disallow recording of > <EOF> into a .DO file being downloaded, but it IS wrong for the > LaddieAlpha/TS-DOS combination during the same operation? > BW> the fact that telcom is part of a very tightly coupled and managed > system. It's not generic software that runs anywhere > > You have clearly, and strongly, stated the some very sound engineering > principles. Honestly I doubt anyone (or at least many) would question the > principles in the universal generic sense. > > But I would assert LaddieAlpha is not universal or generic. It has a very > defined stated purpose, and has always made specific concessions for Model > Ts & WP2s. Using it outside of this context is at your own peril, so to > speak. And you're bringing up not just edge cases but actually *corner* > cases to the usage model. > > Secondly, TELCOM doesn't know where data is coming from via the COM: port, > so I question the claim that it is part of a very tightly coupled and > managed system in the context of how it downloads data. Rather, it filters > the data to be appropriate to the machine. The LaddieAlpha/TS-DOS coupling > is no more nefarious than this, and to knowingly permit that combination to > crash the machine, while TELCOM protects the machine, would not only be > silly, it would be irresponsible. > > Unless the user directs it to do so of course, whereby my > --allow_file_system_corruption switch would suffice. ;-) > > > On Fri, Feb 15, 2019 at 11:31 AM Brian White <bw.al...@gmail.com> wrote: > >> All else being equal, it IS wrong for telcom not to record whatever bytes >> are sent. >> >> It's excuse is, at the time such ideas hadn't been recognized and >> discarded yet, and the fact that telcom is part of a very tightly coupled >> and managed system. It's not generic software that runs anywhere, it's part >> of a rom, and so it's less of a crime to be tightly coupled with the other >> parts of that rom, like making presumptions about what kind of data may >> exist in a file with a certain kind of name. >> >> The tpdd makes no such presumptions. >> >> Telcom also only ever claimed to operate like a user application that >> deals in text just like a text editor. How the text editor and telcom >> package up data internally are their own business. They just accept >> keystrokes and display characters. That is an entirely different domain. >> >> What you should ask is, when you tell BASIC to read or write from COM:, >> does BASIC presume to modify the data? >> >> Similarly would you tolerate a file compressor or other encoder that >> didn't spit back out exactly the data you put into it? >> >> Telcom processing the data as though it's text is like an image editor >> adding metadata on it's own. It's an allowed part of it's job because it's >> job is to deal in displaying a visual image to you, not to hold that data >> in trust for something else. IT is the app whose defined role is to >> manipulate and process the data. >> >> But then when you take that image data the the image editor made, and put >> it into a zip file, and save it to a thumb drive, and then read it back >> from a thumb drive, it's entirely wrong for any of those things to output >> one single bit different from what they were given. >> >> On Fri, Feb 15, 2019, 5:19 AM Gary Weber <g...@web8201.com wrote: >> >>> Since when is it NOT wrong for TELCOM to disallow recording of <EOF> >>> into a .DO file being downloaded, but it IS wrong for the >>> LaddieAlpha/TS-DOS combination during the same operation? >>> >>> On Fri, Feb 15, 2019 at 2:29 AM Brian White <bw.al...@gmail.com> wrote: >>> >>>> Since when does a disk drive decide what is and is not supposed to be >>>> treated as text vs binary data? The application author who decides which >>>> flags to use with open() does that, or the ftp client user does that by >>>> using the bin option *which exists*. The the drive subsystem never ever >>>> decides that. >>>> >>>> No one answered the question about the sewing machines which also used >>>> these drives. >>>> >>>> "AFAIK "good programming practices and principles" are suggestions and >>>> recommendations, not laws." >>>> Indeed. >>>> 1) I never said anything else. >>>> 2) Why is a "good practice" good in the first place? For a reason, not >>>> because god said so or something. Something is good or bad because of the >>>> harm it lessens or increases. >>>> >>>> >>>> >>> >>> -- >>> Gary Weber >>> g...@web8201.com >>> >> > > -- > Gary Weber > g...@web8201.com >
