[Debburn-devel] Suggestions

[Nathanael Nerode]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Albert Chin wrote:
> On Tue, Sep 12, 2006 at 04:55:25AM -0400, Nathanael Nerode wrote:
>> (2) Strip out all the cruft related to support for Linux kernel interfaces
>> other than the ones in Linux 2.6.
> 
> Why drop 2.4?

I think the interface is the same in 2.4 and 2.6, so no, don't drop the
2.4 interface, there's minimal if any cost to maintaining it.

>> (3) Drop support for obscure operating systems, starting with the
>> VMS support files.  (All of those ".com" files are VMS build files
>> -- there's no way those are going to stay maintained, so remove
>> them.)  I think several of the proprietary Unices are clearly not
>> worth supporting either.  You might want to just go all-Linux (or
>> Linux + *BSD); do you really care about non-free OS support?
> 
> We're interested in AIX, IRIX, HP-UX, Solaris, and Tru64 UNIX.

That's a nice, well-behaved list.

AmigaOS, OS/2, MS-DOS, VMS, and Windows (Cygwin) add substantial
quantities of gunk.  Unixware and Openserver support is probably
unmaintainable due to the dead-end nature of those products and the
dead-end nature of the company which produces them.

The other POSIX-like systems are not likely to cause much difficulty
to support.

>> (4) Phase out libscg altogether in favor of a 'new interface' of
>> your own design. A new interface will allow the removal of the "You
>> may not" lines, which will become totally irrelevant.  The libscg
>> interface is bizarrely Solaris-centric, and also excessively
>> old-style-SCSI-centric, because it's a direct emulation of a
>> hardware interface.
> 
> Does this mean moving to something Linux-centric?

Absolutely not.  The idea would be to determine what is desirable from
*wodim's* point of view: to make an interface which looks nice to
the *software*, rather than something based on any particular hardware
or kernel.  (I don't know whether Linux's interface was nice to the
software, but Schilling certainly didn't think so.)  Of course, it
should be low-level enough to cover any commands one might want to issue
to any SCSI and any ATAPI CD-ROM, and to get results back.  Ideally,
however, it would abstract away the differences between SCSI, ATAPI, and
other low-level transport layers, as well as between the different
system interfaces to those layers, to the extent possible.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFIcrfRGZ0aC4lkIIRAqQRAJ9Id+BBF+++HvFEhrTtdmqYf6OzkQCfaesB
pNvwSZVsxmnu+KHypAmeV/A=
=FD19
-----END PGP SIGNATURE-----