FreeBSD and Information handling
Hi, I was wondering if there was any tool available in freebsd for handling information, specifically configuration files, package information and such. I know all information is available via text files however in order to access the information the program might have to hard code the retreval system (not being able to use a shared library). So: 1) What tools are there for accessing information (i.e. libraries)? 2) If so is there any unification of the interface? 3) If no to any of the above, is there a need for such tools and should it be a unified interface (not just specific subsets)? David pgpO5c5MBTP0T.pgp Description: PGP signature
Re: FreeBSD and Information handling
On Saturday, 16 June 2007 at 14:22:50 +0200, David Naylor wrote: Hi, I was wondering if there was any tool available in freebsd for handling information, specifically configuration files, package information and such. I know all information is available via text files however in order to access the information the program might have to hard code the retreval system (not being able to use a shared library). So: 1) What tools are there for accessing information (i.e. libraries)? 2) If so is there any unification of the interface? 3) If no to any of the above, is there a need for such tools and should it be a unified interface (not just specific subsets)? David Hi David. If you want to automate your administrative task your might want to look at puppet or cfengine. -- == - Best regards, Nikolay Pavlov. --- == ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD and Information handling
David Naylor wrote: So: 1) What tools are there for accessing information (i.e. libraries)? 2) If so is there any unification of the interface? 3) If no to any of the above, is there a need for such tools and should it be a unified interface (not just specific subsets)? If everything goes OK, the backend server from finstall could offer something like that. (http://wiki.freebsd.org/finstall). The lan is to finish the prototype in python, then rewrite it in C for inclusion in the base system (though this particular part needs some high-level discussion), so this is not something that will happen soon. signature.asc Description: OpenPGP digital signature
Re: Fwd: AMD deciding _now_ what to do about Linux
So who, exactly, is the best person to write to requesting docs for AMD/ATI graphics/video chips? We need to politely inform them that There are a lot of operating systems out there, and they all need high quality, fully functional drivers. FreeBSD, NetBSD, OpenBSD, Plan-9, Open-Solaris, ... We might want to add a ATI graphics/video card to a computer with a different CPU architecture (Alpha, Sparc, PPC, ...) Binary drivers are useless, because: Too many OSes. Too many CPU archs. Can't fix bugs. Can't fix security holes. Therefore we need documentation on how to program the chips. 2D is not enough. We need video decoding and 3D. If we can't have high quality, fully functional source code drivers for the OS and CPU arch of our choice, then there is no reason to buy the product. Have I left out anything? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fwd: AMD deciding _now_ what to do about Linux
On Sat, Jun 16, 2007 at 10:33:00AM +0100, Dieter wrote.. So who, exactly, is the best person to write to requesting docs for AMD/ATI graphics/video chips? We need to politely inform them that There are a lot of operating systems out there, and they all need high quality, fully functional drivers. FreeBSD, NetBSD, OpenBSD, Plan-9, Open-Solaris, ... We might want to add a ATI graphics/video card to a computer with a different CPU architecture (Alpha, Sparc, PPC, ...) Binary drivers are useless, because: Too many OSes. Too many CPU archs. Can't fix bugs. Can't fix security holes. Therefore we need documentation on how to program the chips. 2D is not enough. We need video decoding and 3D. If we can't have high quality, fully functional source code drivers for the OS and CPU arch of our choice, then there is no reason to buy the product. Have I left out anything? Well.. yes. How much revenue ($$) AMD will loose when these open source projects do not get the chip docs. Ultimately the $$ question is what exec level management will ask. -- Wilko Bulte [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fwd: AMD deciding _now_ what to do about Linux
Wilko Bulte wrote: On Sat, Jun 16, 2007 at 10:33:00AM +0100, Dieter wrote.. So who, exactly, is the best person to write to requesting docs for AMD/ATI graphics/video chips? We need to politely inform them that There are a lot of operating systems out there, and they all need high quality, fully functional drivers. FreeBSD, NetBSD, OpenBSD, Plan-9, Open-Solaris, ... We might want to add a ATI graphics/video card to a computer with a different CPU architecture (Alpha, Sparc, PPC, ...) Binary drivers are useless, because: Too many OSes. Too many CPU archs. Can't fix bugs. Can't fix security holes. Therefore we need documentation on how to program the chips. 2D is not enough. We need video decoding and 3D. If we can't have high quality, fully functional source code drivers for the OS and CPU arch of our choice, then there is no reason to buy the product. Have I left out anything? Well.. yes. How much revenue ($$) AMD will loose when these open source projects do not get the chip docs. Ultimately the $$ question is what exec level management will ask. Countering the above statements (the following are important questions to answer, and should be done by their business types with more hard data): How much money will AMD lose on competitive edge versus market segment share for the particular open source customer base? How much of the ATI drivers will they have to modify in order to ensure that they remain IP protected and the extremely proprietary sections don't get put out in the open by accident? -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fwd: AMD deciding _now_ what to do about Linux
On Sat, Jun 16, 2007 at 02:16:48PM -0700, Garrett Cooper wrote.. Wilko Bulte wrote: On Sat, Jun 16, 2007 at 10:33:00AM +0100, Dieter wrote.. So who, exactly, is the best person to write to requesting docs for AMD/ATI graphics/video chips? We need to politely inform them that There are a lot of operating systems out there, and they all need high quality, fully functional drivers. FreeBSD, NetBSD, OpenBSD, Plan-9, Open-Solaris, ... We might want to add a ATI graphics/video card to a computer with a different CPU architecture (Alpha, Sparc, PPC, ...) Binary drivers are useless, because: Too many OSes. Too many CPU archs. Can't fix bugs. Can't fix security holes. Therefore we need documentation on how to program the chips. 2D is not enough. We need video decoding and 3D. If we can't have high quality, fully functional source code drivers for the OS and CPU arch of our choice, then there is no reason to buy the product. Have I left out anything? Well.. yes. How much revenue ($$) AMD will loose when these open source projects do not get the chip docs. Ultimately the $$ question is what exec level management will ask. Countering the above statements (the following are important I would not call that countering, I think we agree? questions to answer, and should be done by their business types with more hard data): How much money will AMD lose on competitive edge versus market segment share for the particular open source customer base? And is that enough to be noticable in the grander (MS-Windows) scheme of things How much of the ATI drivers will they have to modify in order to ensure that they remain IP protected and the extremely proprietary sections don't get put out in the open by accident? The outcome might even be that this is not worthwhile for them.. (blackest possible outcome, I agree). -Garrett -- Wilko Bulte [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using shell commands versus C equivalents
Tim Kientzle wrote: As Joerg said, though, you're not likely to gain much from this. pkg_install is almost entirely disk bound. Going back to this particular comment, has anybody really looked into the speed of mtree(3)? That was the next stop that I planned on looking at after I make my changes, in terms of fchown(2) and friends. Also, were the bottlenecks seen in pkg_delete and pkg_add, or does it appear to be distributed across the board? Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using shell commands versus C equivalents
Also, were the bottlenecks seen in pkg_delete and pkg_add, or does it appear to be distributed across the board? The biggest time sink in pkg_add is writing each file to a temp dir then copying it to its final location. There are a couple of strategies for avoiding this (by writing the files directly to their final location), but it basically requires rewriting pkg_add from scratch. I prototyped this a long time ago and found about a 3x speedup. (Parts of that prototype eventually became libarchive.) I haven't looked closely at pkg_delete, but I doubt there's much that can be done to speed it up; once you've examined the dependency information to determine what can be deleted, actually removing the files is a pretty straightforward operation. The two operations that people focus on performance issues have been index rebuilding (which requires inspecting every port in /usr/ports) and update (which requires inspecting every installed port). The modular Xorg is especially going to stress updates, since it greatly increases the number of ports on the average system. One useful tool: truss can include timing information that can give a lot of insight into where a program is really spending time. Tim Kientzle ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
