|
Home > Archive > Debian Developers > April 2004 > Font source Re: Social Contract GR's Affect on sarge
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Font source Re: Social Contract GR's Affect on sarge
|
|
| D. Starner 2004-04-29, 7:33 am |
| > People have argued that since there exists Open Source tools for
> editing fonts, font files should be considered their own source, even
> if Font Foundries have their own preferred source formats and use
> propietary tools to create font files via a compilation process.
But the TrueType files are the preferred form of modification for us;
most people, if offered a choice of the TrueType file or the format the
font foundries used to edit, they would take the TrueType files.*
> But we can edit firmware via hex editors too,
> but firmware is considered evil so they are not considered own
> "source".
But almost no one, if given a choice of the binary or the assembly language
to edit, would choose the binary. At the very least, the assembly would be
invaluable to deciphering the details of the firmware, and I suspect many
programmers would write a Q&D assembler to use the assembly if there were
no free assemblers for the target.
* As a side note, it's far from true that all of the fonts in Debian
are produced by font founderies. The Thryomanes fonts are produced by
a lone programmer using the Macromedia font builder, IIRC. Several
newer fonts have the PfaEdit source files with them, making this
whole argument moot for them.
--
________________________________________
___________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| Stephen Frost 2004-04-29, 8:34 am |
| * D. Starner (shalesller@writeme.com) wrote:
> But almost no one, if given a choice of the binary or the assembly language
> to edit, would choose the binary. At the very least, the assembly would be
> invaluable to deciphering the details of the firmware, and I suspect many
> programmers would write a Q&D assembler to use the assembly if there were
> no free assemblers for the target.
It's not like there's a whole lot of difference between the assembly and
the binary in this case. Write a Q&D disassembler and extract the
assembly if you want.
Stephen
| |
| Stephen Frost 2004-04-29, 9:34 am |
| * D. Starner (shalesller@writeme.com) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
>
> Even if we were talking about x86 assembly, there would still be a lot
> of difference between assembly with mnemonic constants and labels
> and comments, and assembly from a disassembled binary. But some of
> these chips are poorly documented or undocumented; if we don't know
> the instruction length, much less the opcodes, writing a disassembler
> could be a serious act of reverse engineering.
Of course it could. Writing an assembler would probably take some
serious effort too without knowing that information. To some extent
that's my point- are we going to require hardware specifications for
anything that uses firmware? Personally I don't think we need to, or
should. If we don't have the hardware specifications though, there's
really not much use to having the assembly for the firmware that runs on
that hardware.
Stephen
| |
| D. Starner 2004-04-29, 9:34 am |
| Stephen Frost <sfrost@snowman.net> writes:
> It's not like there's a whole lot of difference between the assembly and
> the binary in this case. Write a Q&D disassembler and extract the
> assembly if you want.
Even if we were talking about x86 assembly, there would still be a lot
of difference between assembly with mnemonic constants and labels
and comments, and assembly from a disassembled binary. But some of
these chips are poorly documented or undocumented; if we don't know
the instruction length, much less the opcodes, writing a disassembler
could be a serious act of reverse engineering.
--
________________________________________
___________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
| |
| D. Starner 2004-04-30, 5:34 am |
| Stephen Frost writes:
> Of course it could. Writing an assembler would probably take some
> serious effort too without knowing that information. To some extent
> that's my point- are we going to require hardware specifications for
> anything that uses firmware? Personally I don't think we need to, or
> should. If we don't have the hardware specifications though, there's
> really not much use to having the assembly for the firmware that runs on
> that hardware.
Sure there is. Having the binary and the assembly would reveal enough
information to to write an assembler; it would reveal roughly what the
opcodes did and how to program for it. It would be a lot easier to make
changes to the firmware once that information had been revealed. It
could provide a good start on a full reverse engineering of the hardware.
--
________________________________________
___________________
Sign-up for Ads Free at Mail.com
http://promo.mail.com/adsfreejump.htm
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
|
|
|
|
|