From: Scot McSweeney-Roberts (newton_at_mcsweeney-roberts.co.uk)
Date: Mon Sep 13 2004 - 05:03:40 PDT
Paul Guyot wrote:
>
>Some people here seems to know better than us what we should do and
>find stupid ideological excuses for not working on projects (geez,
>you didn't work on the DCL because it was not GPL'd?
>
No, because I have no idea if I can use the DCL with my GPL'd code. This
has nothing to do with ideology - I don't want to write something that
uses the DCL only to find out later that my use of the DCL violates the
DCL's license. I'm not a lawyer and I don't want to have to hire one, so
I'm going to prefer linking my software with other software that has a
well known and widely used license - one where my rights and
responsibilties for useing the code are well understood. I'm not going
to get that from software that uses it's own unique license that has
more quirks in it than any other license I've seen.
> because it had
>spaces in the directory names?
>
While not enough of a reason to not use it, it gave the impression that
this was for OS/X and not for Linux/*BSD (and therefore getting it up
and running may be more trouble than it's worth).
> because it was commented in French?
>
>
Je ne parle pas francais. English has become the global second language
and is certainly the international language of commerce - commenting
code in English opens to code to far more developers than commenting in
French. You've already got a very small pool of developers to draw from,
why make it more difficult for them?
>Most open source software aren't commented at all, and the DCL does
>compile on FreeBSD & Linux and we explain how to do so in plain
>English).
>
>
Where? I've come to expect to see plain text README and INSTALL files
in the top level directory - when I downloaded the DCL I found nothing
of the sort. It might not be so bad if the build instructions were on
the DCL's home page, but they're not. The same could be said for the
license - it took me a while to find out exactly what license the code
was released under. Most project pages prominently feature both of those.
>
>What is left is:
>- what should we do now considering what we don't want to do?
>
>Basically a subset of the question might be:
>- should we work on JIT emulation and run on any PDA with any processor?
>or
>- should we work on porting Einstein for natice code execution on
>ARM-based PDAs?
>or
>- should we work on porting Einstein for native code execution on top
>of an open source POSIX-compliant operating system (like NetBSD or
>Linux)?
>
>
>
Why not combine the first and second - write it so that it uses native
code when it sits on top of an ARM processor and emulation when it's not
(like how the Basilisk Mac emulator uses native 68k when it's run on a
68k machine, and a 68k emulator otherwise). By making it run on POSIX
compliant OSes, it should be easier to abstract yourself away from the
hardware of the device it's running on (and it gives a certain amount of
futureproofing).
Scot
-- This is the NewtonTalk list - http://www.newtontalk.net/ for all inquiries Official Newton FAQ: http://www.chuma.org/newton/faq/ WikiWikiNewt for all kinds of articles: http://tools.unna.org/wikiwikinewt/
This archive was generated by hypermail 2.1.5 : Mon Sep 13 2004 - 10:30:02 PDT