Tunes ballot

[Nathan Hawkins]

On Sat, 30 Mar 1996 spc@gate.net wrote:
> On some network somewhere in cyberspace, Francois-Rene Rideau transmitted:
> >    Yes, but not only:
> > it would be stupid to think plpenty of people will be rewriting
> > yet another driver for every single hardware board in the world,
> > just because there are good ideas behind Tunes.
> > My intent is we use the Ctranslator subproject to steal all
> > the device-driving code from Linux, BSD, VSTa, et al,
> > because there's so much of it, that already works well.
> > Of course, whoever uses blindly translated code
> > will have to be aware of potential bugs.

In this case, based on experience with trying to mooch Linux drivers, I'd 
say forget it. You might have better luck with VSTa.

> > Nevertheless, code will potential bugs is better than no code at all,
> > you can modify it thanks to the GPL.
> 
>   And as far as modularity goes, it wasn't, isn't and doubtfull it'll ever
> be.  There were references to SCSI drivers in the kernel!  Ye gods!
> 

Yeah, Linux wasn't designed with modularity in mind. It is extremely 
obvious that it was an afterthought that was hacked on, with very poor 
results. (I had such a bad experience with modules that I decided not to 
use them.)

> >    I half-agree with your statement:
> > the general design should effectively be a clear, consistent vision,
> > that doesn't make any concession just for the sake of "compatibility".
> > Still, we shouldn't *systematically* call remnants of the past "mud";
> > sure, most of it sadly is,
> > but if we reached the present point in civilization and technology,
> > it is precisely because in this mud lie diamonds
> > that appear as the mud is cleared away by time.

By no means forget to keep useful concepts, such as code, data, memory, 
etc. ;)

> >    So as for borrowing code, particularly from device drivers,
> > this doesn't frighten me, all the more as it is meant as an expedient way

After looking at Linux's drivers, I'd have to say that it probably should 
frighten you.

>   But I thought TUNES was a Useful, Not Expedient System <duck>
> 
> > to quickly provide support for various hardware,
> > while developping more generic tools to recycle all code into
> > code usable on the new platform.

Hm. I have my doubts about directly translating device drivers. 
Especially considering the weird timing issues that crop up on most 
devices... In theory it might be possible, but practically, I don't think 
you could automatically port drivers to a dissimilar system. Besides, it 
might be less work to just recode drivers.

>   My experience has been that trying to shoehorn code into a project that is
> similar, but not quite the same often takes longer and produces more bugs
> than rewriting the code (or writing the code) from scratch, especially if
> the original code is poorly written or designed, which I have to say that
> most of Linux falls into this camp.
> 
>   I would probabably use the existing drivers as a reference, but that's it.

Better yet, get actual specs, and use those, with reference to Linux. 
Certain Linux drivers (I'm thinking of the IDE driver here) were 
developed without them, and just hacked on until they seemed to work. 
There are still comments in the IDE driver about phenomenon that they 
don't understand.

I got a working IDE in about a week and a half, but I wrote it by 
refering to the spec.

*utsl*