Re: Progress Update

[Pierre Phaneuf <pp@ludusdesign.com>]

Christian Reiniger wrote:

> > I just felt that discussing THE most optimized algorithm for such a
> > relatively unimportant part of the system is the kind of thing that
> > makes projects of the scope of PenguinPlay bog down. Heck, regular Unix
> > ufs uses a darn ARRAY for directories entries!
> 
> And because that is too slow in many case modern file systems (reiserfs,
> ext3 and AFAIK also xfs) use trees for that. We can't optimize much in the
> area of file reading, but we can do *much* in the area of file opening -
> and considering that many games operate with hundreds to thousands of small
> files the speed gain from this isn't as little as it may seem.

Note that Unix ran for more than 20 years without trees for directories.
:-)

And you're not thinking that FAT or NTFS might have trees? ;-))

(Actually, I do not know for NTFS, but it is so slow, it probably
doesn't matters anyway if it has trees or not)

I'm not saying that you shouldn't use your HashTable for directories.
I'm just saying that putting so much effort into something so easily
fixable later on (I'm assuming good modularity here) is *not* helping
PenguinPlay as a project. It isn't the first time that PenguinPlay "dies
out", maybe this is a reason.

PenguinFile is only the tip of the PenguinPlay iceberg!

You should just make sure that your global design is modular enough so
that things are "fixable" later on. Heck, I would have prototyped this
with a crappy linked list! But since it is hidden from the user anyway
(I used a set/get/remove hashtable-like interface), I would go later on
and fix it. Heck, it could prove to be totally sufficient and I'd just
spare me the whole trouble!

The *real* problem is where you have stuff that is inherently badly
designed and unfixable.

> >that they were the best machines and environments ever conceived. Don't
> >get pedantic with that last 10% of work, Unix is *FINE* without it, see?
> 
> No ;)
> There are several parts in Un*x etc where it's just "good enough" instead of
> "as good as possible". And from time to time these pieces hurt (Ever
> wondered about the bad performance of NFS and telnet? Ever wondered why it
> is so hard to do graphics on the console?)
> "Just making it work" is almost always bad, planning a bit more to "make it
> work fine" is often good, but sometimes "doing it properly" is the right
> way.

Yes, but I gave you the perennial example of a system that "did it
properly" and went straight to the garbage dump.

Unix is mostly fixable, *that* is what took it from the 70's right up to
now. The old filesystem was too slow, they improved on it without
changes to the applications, and this is about to happen again (with
ext3/reiserfs/xfs). Note that every spots where we have problems is
mostly because of compatibility/encapsulation issues, like going from
/etc/passwd to /etc/shadow to LDAP authentication for example.

Read this page for further enlightenment on this matter:
http://www.jwz.org/worse-is-better.html

The full paper can be found at
http://www.ai.mit.edu/docs/articles/good-news/good-news.html

> >Where does PenguinPlay want to be? On all the Linux machines? Or in the
> >garbage dump?
> 
> On all Linux, Windows, Irix, BeOs and Mac machines. At the very
> least. And for that to archieve it has to be good.
> And PenguinFile is now only about one week from the "debugging and
> polishing" phase.

Good, but think about *how* you'll get there. Think about how to make a
"perfect computer virus", such as Unix and C were.

Life and evolution rates success by one factor: population.

The idea isn't to get a perfect design, it is to get the best possible
design that will *succeed*. Such are engineering compromises.

-- 
Pierre Phaneuf
Ludus Design, http://ludusdesign.com/
"First they ignore you. Then they laugh at you.
Then they fight you. Then you win." -- Gandhi