Re: [Savannah-register-public] Re: [task #7917] Submission of Otavio Luiz Bottecchia

[Sylvain Beucler]

Hi,

Sorry for the delay, I didn't see this mail.
(and nobody else answered either -_-')


On Fri, Apr 18, 2008 at 10:32:01PM +0300, Alexander Shulgin wrote:
> Hi Savannah Hackers,
> 
> I need some advice on this project submission:
> http://savannah.gnu.org/task/?7917
> 
> On Fri, Apr 18, 2008 at 3:49 AM, Otavio <address@hidden> wrote:
> >
> >  Follow-up Comment #7, task #7917 (project administration):
> >
> [snip]
> >
> >  No, I have not tried to run it on Linux.
> >
> >  The program just send a sequence of commands to the controller, which, in
> >  turn, sends other commands to the transceiver. The syntax is determined by 
> > the
> >  rigs. The primary handshake (i.e., between PC and PTC) will depend both on 
> > the
> >  OS and the Basic interpreter (or compiler). In principle, only the 
> > following
> >  data transfer format is important: 8 data bits, 1 stop bit, no parity and 
> > half
> >  duplex. The later I did not define and the program run, so I did not paid
> >  attention on it. Of course, the baud rate is also important, but PTC has an
> >  option to detect baud rate automatically.
> >
> >  I fear there is no universal way to solve the handshake problem. I used
> >  another interpreter years ago and the syntax was similar, but not equal.
> 
> The program in question uses code like open("COM3") to communicate
> with the transceiver via COM port.  In my experience this is
> DOS/Windows who makes such special file names be mapped onto serial
> ports, and to achieve similar effect in Unix-like systems we need
> something like open("/dev/ttySn").
> 
> That said, I'm aware that the world of free operating systems is not
> limited to GNU/Linux and BSDs, and the code might be found happily
> running w/o modifications on, for example, FreeDOS...  Moreover,
> actual name of device file to use is not likely to be hardcoded in a
> real program and users can specify 'COMn' on Windows and '/dev/ttySn'
> on Unix-likes.

If it runs on FreeDOS without requiring proprietary drivers and such,
then it runs with 100% free software and it can be accepted at
Savannah. Same goes for *BSD (and possibly ReactOS, though I don't
know how clean their licensing is).

> Also, in GPL there is a disclaimer of warranties and in the current
> state the program runs on my box, but just doesn't do what it's
> supposed to do.  And that depends on how do you look at this: the
> program provides 'more features' (it actually works) on Windows while
> it runs, but it doesn't work (less features) on GNU/Linux. ;-)

If a program runs with more features on MS Woe then that's a problem;
it entices people to use proprietary software and we won't accept it
at Savannah.

> I believe there's no real obstacle to approve the project now, but
> still I feel we need to persuade author to 'improve users experience'
> on GNU/Linux.
> 
> Your comments?

I'd say the author has to test his software under a free OS
(GNU/Linux, FreeDOS, etc.) and tell us how it goes. He also has to
agree to continue doing so when maintaining the project.

It's similar to what we ask when people use Java (~ "Did you test it
with a Free Java Suite, and do you agree to make sure it continues
working that way in the future?").

-- 
Sylvain