Hey All,
I have decided to take the initiative of switching to a better delivery system for the next revision of Driver On Demand.
DKMS is a driver management system designed by Dell released under the GPL, that not only supports both binary and source packages, but can also patch the source for specific versions of the kernel.
Directly from Dells site: DKMS stands for Dynamic Kernel Module Support. It is designed to create a framework where kernel dependent module source can reside so that it is very easy to rebuild modules as you upgrade kernels. This will allow Linux vendors to provide driver drops without having to wait for new kernel releases while also taking out the guesswork for customers attempting to recompile modules for new kernels.
Another major benefit is that upgrading drivers is significantly safer, because you can easily switch between versions, use RPM based packages, rollback drivers, and uninstall them easily.. Basically, everything we wouldn't have had before.
What I am really seeking now is other companies opinions of DKMS.. It is GPL so i believe it to be a great choice, however, I'd like to know if anyone has any problems with it..
The use of DKMS will also dramatically reduce the complexity of the driver definition files, and prevent the need for reinventing the wheel. It also prevents the creation of a new unneccessary standard. One problem in the past with linux has been that there have been many different packaging systems. My hope is that DKMS, and the use of XML based driver definitions will be extendible enough to last years into the future.
Thank you for all your support.
Saturday, September 18, 2004
Monday, September 13, 2004
New Logo and possible consortium needed
Hey all,
Finally, I have the new logo online, designed by Andreas Nilsson, as you can see on the side menu. Hopefully this symbol will remain one in the future that represents Linux device drivers.
One thing that I have discussed about is that there are two different types of driver management systems... Ones which utilize an existing package manager, and one which utilizes its own package management system. The issues have always been that ones that don't hook into existing package managers can't easily tell which packages need installing well (there are ways of allowing them though), and the problem with using the existing ones is that many repositories will be needed, which will scare away driver developers
Jono Bacon (the brainstorm behind the article posted) agrees with me that distro developers need to step forward, representing a large amount of distro's and need to collaborate to develop a common standard this time. People would lose faith in a system if there are 600 different standards for it, so this time we need to do it right the first time (possibly use a portage like system?).
One issue with trying to make packages work on every distro has been that some distro's don't follow the Filesystem Hierarchy standard (ie. some put /etc in /config etc). My idea was to develop a bunch of standard environment variables covering all the standard locations, which make scripts would use etc.
Phase 1 of such a process would be to at least allow compile time compliance with the system, and phase 2 might be to allow full runtime compliance (would be nice to have it so that users could even move /config to wherever they dream, but that's not going to happen).
Someone on freedesktop mentioned that such a standard is already being designed http://freedesktop.org/Standards/basedir-spec/basedir-spec-0.6.html
It seems though that it is only for home directories, not the entire filesystem, so I am thinking of quickly spending my weekend designing one for the entire filesystem
Finally, I have the new logo online, designed by Andreas Nilsson, as you can see on the side menu. Hopefully this symbol will remain one in the future that represents Linux device drivers.
One thing that I have discussed about is that there are two different types of driver management systems... Ones which utilize an existing package manager, and one which utilizes its own package management system. The issues have always been that ones that don't hook into existing package managers can't easily tell which packages need installing well (there are ways of allowing them though), and the problem with using the existing ones is that many repositories will be needed, which will scare away driver developers
Jono Bacon (the brainstorm behind the article posted) agrees with me that distro developers need to step forward, representing a large amount of distro's and need to collaborate to develop a common standard this time. People would lose faith in a system if there are 600 different standards for it, so this time we need to do it right the first time (possibly use a portage like system?).
One issue with trying to make packages work on every distro has been that some distro's don't follow the Filesystem Hierarchy standard (ie. some put /etc in /config etc). My idea was to develop a bunch of standard environment variables covering all the standard locations, which make scripts would use etc.
Phase 1 of such a process would be to at least allow compile time compliance with the system, and phase 2 might be to allow full runtime compliance (would be nice to have it so that users could even move /config to wherever they dream, but that's not going to happen).
Someone on freedesktop mentioned that such a standard is already being designed http://freedesktop.org/Standards/basedir-spec/basedir-spec-0.6.html
It seems though that it is only for home directories, not the entire filesystem, so I am thinking of quickly spending my weekend designing one for the entire filesystem
slashdotted
This was an unexpected surprise.. Front page of Slashdot.
http://linux.slashdot.org/article.pl?sid=04/09/12/2227228&tid=137&tid=185&tid=106
Guess I should be thanking Jono Bacon for his excellent, and sorely needed article, as well as prostoalex and timothy for posting it.
it also appeared in OSnews the other day too http://www.osnews.com/comment.php?news_id=8226.
Seems there were some good ideas coming from people, and I rarely saw a bad post too, so maybe I should start working harder on it again. I have actually been thinking of using a portage like system, as the current 8 gig DVD's can accommodate compilation tools and the necessary packages to compile drivers during the install process. Anyway, I guess I'll do some more research on the new architecture required.
http://linux.slashdot.org/article.pl?sid=04/09/12/2227228&tid=137&tid=185&tid=106
Guess I should be thanking Jono Bacon for his excellent, and sorely needed article, as well as prostoalex and timothy for posting it.
it also appeared in OSnews the other day too http://www.osnews.com/comment.php?news_id=8226.
Seems there were some good ideas coming from people, and I rarely saw a bad post too, so maybe I should start working harder on it again. I have actually been thinking of using a portage like system, as the current 8 gig DVD's can accommodate compilation tools and the necessary packages to compile drivers during the install process. Anyway, I guess I'll do some more research on the new architecture required.
Subscribe to:
Posts (Atom)
