Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
Quoting Gregory Boyce <gboyce-qL0WqcyiFk9Wk0Htik3J/w at public.gmane.org>: > On Mon, 22 Dec 2008, Derek Atkins wrote: > >> Neither of which are reasonable choices, the latter even more-so. I >> used a disk driver as an example concept -- this has nothing to do >> with a physical piece of hardware per se. > > The current approach works fine unless you can't access the necessary > files during the early boot process. This means either disk > controller or possibly networking in cases where you're network > mounting filesystems. > > How many disk controllers out there actually require proprietary drivers? You're right that the approach works unless you can't access the necessary files during the early boot process. However there are more reasons than just disk or network controllers. Unfortunately I cannot go into more detail at this time, but just trust me that other issues exist in this category. >> What I'd like to see is a dkms solution that works based on RPM >> install triggers... So when you install a new kernel package it >> automatically fires off the rebuild without requiring a reboot. > > This would be a reasonable approach if you wanted to tie into a > particular package management system. I'm guessing their approach > was an attempt to be package manager agnostic. I'm happy to tie into a particular package management system. It means I only need to write my packaging twice, once for RPM and once for DPKG. That's fine with me. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warlord-DPNOqEs/LNQ at public.gmane.org PGP key available
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |