Date: Fri, 12 Jul 2002 20:09:48 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Kutulu <kutulu@kutulu.org> Cc: arch@freebsd.org Subject: Re: Package system flaws? Message-ID: <3D2F99FC.61337E12@mindspring.com> References: <200207120055.g6C0tbpQ084565@dotar.thuvia.org> <3D2F5602.9039F5DE@mindspring.com> <002401c22a12$57659c10$fe663244@KutuluWare>
next in thread | previous in thread | raw e-mail | index | archive | help
Kutulu wrote: > While I agree in general with this logic (that just because it's Microsoft's > idea doesn't automatically make it bad), even THEY eventually concluded that > the registry was a really bad way to manage a centralized software "package" > database (COM components), and are moving towards a more directory-based, > localized package management system with XP/.NET. That's not really what they concluded, if we want to be honest about things. A hierarchical data store is a hierarchical data store. Doesn't matter if it's an FS, a registry, an LDAP directory, a DNS server, or FreeBSD's use of "_" as a path component seperator in /etc/rc.conf ...hierarchical is hierarchical. The choice of implementation technology is totally seperate from that of structure; it only becomes an issue when you need to look data up. Finding one tag in one of a thousand files is, to be blunt, computationally Very Hard, which was one of the arguments originally put forward against the NetBSD RC system, before it was understood that configuration data remained centralized, and that one could assemble and cache a single script instance. The COM component registration model is actually a good model, since the issue is to ensure uniqueness within the namespace; it fails under ongoing maintenance because it picked uniquifiers that were not invariant between maintainers of a particular set of code, or even the same maintainer, over time: the MAC ID of the ethernet car in the workstation used to perform the component definition. COM failed because the variant part failed to group derivative works, as they had hoped it would. It also failed because of the method of interface versioning they selected, but moving to files doesn't fix the lack of major/minor numbers in the file naming conventions (the Visual C RunTime Library puts the version number in the file name, *without establishing a convention*, in order to get around this same problem). In other words, their failures were not attributable to their use of a hierarchical data model (structure), but to their selection of hierarchy identifiers (selection of identifier can be stretched to fit under "implementation technology", even if I'd argue that it's a third, and therefore totally irrelevant, factor). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D2F99FC.61337E12>