[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: more evil firmwares found

Ryan Underwood wrote:

> On Fri, Apr 23, 2004 at 08:26:35PM +1000, Herbert Xu wrote:
>> Ryan Underwood <nemesis-lists@icequake.net> wrote:
>> >
>> >> Duh, of course the *definition* is software.  Any stream of bits is
>> >> software.
>> > 
>> > *Any* stream of bits?  I think that's going a bit far.  I think you are
>> > confusing the algorithm with the input.  The input is not software.  It
>> > cannot be executed on a machine.
>> Given any finite string of bits, you can construct a Turing machine in a
>> deterministic way and execute it.
> Are you going to be the one who constructs virtual machines that execute
> all of these arbitrary bits of data that we are currently referring to
> as "software"?

There is in fact a much better reason to think of them as programs.  There's
not much distinction between having a 'program' run by an 'interpreter' and
having 'data' interpreted by a 'program'.  We certainly consider programs
in interpreted languages like perl or python to be programs, not just
'data'.  But similarly, an ASCII file can be considered a 'program'
executed by the interpreter consisting of 'cat' plus your console.  An HTML
file is a 'program' interpreted by a web browser.  Et cetera.

> Should Debian be referring to supporting material as software, solely on
> the basis that a theoretical machine to execute that data *might* exist
> at some indeterminate point in the future?

> Is an application not distributable by Debian if it does not include the
Not the difference between 'not distributable by Debian' and 'not
distributable as part of the Debian system'.  Something is 'distributable
by Debian' if it can be legally distributed in non-free.  That doesn't make
it distributable as 'part of Debian', in 'main'.

> source XML of a manual,
I certainly hope that to go in 'main', manuals will have to provide source
(preferred form for modification); otherwise, it's quite annoying to modify

> or the source EPS of an image file,
If it was created and modified in that form.

> or the
> source waveform of a mp3,
If it was managed and modified as a .wav, the way I would, the .wav would be
the required source, yes.  (Some people work directly with .mp3s, despite
the quality loss, for whatever reason.)

> etc etc, ad absurdum?  Where does the cutoff
Nuthin' absurd yet.

> of practicality between software and supporting materials end?
What practicality problem?

In the *binary* packages, you distribute the preferred form for installation
and general use.  In the *source* package, you distribute the preferred
form for modification.  People who aren't interested in modification don't
even download the source package.  People who are interested do.

There are none so blind as those who will not see.

Reply to: