Date: Mon, 14 May 2007 21:39:26 +0200 From: "'Michel Talon'" <talon@lpthe.jussieu.fr> To: Tom Evans <tevans.uk@googlemail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: DPS Initial Ideas Message-ID: <20070514193926.GA24449@lpthe.jussieu.fr> In-Reply-To: <1179161318.1791.32.camel@zoot.mintel.co.uk> References: <20070514082512.GA25544@lpthe.jussieu.fr> <1179161318.1791.32.camel@zoot.mintel.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, May 14, 2007 at 05:48:38PM +0100, Tom Evans wrote: > On Mon, 2007-05-14 at 10:25 +0200, 'Michel Talon' wrote: > > Where is this huge increase in size? > > Admittedly, i have not created indexes, etc. > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Compare this to the portsdb created by portupgrade from the same INDEX-6 > > > > niobe% ls -lh /usr/ports/INDEX-6.db > > -rw-r--r-- 1 root wheel 21M 16 fév 13:36 /usr/ports/INDEX-6.db > > > > Surprise, surprise, the BerkeleyDB suddenly appears less glorious. > > Your index has no indices, and you wonder why it is smaller? I am really tired answering questions about straw man, misrepresentations of my position, and so on. I don't advocate using XML, nor java, nor java tools nor anything of this sort. I am only claiming that SQLite does a better job than a BerkeleyDB for the precise mission that it seems the BerkeleyDB is programmed in the SOC. As to the question of indices i am the one who pointed out there are no indices, so there is little merit inventing this new objection. Moreover the objection is completely bogus, because SQLite creates the index in memory. After the following command sqlite> create index path_ind on index6(path); (i have created an index on origins, the only question of interest) the size of the database doesn't change at all! It remains twice smaller than the BerkeleyDB. But the memory consumption augments. here are the values before and after creation of index: USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME COMMAND michel 1174 0,0 0,2 2984 2324 p2 I+ 21:03 0:00,01 sqlite3 michel 1174 0,0 0,6 6728 6068 p2 S+ 21:03 0:00,34 sqlite3 By the way, i don't concern myself with the problem of accelerating package registration or similar stuff. Indeed most of these problems can easily be solved by some optimizations in the makefile and parallelism. The true problem, as Kris said, is the problem of upgrading an installation in a reasonable time -that is, not several days- and with *total* reliability. None of present FreeBSD tools do that, while it is common place with Debian. This is an extremely difficult problem in the FreeBSD context as des said, and i am certainly not able to solve it. But at least i have researched the question and written some code. It is perfectly obvious that most of the bikesheds in this thread are due to perfect ignorance of the subject, which could be remedied reading: http://www.lpthe.jussieu.fr/~talon/freebsdports.html and the small SQLite documentation at: http://www.sqlite.org/lang.html -- Michel TALON
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070514193926.GA24449>