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 <[email protected]> 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 <[email protected] 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 <[email protected]> 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 >> [email protected] >> > -- Gary Weber [email protected]
