On Wed, 15 Oct 2003 08:11:16 +0200, <[EMAIL PROTECTED]> wrote:
<snip>
On 14 Oct 2003 at 22:13, Peter Graf wrote:
.
To some extent, QPC and Qx0 might be seen as competing with each other, (I've heard
this being said) even though, for me, they are definitely not.
I do not think that the Qx0 and QPC are directly competing with each but they do indirectly.
To explain: Basing an OS around an emulator, tempts users to totally abandon hardware for software only.
Once this is total, then the QL idea will be all but dead. That is not to say that emulators do not serve a purpose,
on the contrary; they can act as complimentary tools (and they do so) in many occasions as for example software development.
(Many systems rely on software emulation running on Windows or Unix or other platforms for testing of software before it gets to the real hardware.)
That's VERY good and VERY helpful (Ie software development of even the PSION suite was done on alien hardware, or modern Symbian development is done on Unix and Windows).
However (and that is the user's preference not Marcel's doing of course) when the emulator becomes the only place where the software is run, then first the hardware becomes totally obsolete and then the emulator itself. If the trend for emulation-based only QL work continues, then we might as well totally abandon QPC/QemuLator/uQLx etc and rewrite QDOSMSQ (to use Thierry's term ;-) in a higher level language and use it natively on PCs, MACs and what have you.
The purpose of existence of any QL derivative OS is to run on hardware after all and to take advantage of that hardware. If that doesn't happen what is the point of still using the OS?
It is (and according to my belief illustrated above) therefore imperative that the users choose to invest in hardware instead on only software (in the best situation both) if there is any point in all of this.
Marcel (as well as Peter) each in their own, chose to create something to satisfy a demand that existed. The fact the users brought the two "solutions" (Better term than platform ;-) against each other in a way (see articles in QLT before the whole SMSQ/E license change by people not involved in this) that the creators of the solutions were brought before an existing situation beyond probably their initial reasoning for creating what they did.
Unfortunately, today, one of these platforms (QPC) is actively maintained by its author,
the other (Qx0) doesn't seem to be, at least as far as SMSQ/E is concerned (and, quite
frankly, the Q60 only interested me as a QDOS compatible machine, if I want to run
Linux, any old PC will do - and they come cheap).
I don't think that the Q60 was ever sold as a Linux machine (although it runs it very capably) but with the *ability to run* Linux. (Similar to saying PC with the ability to run QL software via QXL or QPC!.. It's not primarily therefore a QL ;-)
Apart from that I fail to see how the Q60 is being developed actively? Software development and hardware development are distinct processes. The Q60 is completed and working fine. Peter designed and implemented the hardware and we're asking him to make the software for it too? (Don't get this in the wrong way I am just asking a legitimate question). Nobody asks Marcel or you to design hardware to fit the software right? Just as we never asked Miracle to write SMSQ. TT did that!
The fact that Peter has the ability to contribute software is unrelated to the fact that he designed the hardware.
Now, if you mean by developing to create new hardware solutions more extended than the current Q60 offering that's a different process that involves a substantial and immediate investment. Even to make my new ED drives it took me several hundreds of dollars and that's an easy task... imagine tackling a whole machine in say a ColdFire implementation with PCI bus... can it be done? Sure... will it be done? Probably not, and one of the reasons was explained by Peter... he doesn't feel that the current license of SMSQ/E can help a potential design.
Now, Marcel has gone to great pains to make sure that all of his efforts are useable on
the others machines, even to such an extent that he didn't just dunk me his code and
tell me to adapt it (whih he could simply have done, and nobody would have found
anything odd with that) but he actually programmed, e.g., Q60 specific code.
But still, you have a situation where one platform is being maintained by what some
(you?) see as its competitor. And here, I can only salute Marcel's dedication - I'm not
sure I would have had the moral fortitude to act this way.
However, you can't expect Marcel to do Qx0 specific development only.
For example, who will try to take Thierry's CD driver any further? Who will do software
development to take the Q60's sound system further? Shouldn't you be involved in
that?
Isn't it a pity that you aren't?>
I think that the issue is a lot more complicated than that. Unfortunately, in order for the Q60 hardware to be fully utilised, a lot of processor and hardware specific code has to be written. Unfortunately the current situation of the license permits that only for one's own leisure. The license is what it is and has to be respected regardless of one's personal opinions. A solution to that would be extensive patches on the code and the list has seen a tremendous disagreement over that in the past. As for the sound system what do you mean? If you mean sound generation by tapping into the DACs directly it has already been done (and a future version of QWord will include that code which I am now perfecting thanks to the always valuable assistance by Simon Goodwin) but we should not forget that many of the hardware capabilities are severely restrained by the software.
Emulators do not have these problems because even though the version of the OS can be "compatible" with other platforms, the emulator can trap whatever the heck it wants and replace it on runtime with native code thus removing the restrictions... in effect patching the OS at the author's leisure. I am not saying that this is bad or good (I actually think that it is good as it improves performance and everything for me is about performance) but it is a tad unfair to the native hardware if you think about it. Why shouldn't the Q60 be able to use the MMU or FPU natively and HAS to rely on the "compatible" code if it is to stay "official". Sure you can patch it later on, but then the whole premise of the registrar and "compatible" code goes out the window anyway.
As for Marcel's involvement in Q60 development, I don't think that anyone expects him to do it... we are very grateful for what he has done so far and if he would stop right now any development he would have still made more than enough contributions...
As for Thierry's CD driver it still is severely hindered by the structure of the IOSS which needs a VERY serious overhaul. CD ROMS being inherently slow devices lock the machine completely. Thierry's work is great but without substantial improvement on the way I/O is handled by SMSQ/E and QDOS it is good only as a once-in-a-while access for massive files that need only scarce access. The funny part is that by allowing 040+ commands in the code you could save a lot of time in many I/O operations and you would at times double the effective speed on many operations on Qx0s. But this is not allowed is it?
I would LOVE to have you with us.
Everyone would. One lost developer is one too many :-)
Phoebus
--
Visit the QL-FAQ at: <http://www.dokos-gr.net/ql/faq/> (Still uploading stuff!)
Visit the uQLX-win32 homepage at: <http://www.dokos-gr.net/ql/uqlx.html>
Visit the uQLX-mac home page at:<http://www.dokos-gr.net/ql/uqlxmac.html>
