From owner-freebsd-hackers@FreeBSD.ORG Fri May 11 16:13:06 2007 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 2386A16A403 for ; Fri, 11 May 2007 16:13:06 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.freebsd.org (Postfix) with ESMTP id A14AF13C45B for ; Fri, 11 May 2007 16:13:05 +0000 (UTC) (envelope-from freebsd-hackers@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HmXU2-0008Gp-Vw for freebsd-hackers@freebsd.org; Fri, 11 May 2007 17:56:43 +0200 Received: from lara.cc.fer.hr ([161.53.72.113]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 11 May 2007 17:56:42 +0200 Received: from ivoras by lara.cc.fer.hr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 11 May 2007 17:56:42 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org From: Ivan Voras Date: Fri, 11 May 2007 17:54:09 +0200 Lines: 86 Message-ID: References: <200705102105.27271.blackdragon@highveldmail.co.za> <4643C7DB.6000408@elischer.org> <17988.35412.231093.411177@bhuda.mired.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA0F802F6F6CE7264877492FB" X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: lara.cc.fer.hr User-Agent: Thunderbird 1.5.0.10 (X11/20060911) In-Reply-To: <17988.35412.231093.411177@bhuda.mired.org> X-Enigmail-Version: 0.94.2.0 Sender: news Subject: Re: SQL in the base system X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2007 16:13:06 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA0F802F6F6CE7264877492FB Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Mike Meyer wrote: >> Perhaps this is a good time I should mention that I think sqlite would= >> also be good for the password and login databases? :) >=20 > Someone has already pointed out the horror that is the Windows > registry. IIUC, even MS has figured out this is a bad idea, and gotten > away from it with Vista. But it's been tried on Unix systems before as This is the first time I hear about Vista - AFAIK it relies even more on = registry, to the point that the boot process also uses it. Registry was pretty bad in Win9x, but AFAIK most of those issues were=20 because FAT32 is a bad file system. I never had a registry problem (on=20 many machines) running Win2k and WinXP. > Using a binary format brings it's own problems. How hard is it to fix > a corrupt database? How hard is it to figure out that the database is > so corrupt you aren't going to get anything out of it, so you might as > well give up? How robust is it - can a corrupt block fry the entire > database? How about portability - can I move the file to a completely > different architecture and still get the data from it? If any of these > are noticably worse than they are for text files, changing is probably > not a good idea. Most of those issues are valid, but don't strongly advocate against=20 databases, because the same issues (corruption, rebuilding, manual=20 inspection) are present for directories of text files. Endian issues are = solved in sqlite. I don't think databases are so scary (but possibly that's lack of=20 experience on my part). If you would get a corrupt block in the middle=20 of a complex text file, it would wedge your system just as bad as if you = got a bad block in a table in the database (anecdotally, sqlite database = can be read even in those circumstances, if you avoid the corrupt=20 table). (And a corrupt block in an important metadata section is the=20 same as a corrupt block in the directory record on the file system). The = objective downside is that there are more blocks in a database. > Someone else mentioned XML. Well, it's easy to parse - assuming you > read that as "someone else wrote the parser for us". That's true for > lots of things. I also question the sanity of using it. But I wind up > doing a lot of it, because my clients like the buzzword compliance. I > regularly beat on them to take advantage of what XML can do that other > formats can't. Meaning I make them install validation software, and > pay me to write schemas for them, and get them to add hooks to the > repository so you can't check in xml files that don't validate. But if > you're not going to do that kind of thing, the major feature XML > brings is the buzzword compliance. Bofore I get misunderstood, I'd like to say that I'm not actually such a = big fan of XML, but I think it's currently the lesser of evils. The=20 alternative is either to create a one-off file format for each and every = purpose (aka "the unix way"), or use some XML-replacement (JSON &=20 others) which has most of the evils of XML and introduce lack of support = from existing tools. --------------enigA0F802F6F6CE7264877492FB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFGRJGtldnAQVacBcgRAo22AJ9m/aws78NY/jbgLEwV98L9E++3NwCglfwN aV3f2xwPd/Yje/fUIvfFF/s= =m8Eq -----END PGP SIGNATURE----- --------------enigA0F802F6F6CE7264877492FB--