??? 7/11/2002 12:07:12 ??, ?/? Dave P <[EMAIL PROTECTED]> ??????: > > >Before replying to Phoebus' post, I'd just like to say that I have the >utmost respect for someone who changes their mind after expressing a view >for so long.
Thanks. Please here note that if TT had made a different point in his email my objections would still stand on the license... It's just that up until now, I regarded the SMSQ/E license under a different light. Truth be told that a program developed continuously since 1983 at a certain point stops being a product and becomes a labour of love (it's art in its own right). This fact I overlooked. Regarding the rest of the OSS world however, I stand by my original opinion, which isn't that much unlike Dave's :-) <snip> > > >The issue I take with it is this notion that all versions of SMSQ/E must >be identical. I think this is not in SMSQ/E's best interest because it >discourages development. > I would disagree on that. I don't believe that the license's intent to make everything identical. It's intent as I perceive it to make non-hardware specific functions behave the same. In that sense, if you are writing a program that's graphics oriented (to come back to my favourite subject), its useless if on a specific platform the same calls do different things. In the case of graphics for example I would say that you are confusing functionality with output. SMSQ/E achieves that as it stands now in the sense that even non-colour aware versions of SMSQ/E (later ones granted) can understand the colour specific commands even if the hardware (or the specific version's drivers) can't display them. That's not bad. It does ensure a level of compatibility which is not perfect but better than nothing Before something jumps in and says that I said to Roy that if totally new features were introduced that made older software incompatible that was okay... please note that these features should be available EVERYWHERE... therefore making SMSQ/E for ALL platforms incompatible, not just one :-) >For example, I think it is good for a version to add a feature that may >not be supported by other platforms, *as long as it is an addition*, and >the software style guide states that if the feature is used in software >released for all platforms, the equivalent functionality should be >included (if possible) for other platforms too. Exactly my point :-) And also at least the other be aware of the extra functionality and not crash... This cannot be possible with patches (which in the specific Q60 case may or may not be affecting code functionality on other platforms, but that's besides the point here) but only with incorporation in the main source tree... >For example, say a machine is released that requires different code to >operate an IDE interface. That version should be allowed to exclude code >which is simply not relevant, like microdrive-related code, if microdrives >could never be attached to the machine. (this may be a bad example) > >That IDE code may for hardware reasons be entirely irrelevent to every >other version, but be required for this version just to achive the same >functionality. See here you are partially wrong and I will tell you why too. (I owe this explanation to Nasta btw) The problem with QDOS/SMSQ so far (and I believe its the most serious problem) is that in reality its "drivers" are really custom pieces of code (as in code that someone would write only to support a specific hardware/software combination and that wouldn't be available elsewhere in the OS) that really have nothing to do with the OS itself (the famous metadrivers discussion again). While QDOSMSQ provides us with the necessary functionality to do these things (and more... Really if we think about something "new" chances are that SMSQ/E already has it... problem is Tony never really "told" us about it... but more on that in a second), no one really sat down to write a driver framework (Objects, Methods and Classes... yes in reality SMSQ/E is a truly Object Oriented OS) and thus eliminating the need to keep "drivers" in the source tree. If such a framework is introduced, first of all, all discussion on how drivers and hardware specific functionality is implemented will immediately cease. (A very basic level of a "BIOS" equivalent with a quasi-driver of course will have to be maintained in the source tree in order for one to be able to boot the machine... that's understandable but the drivers in that case being what they should be wouldn't cause either controversy or incompatibilities ;-). > >Dealing with the machine at a hardware level, it seems silly to require >that all those patches be included in all versions of SMSQ/E, and/or that >additional features to support extra hardware be globally applied even if >other machines could never support the hardware. > True (see my take on the subject above :-) but in any case that wouldn't matter... as the interface would be there, just not the drivers... so you call something and the IO subsystem would respond in an appropriate matter, not introducing more bugs with each version of the OS. Writing the code that isn't there (A traffic monitor in essence for the IOSS, plus a driver framework i/f) is one thing I plan on doing with SMSQ/E once I get the sources... oh yes and a decent command line :-) (I hate typing five hundred words just to copy one file... I have to admit, even more than Unix shells, DOS had always the best (see: easiest to use) command line (especially when enhanced by 4DOS or NDOS) It's my firm belief that SMSQ/E is still one of the most advanced OSes in existence and with a few alterations it can be with us a lot more years to come. As for portability, I would like to see it written in C for easy portability on other platforms. Granted most software would need recompiling, but just imagine a 2.7 GHz x86 machine running SMSQ/E natively... fear us Windows (And Unix). If it is stripped of the unwanted baggage (see: "drivers" and enhanced with a decent command line) it is very possible :-) >I hope I explained this properly - it's a difficult thing to explain when >I'm tired and can't find the words. > You and me both buddy :-) Phoebus
