On 22/05/02 at 22:37 Richard Zidlicky wrote:
>> The support for a platform per se is not nor should ever be part of an
OS
>> core - the ability to add this support externally SHOULD.
> that would be nice. However we are in the position that all machine
specific
> parts on the Q40 work fine, the problems are in the generic code. There
is no
> way this problems could be fixed without fixing the generic part.
You'll get no argument about that from me. And, in fact, there are many
more things that need to be done to the generic SMSQ than you hinted in
your email. Not necesairly on the ground-breaking level, just a big
housecleaning.
>> programmers writing the [platform] support... should not contribute that
>> support in the first place. The part that they should contribute are the
>> changes necessary to have this support as an external module, AND THAT'S
IT.
>sort of BIOS? No problem but the problems with generic SMSQ remain.
Not really a 'BIOS' but rather a more modularized version of SMSQ. For
instance, not every concievable platform needs a floppy drive. Try pulling
out floppy support only from SMSQ, see how far you get. For things like
that one should hardly need to regenerate the whole binary after they have
searched out all the necessary source fragments and took them out!
Next big candidate is the OS bootstraping. There is a lot that happens
before the actual OS takes over, yet there is no way to change this
speciffically for a platform unless the actual start-up code of SMSQ is
changed. This should be a module. You mentioned in another email that it
may benefit 'some strange hardware'. Actually, it doesn't have to be that
strange at all. One good candidate would be an emulated system without a
host OS (i.e. hardware intended to run SMSQ based on a different CPU).
>> * Problem: special platforms like emulators that may have parts of the
OS
>> rewritten as native code. It would be in everyones best interest to
>> devise a standard way of doing this, not just for a speciffic case but
as a
>> general resource (yes I am aware this is not easy!).
>I don't see rewriting parts of the OS as useful, only OS part where
>emulators spend noticeable time are screen drivers.
That may well depend on the particular case, some emulators are closer to
the real machine than others. A way to go into native code for cases where
this is needed would be a good idea. Candidates, aside from graphics you
mention would for instance be floating point operations, and parts of
drivers in general. Ditto the first module executed - system
initialisation, see above. This may well be non-68k native code, setting up
the emulator itself, before it starts the actual OS code (68k). Even some
more complex operations which may not be part of the OS, but would need to
be things, would need such a feature (anything to do with co-processing is
a candidate).
>> If a contribution becomes a part of the official distribution, under the
>> current licence the contribution has to be free. May I remind everyone
>> that by gaining access to the source, you will essentially be able to
use code
>> that someone somewhere has paid for to be written, essentially for free.
>> It logically follows that any contribution added to the official
distribution
>> must also be free.
> I agree. Essentially there is very little work to be done to the core
> OS, mostly bugfixes, a few missing features on various platforms and
> a better framework for supporting filesystems. I do not believe that
> this would require "commercial" development.
Neither do I, but I don't think that work on the core OS could be called
'minor'.
There are things that could prove quite demanding, for instance interrupt
handling (multiple levels), memory management (slave block problem),
multiple processors...
>If someone wants to tweak specific parts of the system like SBasic or
>write a new filesystem it could be very well done outside of the core
>system.
Assuming it is split from the current source as it is. What I'm getting at
is that as a programmer, so far you only get to see the monolytic SMSQ. The
file system API as far as the OS goes is essentially the set of traps
available, very rigid and mostly cannot be changed. There is no reason why
this would not be a separate module. For all we know, it may be - but as I
said, right now it's all just guesswork (and an educated guess would be
that it's NOT a separate module).
>> Availability of the binaries in any circumstance cannot be guaranteed,
>> and it is absurd to even ask this.
> sure. On the other hand, should the license explicitly prohibit
> someone from compiling and making the binaries available when
> noone else wants to support this platform or the master repository
> gets struck by a meteor? This is absolutely ridiculous and I am
> becoming tired of reading about buses and meteors as an excuse
> for poor license.
Of course it is ridiculous, but if you demand a guarantee (without
gualifying it somewhat, and preferably in detail), you can expect your
demand to be taken to it's absurd exaggeration.
The licence text surely does not EXPLICITLY prohibit ANYONE, it only does
not provide an automatic recourse, rather an implicit one. The recourse it
does provide is for either an existing distributor to 'take over' or for
someone to become a new distributor for this platform. I.e. anyone can
provide the binary provided they pay TT Eur 10 for each copy provided. It
would be possible to demand of the distributors to be able to supply every
binary, which immediately begs the question of support, an especially
tricky subject when, as you say, no-one wants to support a platform!
I suspect one of the things you are getting at is support for a platform
that may be considered 'obsolete' rather than 'lost interest in'. For
example, a platform is 'abandoned' (no hardware suppliers, for instance) at
SMSQ X.YZ, and since then SMSQ has progressed to > X.YZ, yet you cannot
provide binaries X.YZ _for_free_. I wonder if it would be possible to
automatically make old versions of the binary free - I mean, sufficiently
older than the current one. Otherwise the scenario outlined should be
somehow catered for.
>Show me an open source project that would be so openly arrogant
>to the users as to create artificial hurdles if they wish to help
>themselves.
I think this is a case of improper semantics. It is obvious that this
licence does not put SMSQ into an 'open source' situation in the sense this
idiom is used (for instance for Linux). Open source in this case is the
regular language vernacular. It means, more open than it was thus far. I
think the words used automatically resulted in expectations associated with
those words in a different setting.
My point is, no it's not 'Open source' (note capital O), but it's still
better than what it was thus far. At least now you can get to read the
source and see if it's worth your time.
> Linux-Q40 is probably one of the less widespread branches of
> Linux and yet I have working up to date software like...
> Fortunately there is nobody who could prohibit me from making
> the binaries available so I feel very strongly compelled to
> continue development in this direction.
I assume you meant 'OS binaries' here... I see your point, but this is
after all your decision. Between having SMSQ completely closed, and under
this licence, which one would you rather vote for, even if you never use
it? My point is, this may not be the best possible licence, but between it
and nothing, I think I'll take it. This of course does not mean you
shouldn't voice your opinion.
>> * Problem: a LOT of work needs to be done to SMSQ before it reaches that
>> stage. This work is ABSOLUTELY NECESSARY in the long run.
> Consider the Q40 hardware - all drivers except parts of keyboard
> handler and soundsystem are fully generic. You supply different
> constants for the IDE definitions, 16550A base address etc and
> it will work on every other machine that uses this HW components.
Hardly - interrupts would be a problem for one thing. The way it's
currently set up, you either have to emulate one interrupt as it's set up
on the QL or as it's set up on the Qx0.
A good case could be made to have multiple interrupt levels (as long as
their usage is clearly defined) for certain peripherals.
Another thing would be some specifics for peripherals that may not be
currently supported, as an example I can mention the FIFO in the floppy
controller (this would enable true background floppy operation).
>> Under the licence, the source can be distributed as long as it's not
>> charged for in any way. The distribution of binaries that is not free is
>> rather simple to get around as a problem by distributing a make file, an
>> assembler/compiler, and a means to run it.
>sure, but:
> - distributing source by snail is costly. I would be a complete
> idiot would I volunteer to port SMSQ to UQLX and then have
> 10 Euro expenses on each copy I would send out to anyone.
I agree, which is why I put that in the 'problems' section just after this
paragraph. I can see some sense in not wanting the source to end up
'everywhere', with this licence (it could be a different matter if it were
truly 'Open source'), and I suspect the snail mail is a 'slow down'
measure. OTOH, if the source does end up 'everywhere', it would be very
difficult to trace how this happened, who is responsible, and how to
enforce the licence prohibition to do so.
IMHO two exceptions are worth considering, both to do with a class called
'developer':
One is beta versions of something that have to be tested, the other are new
releases of the source. The fact of the matter is, not everyone can use
IRCs (If I were back home in Croatia and asked for them, they would laught
their asses of, and once they managed to get their senses back, they would
say 'don't tell me you actually think you live in civilisation here').
There are many ways this could be done, but the problem is really agreeing
on something that everyone can do. For instance, you could do a digitally
signed PGP, kept on file. Ask the registrar by sending the signature, which
is verified against the PGP key on file, and if it checks out, he sends you
the sources PGPd with your key (on file) and signed with his signature (so
you can verigy the source). But now try to agree on the exact same version
of PGP...
> - you can't "distribute" the assembler/linker that easilly,
> iirc they are Quanta property.
I think only the linker, but I though it can be freely distributable? There
is a free assembler, assuming of course you can assemble the sources with
it (gwass?)
> - you need at least TK2 to do the bootstrapping
Not sure what you mean here (I may be limited by the platform I use)
>This might be easy enough for QDOS tinkerers but should I dare
>to offer this on freshmeat.net they would in best case laugh
>at me. Look how many excellent OS's are available under GPL
>licenses, it doesn't have to be Linux.
Well, agreed, but this is not GPL. Wether it would be better if it was GPL
is a matter of opinion, with TT ultimately being the one who decides under
what kind of licence SMSQ will appear. You can try to influence him in that
direction. Until the licence is hammered out, it is after all still HIS
stuff.
>> Distributing sources and binaries for developement purposes absolutely
>> MUST be alowed by electronic means. Developement easily generates dozens
>> of different binaries a day (or more!) and not using the fastest means
to
>> distribute them is equal to stopping all developement, period.
>!!!!
Especially considering that your testers may be thousands of miles away...
Mind you, IF SMSQ is split into a generic core, properly modularized, the
need to actually distribute SMSQ sources (rather than modules not covered
by the licence) would be fairly low. Still, demanding that it be done by
snailmail only would bring a halt to everything. Especially since for the
time being any changes made until we get to a point where there is a
properly generalized core, will be 'to the whole thing'.
>> Also, from this licence, it follows that TT, should he wish to
contribute
>> to the core, would have to do so under the same rules as everyone else!
>imo this doesn't follow from this license and I don't care under which
>conditions TT would contribute.
I think it does follow by virtue of not making an exception for anyone how
to submit anything. One problem would be the registrar himself (see what I
wrote about conflicts of interest, balancing the registrars powers with the
contributors, peer review, etc...).
In an ideal world, 'we are all friends' and all loopholes would not need to
be explicitly plugged, nor would the licence have to be enforced with an
iron hand, but if nothing else, the rather fiery digressions within this
discussion have already shown that going throug the licence with a fine
tooth comb, might after all be necessary. The only thing I fear is that
everyone will loose their patience and things will go back to the way they
were, something that could have been a very good thing will not happen at
all.
Nasta
