Re: freedomization task list [was: Re: Dangerous precedent being set - possible serious violation of the GPL]
On Tue, 7 Dec 1999, Richard Stallman wrote:
> for instance, I run Debian, and the version of EMACS that Debian comes
> with, when run under X, spawns off an X-ized version of EMACS, rather than
> merely running the text-only (console?) version in the xterm.
>
> This is a minor thing, easy to change. If we want the pico-emulator
> to behave differently, we can easily make it so.
Obviously, if we're doing this to prick the Pico-user's conscience, we'd
BETTER make it damn well exactly like Pico's behavior, or forget the whole
thing: a nagging conscience doesn't have NEARLY the power that a
comfortable interface has.
> Whether Emacs is a good basis for replacing Pico is a matter that
> should be decided based on things that are not easy to change.
No, it should be decided STRICTLY on the basis of the willingness of the
average Pico user to switch over, regardless of how easy or hard the
changes are to make. We're talking about a user that ALREADY has their
editor of choice (to be exact, this choice of editors is strong enough to
override their social conscience). The onus of work here is on the one
requiring the change, not on the one giving up their editor of choice:
for the one giving up their editor of choice will be perfectly satisfied
if the status quo were to be maintained,.
> More importantly, EMACS is huge. Pico is tiny-- 156K versus 1.81M
> on my system, just binaries-wise
>
> 2 meg nowadays is not a big deal. I suspect that most Pico users will
> not notice the size of the editor; they do notice the look and feel of
> it.
I guess we all now get to sing "It's all about the Pentiums" :) 2 Meg
nowadays IS still a big deal. Ockham's Razor cuts software as well as any
other logic: "Pluralitas non est ponenda sine neccesitate". Also, 2 Meg
is larger than the average Diskette, and there is still something to be
said for an editor that can fit with a minima of tools and a zImage on to
a diskette--Volia! a Rescue Disk.
> Pico is tiny, albeit tricky to
> compile-- the clone would be tiniER,
>
> Optimizing a program for smallness tends to be a lot of extra work.
> It is not worth while unless there is some special crucial need for
> it, which here there isnot.
You're right--it's usually easier to scrap the idea at this point.
Actually optimizing a program for smallness shouldn't be necessary: you
shouldn't need to because it should already be optimized in the three
steps before you type a line of code: flowcharting, dry code, and
simulated runs.
> I don't know whether it is better to base the Pico replacement on
> Emacs, or something else, or start from scratch. But whichever way it
> is done, I think people should focus on getting it working properly
> with as little time as possible, to move on to another project--not on
> optimizing it for size.
Let's let the people doing it worry about what they're going to focus on.
If you want to make a pico-mask for EMACS, I doubt anyone'll stop you or
tell you where your focus should be.
>
> --
> To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
EMACS == Eight Megabytes And Constantly Swapping
Who is John Galt? galt@inconnu.isu.edu, that's who!
Reply to: