2014-08-21 15:15 GMT+02:00 Alexander von Gluck IV <kallisti5@xxxxxxxxxxx>: > On , Ingo Weinhold wrote: > >> On 20.08.2014 18:26, Sia Lang wrote: >> >>> On Wed, Aug 20, 2014 at 6:02 PM, Ryan Leavengood <leavengood@xxxxxxxxx >>> <mailto:leavengood@xxxxxxxxx>> wrote: >>> It is a lot to ask the Haiku community to abandon our current >>> approach >>> for what sounds like a prototype. >>> >>> Totally agree, I'm not asking anyone to jump ship and join me. >>> >>> I am however asking the Haiku community to consider if the kernel choice >>> made 14 years ago still makes sense. It's painful to leave a huge amount >>> of work behind in the dust, but there's still so much Haiku work that >>> would have a great life on top of a Linux or BSD based BeOS. With all >>> the up-sides mentioned before (busses and drivers abound!) >>> >> >> Unless I miss someone, of the Haiku developers (counting committers >> only) who posted in this thread no one strictly opposed the idea of >> switching to another kernel and most even seem to consider this an >> interesting option. >> > > -1 > > Fixing the few remaining kernel bugs and getting a release out is more > important than trying to move everything over to a Linux kernel (which > would > likely push any further releases back *years* given our current workforce.) > > Yes, it is rough to keep up with hardware drivers. However it can be done > and > we do support a *lot* of hardware at the moment. Do we support the latest > fancy IceWire 2015 hardware? No. (that wasn't a real thing btw) > > Do we support enough hardware for day-to-day desktop use? I think so. > > We've crossed the catch 22 of kernel design. We support the *basics*, now > lets get a solid release out to attract developers who like Haiku enough to > make them *want* to write drivers for their shiny new IceWire 2015 > hardware. > It is not only about drivers (though it would be nice to have a proper power management), but also about much better performance (especially in terms of scaling on multicore processors) and features (e.g. kvm, lvm). Paweł