Mail Archives: djgpp/2009/05/18/23:01:49
On Sat, 16 May 2009, Rugxulo wrote:
> Hi,
>
Hi,
Here come a few rants inspired by your observations on the
ever increasing software sizes. (Also, I have rants about
glibc2 threads, UTF-8, and an interesting comparison of
gzip - compress - bzip2 and cat, but I'm saving those for
another day.) I do, however include a little bit of
conspiracy theory right away (well, not really right away:
you may have to skip some paragraphs to get there)...
enjoy, while I catch some sleep!
> On May 14, 1:40 am, Blair Campbell <blaird DOT DOT DOT AT gmail DOT com> wrote:
> >
> > I recently compiled perl 5.10.0 with DJ-ELF and it sometimes comes in
> > handy to have perl with some modules for configure scripts.
>
> 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. Not saying Perl
> isn't useful, but it bothers me that everything was Perl 5 forever
> (why? was Perl 4 useless?). Perl 6 has been in planning for a long
> time, several rough implementations exist, but it's incompatible
> (another rewrite).
>
> perl561 exe 1,192,448 Dec,15,2003 11:03:24pm A...
> perl588 exe 4,330,496 May,11,2007 03:03:20am A...
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.
(Other distributions of Linux, such as Slackware, are
significantly, but not satisfactorily better.) (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.)
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... Perl
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. 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. The 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. (Although I suppose it must be acknowledged
that scripts may have advantages such as portability, once the
interpreter has been ported.)
Interestingly, it's not DOS/Win9x that has the worst problems
with the above trends, but aging Unix systems. A shining
example follows (in spite of the fact that objdump is at least
a compiled executable rather than a perl or python script (but
maybe we'll get there?), and it can be quite useful at times,
but not this time):
# objdump -m vax -b binary --start-address=0xd4e7e -D /kmem-page80000plus.dump|more
objdump: Can not allocate 33296384 bytes after allocating 30504 bytes
I bet it was planning to read the whole dump of all 32 MB of
memory the machine has into... memory? ...before starting to
disassemble the 13 bytes or so that I needed [1]; fortunately,
the error caused it to abort the plan before wasting too much
of my time. I'm pretty sure that a real mode DOS or a PDP/11
programmer wouldn't even think about doing something so
ridiculous (I know I don't; and yes, I am sporadically working
on both a VAX disassembler and a x86 one): or in other words,
memory barriers have a positive influence on programming habits
and resulting code.
> 3,920,947 Python-2.0.1.tgz
> 6,410,852 Python-2.2.3.tgz
> 8,154,677 Python-2.4.6.tar.bz2
> 11,156,901 Python-2.6.2.tar.bz2
>
> bloated as it looks. Python 2.0's main addition was Unicode, and then
> came 2.2, 2.4, 2.6.2 is latest "compatible" with a few backported
> features while 3.1b1 (beta) is the incompatible branch. Just like Perl
> 6, they will support some automatic translation between old 2.x and
> new 3.x, but it just seems like such a moving target, I just wonder
> how useful something is if it gets deprecated so quickly.
"Deprecated"... Could that be a conspiracy to force you to
"up"grade to the latest bloatware, because older code will
no longer work (as it's too full of "deprecated" stuff)?
> 207,202 lua-5.1.4.tar.gz
>
> Now I know why Lua is so popular, it's tiny!!
I was discouraged from trying it a few years ago, because
they wrote that they don't support integers, only floating
point, and integers (of which pointers are a special type,
as far as I'm concerned) are what I need almost exclusively.
However, the surprisingly reasonable size suggests that
there may be something good about Lua as well (and maybe
they fixed the data types?).
> Why they didn't just use that instead of Python for
> GDB 7.0 I'll never know.
Python is indeed heavy stuff... the Mailman mailing list
management system that I used to run on a Pentium 60 MHz [2]
was written in Python and had an appetite for resources
like no other process on the system; for comparison, the
SMTP and web servers easily handled their parts of the
job (of running the list) with quick response times.
(I wonder if DJ has similar reasons for writing and
running his own flavour of list management system...?)
Returning to the topic of scripting languages (although
the language I'm going to mention can also be compiled) -
What about Forth? It's a language I've heard great things
about, but I haven't looked into it sufficiently to confirm
its excellence. Among other things, it's used in some boot
loaders and console firmwares (ie. BIOS-like systems that
support early stages of hardware initialisation and booting),
and if my recollection is correct, the Sun Sparc is one
example of such a system, but it may be used in some other
"alternative" alternative architectures too.
-aw
[1] ... 13 bytes or so, which I needed In order to decide
precisely what and where to patch. It all turned out all
right in the end, after copying a 32 byte chunk out of the
memory dump with "dd" and using objdump on that. Patching was
then a matter of looking up instruction bytes to assemble
(from a book or data sheet) and using printf "\x8F\x00,,,etc",
piping its output into "dd" with the right parameters to
specify the target file offset within the kernel image file,
and last (as well as least), rebooting. (Just remember
"conv=notrunc" also, or dd will truncate the kernel.)
[2] Yes, the one with the FDIV bug!
- Raw text -