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.
Yeah.
>
> 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.
I fully agree with you on that one...
>
> 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
I -don't- fully agree with you on that one. 2 megs is -big- for a pico
emulator. Pico is a simple little thing that runs fine even on a Mac
II-series 68030 box running NetBSD (translation-- slow on top of slow)--
EMACS would chunk on the same machine... that is, if you could stand the
idea of the EMACS packages taking up so much of their precious little hard
drives...
That's just my 2C there. Personally, I think that EMACS is far too big to
kluge into a pico workalike.. and it would still leave the problem of
PINE. Pico is relatively simple, and PINE is just another mailer-- neither
would be too difficult to clone exactly. It's just not been done.
> not notice the size of the editor; they do notice the look and feel of
> it.
>
> 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.
Oh, I agree... but here, the issue is not optimizing for smallness, but
simply "recoding from scratch", which -in and of itself- will likely
produce a much, much smaller binary than pico. A friend of mine wrote his
first (serious?) editor recently; it already comes out of the box with
color hiliting and other spiffy features. It's binary is, I believe,
approximately two dozen K stripped. And it does more than pico does...
Pico is an old fart of a University kluge. The mere act of reimplementing
it from scratch would result in a teeny weeny binary. :) We wouldn't even
have to focus on optimizing for smallness.
>
> 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.
>
Agreed (see above). I'd like to start work on PiClone immediately.
--
= Jon "Caspian" Blank, right-brained computer programmer at large =
.--------------------------------------------------------------------.
| Freelance coder and Unix geek / Founder, The Web Union (twu.net) |
| Information wants to be free! Visit www.gnu.org. |
| WANTED: Writers who share the GNU philosophy. www.forsmarties.net. |
| - - - - - - - - - - - - - - - - - - - - - - - |
| E-mail: caspian@twu.net Web: http://caspian.twu.net |
| Send a short message to my cell phone: caspiancell@twu.net |
`--------------------------------------------------------------------'
Reply to: