Make what stop? And why? It's a technical discussion of a techinal topic on a technical topic mail list. Why be on a mail list about a computer if you don't like hashing out computery details like that?
-- bkw On Fri, Feb 15, 2019, 11:28 PM Kevin Becker <ke...@kevinbecker.org wrote: > Please make it stop > > > On Feb 15, 2019, at 10:56 PM, Brian White <bw.al...@gmail.com> wrote: > > 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 >> > >
