Tunes ballot

[spc@gate.net]

On some network somewhere in cyberspace, Francois-Rene Rideau transmitted:
> 
> >   As to borrowing code from Linux, if you're thinking in terms of
> > using Linux code to write a "UNIX Emulator" for Tunes, then there's
> > nothing stopping you from doing that.
>    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.
> Nevertheless, code will potential bugs is better than no code at all,
> you can modify it thanks to the GPL.
> 
  I'm speaking as someone who has tried this.  Forget it.  

  Some background.  A company I work for (okay, I'm a partner) currently use
Linux because it meets our needs.  We currently run 1.2.13.  We got a new
machine with some pretty high-end hardware, and the SCSI card we got isn't
supported in 1.2.13, but there is a driver for it in 1.3.x.

  "Okay," I said.  "Device drivers should be pretty modular, even for Unix. 
I'll just take the source code from 1.3.20, plop it into the 1.2.13 tree,
and compile it.  It's from the same OS for crying out loud."

  No go.  Too many things undefined.  

  "Okay," I said.  "To add device drivers you link in the new ones, so I'll
take the object code from a 1.3.20 build, move the object file over, and
attempt linking it into a new 1.2.13 kernel."

  Three hours later, I still didn't have a kernel that would link.  And Lord
knows that even IF I got the thing to compile and link, that it would last
10 minutes running.

  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!

  And the serial device drivers are only there to service terminals (and
their line disciplines), not the serial device.

  It's not worth it in my opinion.

> > And personally, if it were
> > me writing a new OS from scratch (and when I have a steadier income,
> > it will be :), I wouldn't use any code from any existing OS - it's
> > hard enough breaking the mold of outdated concepts without trying
> > to borrow them to make your work easier. For something like you're
> > trying to do, you need to (even though it's more work) forge ahead
> > with a clear, consistent vision, unmuddied by remnants of the past.
>    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.
>    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
                                                              ^^^^^^^^^

  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.
> 
  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.

  -spc (Some of the code in Linux scares me)