Martin, > -----Original Message----- > From: Martin Hejl [mailto:[EMAIL PROTECTED]
> I understand what you're saying - and I guess the framework > (scripts to handle the update proces) would surely make their > way into the Bering uClibc distro. At this point, I'm just > not sure if there's enough interest in the leaf userbase to > warrant spending business hours on this (I already spend much > of my spare time on Bering uClibc, but that's a different matter :-)) > > As I said - nothing is set in stone at this point, we're > still in the decision making process, so we're surely open > for suggestions. In the end, it all comes down to the fact > that we need to make sure we're not putting in a lot of money > and resources into a project that will not at least create > some return over a reasonable amount of time. We're not a > huge corporation, so we can't pump huge amounts of cash into > a project that will not pay for itself at some point. If a > model where people pay for the "premium service" > (notification of updated packages, maybe even a "push model" > for some sort of "auto-update" - even though I have rather > strong reservations about updates being installed without the > administrator knowing about it) works even if the same > packages are published for free on the website, I don't see > why things couldn't be done that way. I think your on track with the key point that it all depends on what the interest would be. I have no doubts that it would be fairly easy to create enough value added for a premium service that anyone with $ could not live without. The question is just how many of these people are there? To put it another way, how many LEAF firewalls are deployed in production by companies or other NGO's? I think that every one of these entities would be hard pressed to not buy into such a service if it was cheap and provided otherwise unavailable assurances that their LEAF install is secure. As to the service, I guess you would have to monitor one or more sources that track security issues and other vulnerabilities in Linux programs and match them up against what is included in each of one or more uClibc versions to determine if any updated LRP's need to be created and disseminated. This service could also include notices of issues that may not require a new LRP but may have to do with configuration settings that may be insecure or cause issues. Can anyone else out there respond with their interest???? Richard ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf ------------------------------------------------------------------------ leaf-user mailing list: [email protected] https://lists.sourceforge.net/lists/listinfo/leaf-user Support Request -- http://leaf-project.org/
