In <Pine.LNX.4.10.10007261211210.17503-100000@dax.joh.cam.ac.uk> James Sutherland (jas88@cam.ac.uk) wrote:
> On Wed, 26 Jul 2000, Khimenko Victor wrote:
>> > A properly designed protocol would have had support for this sort of
>> > extension to existing facilities, without inventing whole new dialects.
>> > In this case, probably the lock & unlock commands for removable media -
>> > just add a "password" field - **and include this in the standard so no
>> > other vendor uses the same field for something else, or vice versa**.
>>
>> This is not THAT simple. Not the whole world is hard drives. Especially
>> with SCSI world.
> So what? Whatever you are inventing, it should use a standard protocol.
> Even if it has to be a new protocol.
Yeah ? And then you need to wait for LONG time while committee will be
formed, new protocol will be approved and so on ? And then if can add
new feature (like auto-powersaving) you can not do so before committee
will approve such new feature ? Sorry. Users can not wait (if product is
indeed needed; otherwise they will not buy it). Later when standard will
define standard commands for this features you can change new versions of
products to be compatible with standard. Or you can even ussie firmware
upgrade to make product compatible with standard (think about modems:
28.800 modems existed before V.34 standard, 56.000 modems existed ebfore
V.90 standard and so on).
>> > If I wanted to add a new listing mode to `ls' for some reason, should I
>> > add a new switch to ls's vocabulary, or invent `newls'?
>>
>> And if I need C comiler I hardly want to add switch --cc to ls - better to
>> invent gcc :-)
> That's what I mean: for a new feature to an existing part of the protocol,
> extend that part. If it's genuinely a new area the protocol hasn't handled
> before, you will need a new command - so make that part of the standard.
Sorry. For vendor delivering product is MUCH more important then new
standards development (for linux distributions as well).
> Can you imagine if we had one distro shipping with gcc being "Great
> Cleanup Command", another with the C compiler, and a third where gcc as
> root is "reformat all disks"?
This is extreme example but for less extrime example it happens all the time.
libqt can be QT library or Qthreads (library from old Guile releases), pc
can be "Pizza compiler" (from old version of Kaffe) or "Pascal Compiler"
(from old version of GPC) and so on. Samples are countless. Usually with
time consensus is found (libqt from guile is now libqthread, pc from
GPC is now `gpc --standard-pascal' and so on). But if we tried to standartize
evefything first and try to write code only after then then we had only a lot
of papers about "future great GNU system", "future great BSD system" and
other "future great systems" by now and used Windows (due lack of choice).
Even more: when standard is developed it's still typical to produce new
systems not compatible with standard for YEARS (standard place for info pages
is /usr/share/info for FEW YEARS: how many distributions install them there?).
If you REALLY think it's way to go then stop using PC, stop using Linux and
go to develop "perfect system" in your ivory tower. We have no luxury to do
so: we need things to be done HERE AND NOW, not some 10 years later when
all needed standards will be there.
>> > Alternatively, if I really needed a new command for my new feature - drill
>> > holes in disk, say - I get it included in the next revision of the
>> > standard.
>>
>> What about new command to change resolution in scanner ?
> It's a new command. Put it in the standard.
And then go out of business since when standard will be finished your company
will be bancrupt for year or few (or you'll be able to convince everyone to
wait for standard scanners will not be available till 2010 when this standard
will be finished). Great way.
>> > That way, all you ever need is the latest ATA-* driver.
>>
>> Which in turn will include knowleadge about scanners and photo-cameras.
>> No, thnx.
> NO. The ATA-* driver does NOT need to know what a scanner is - only that
> the scanner commands are valid ones now.
And this is STUPID WAY. IDE and SCSI devices have more memory then my first PC.
It's MORE then enough resources to do all checking in hardware. No need to
teach ATA-* driver, no need to update kernel when you'll plug new hardware.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:21 EST