Mail Archives: djgpp/2009/06/12/23:15:52
Hi,
On May 22, 5:04=A0pm, Rugxulo <rugx DOT DOT DOT AT gmail DOT com> wrote:
>
> On May 18, 9:46=A0pm, "A. Wik" <r DOT DOT DOT AT dynamite DOT narpes DOT com> wrote:
>
> > > Perl 5.6.1 was like half the size of 5.8.8. I don't like it when
> > > things double in size in such a relatively short time.
>
> > That is, of course, because unlimited disk & memory sizes, not
> > to mention unlimited CPU speed and unlimited just-about-
> > everything-else have spoilt programmers into not even trying to
> > control quality of existing code, but rather adding new features
> > so that they can list the latest buzzwords among the supported
> > features of the latest release presented on their frontpages,
> > thus luring bloatware Linux distributions like Red Hat into
> > downloading and including it in their package systems, so that
> > *they* can list the latest buzzwords on *their* frontpages.
Well, some new things I've discovered (corrections welcome):
Red Hat just released Fedora 11, which supposedly crams OpenOffice and
Java on one CD thanks to compression. And they use GCC 4.4.0 to host
everything. If all that's true, that's quite a feat, because a lot of
other distros don't include half that and yet still use a full CD
(which is annoying, even with a fast connection).
> Is it just me or is Linux very media-oriented these days? When every
> distro tries to include MPlayer, XMMS, Firefox, Flash, etc., no wonder
> they all top out at huge sizes.
>
> > (Needless to
> > say, XP/Vista support is essential for maximum popularity of
> > any software, and given the native size of those systems, users
> > hardly notice a few GBs more.)
>
> Compression sucks, or at least nobody uses decent tools. And it's true
> that nobody cares, sadly.
Well, even the just-released Linux 2.6.30 now supports LZMA
compression of the kernel ("33% smaller"). I wonder how that compares
to UPX. Of course, removing write support for VFAT probably slimmed it
a bit too. ;-)
Even FreeBSD or NetBSD kernels are like 10 MB (or 5 MB gzip'd) while
OpenBSD is 6.5 MB or so. And that's not counting modules (although I
think OpenBSD doesn't use any)! Weird, I tell ya, just plain weird.
They say you can strip it down a bit (and some even claim *BSD is much
much easier to recompile, but I wouldn't know), but for a floppy dude
like myself it won't ever be small enough, at least not without lots
of manual tweaking and size optimizing.
> > Perl has been quite useful for a long time (although my
> > experience is limited to using and fixing the perlscripts of
> > others with mixed success) and perhaps even too useful... =A0Perl
> > is the "Practical Extraction and Reporting Language" and it's a
> > suitable tool for that purpose, in those cases where grep, cut,
> > sort, uniq, join, sed, awk, tr, find, xargs, etc. are
> > insufficient or otherwise unsuitable. =A0
I don't know why people use grep, tr, expand, etc. when sed will do
the job for them. In other words, there is some overlap that could be
condensed a bit. I guess that's one argument for using Perl instead.
> At one time, there were efforts towards a microPerl or TinyPerl, even
> for use in place of the autoconf and pals. It does bug me when you
> need twenty different utils just to bootstrap something simple. Of
> course, it also bugs me when "ztouch" (very very very small script)
> requires the big, bloated Perl just to run. =A0 :-P
Look at this:
[ Vista ] - Fri 06/12/2009 >upx --best --lzma --all-filters perl.exe -
qq
307614 -> 105988 34.45% dos/exe perl.exe
Now, granted, it's "4.0.18 patch level 36" from 1993, but still, now
THAT's small. At that time I can see how Perl would be considered
useful. But nowadays with all the bloated extras, it seems like
overkill, esp. when all the tools it's supposed to replace still exist
(and get bigger and bigger, ahem GNU).
> > I would probably benefit
> > from using it myself in many such situations, as I'm prone to
> > start (but rarely finish) a real program instead after finding
> > the basic tools (and vim) unsatisfactory. =A0The opposite problem
> > seems far more prevalent, however, and scripts that should
> > serve, at best, as prototypes, proofs of concepts, or
> > quick-and-dirty fixes for occasional problems are frequently
> > taking the place of proper compiled programs designed with speed,
> > compatibility, reliability, good resource management, and other
> > noble goals in mind. =A0(Although I suppose it must be acknowledged
> > that scripts may have advantages such as portability, once the
> > interpreter has been ported.)
Well, Perl can byte compile (or compile with GCC via "perlcc" although
that apparently doesn't work with the DJGPP version or else I did it
incorrectly). And while "s2p" is a cool hack and potentially useful if
you need to do "real" programming, I can't imagine too many urgent
scenarios for that (will have to play with it some more). Maybe if you
couldn't guarantee that sed would work as promised or wanted to slurp
the whole file in for better speed or needed stronger regex support. I
dunno, even Perl isn't quite ubiquitous in every OS by default (e.g.
NetBSD), so that hurts its odds a bit.
> Every Linux distro advertised for "old computers" these days really
> only targets PII w/ 128 or 256 MB of RAM. They don't know minimal. It
> must be really hard, even with 2.4.x, I dunno. Even DeLi Linux (using
> uClibc) had to up its requirements when they switched to Unicode for
> 0.8.0, sadly.
There is a minimal DeLi 0.8.0 console-only version that runs in very
small amounts of RAM, but I'm unsure what exactly it can do. And of
course the new TinyCore (off-shoot of DamnSmallLinux?), and it's
little brother MicroCore, seem promising, at least regarding size.
But anyways, FreeDOS will always have lower requirements. (And 2038
final was just released like yesterday, finally, see Sourceforge.)
Viva la DOS! ;-)
- Raw text -