Re: [MiNT] Sparemint Site/Updater

[Mark Duckworth <mduckworth@atari-source.com>]

On Sat, 2005-08-06 at 16:21 -0600, evan@coolrunningconcepts.com wrote:
> Quoting Mark Duckworth <mduckworth@atari-source.com>:
> 
> > Eh.. I dunno.  :)  I've heard good things about sqlite and I figure it's
> > extensible later.  Plus I wasn't aware gdbm has a sql interface.  I like
> > sql.
> 
> No, no direct SQL interface, its more of a disk-based hash.  You ask 
> for a key,
> it gives you a value.  To do a full table, you'd need multiple GDBM files.
> 
> > more than welcome to.  Right now however, I think I'll continue to do it
> > my way, because despite the advantages of pipe(), the integrated way has
> > the most pertinent advantage - it's how I feel like doing it ;)
> 
> Interesting attitude.

As with ozk said on WCOWORK and XaAES, I can always just stop working on
it.  It's not that big of a deal, don't make it out to be one.  GDBM
sounds like a hassle still.  I wanted something high level, fast, and
easy.  Sqlite3 fits the bill 100%.  It was exactly what I expected api
wise.  And I don't know why everyone hates that attitude.  While I am
doing it for the community, I'm mostly doing it out of my own
need/desire.  You know, I wrote gim and asked for suggestions and very
few people gave me any and even fewer people use it.  When it comes down
to it, I wrote it for myself.  While I expect sum to be more widely
used, I don't expect a lot of people in terribly limited ram situations
to be using it... and ram is the only real reason besides "properness"
to separate the gem from the console portion.  And it doesn't even need
to sit in ram, you can just set a cron job to run it.  The binary size
of ssh is something like 2 megs or something, the binary size of sum is
600K and it's not likely to get much bigger.  - and I guarantee most of
that is libs that need to be linked into the console binary anyway.  AND
- by unleashing it as GPL I'm giving anyone permission to implement it
however THEY want to.. But before this we had nothing even remotely
similar working thanks to the old version of rpm and the fact that
because of static libs, a build of rpm-python is nearly IMPOSSIBLE.
Finally, I think I'd rather be an asshole (or wrong) who puts forth the
effort then the nice guy who will let everyone else push him around for
what amounts to no good reason.  At least my way things will get done
because I won't be screwing around with stuff I don't know well - and
thus will be very slow to implement.

Besides only you and Standa spoke up so the idea isn't universally
hated ;)  And I know I could convince Standa of the virtues of my way
probably.  You're the unconvincable one around here ;)  Also if you look
around, the smart package manager is designed the same way, as is
redhat's up2date, as is octopus bbs, as is other applications.  To me it
makes good simplistic design sense.  The only separated ones are apt
which doesn't even have a gui interface AFAIK and yum which has a VERY
poor gui interface.

Thanks,
Mark