IDEA: To tackle the driver issue & avoiding binary blobs, the project should focus on ONE hardware platform (until the project solidifies, then consider porting).
Commodore 64 was immensely successful, and only had one set of hardware to support. Also, look at the success of the Raspberry Pi. Focus all effort into supporting one piece of hardware, then grow from there when possible. Preferably open-source hardware. (lemote anyone?) But focusing back on Linux kernel, their direction is questionable. Linus himself hates security. He doesn't care. That mentality will trickle down. On Mon, Nov 3, 2014 at 9:13 AM, Samuel Thibault <sthiba...@debian.org> wrote: > Jeremy, le Mon 03 Nov 2014 09:03:25 -0500, a écrit : > > if only the kernel were replaced, the rest would still work as we al > > like it to. (This is evident with Debian GNU Hurd & kFreeBSD projects). > > It's not so easy :) > > > We all hear everyone say "The code is open for anyone to look for > > exploits" but DOES ANYONE ACTUALLY DO IT? Or does everyone think > > someone else is going to do it, so they don't worry about? > > You'll end up with contradictory issues: having driver support and > having people look at the code. The non-driver parts of the kernel are > quite well looked at. Drivers, much less. Research has shown that > it's there that most bugs lie. And taking another kernel won't really > change that issue (if the other kernel is actually at all shipping other > drivers than just picking up Linux'). > > Samuel >
