On Mon, 22 Aug 2005, W. Wayne Liauh wrote:
...... original reformatted .....
> >Most if not all of the technical questions posted on this forum are left
> >unanswered, but Sun's >engineers do find time to engage in non-technical
> >matters. Perhaps most of the trashings >about Sun are well justified.
>
> The near-total apathy that I have sensed from the overwhelming majority
> of Sun's engineers toward OpenSolaris to me serves as a clear warning as
> to whether Sun is really committed to opensource. Talk is cheap. &
> cheap talks invite resentments. To induce interests, someone must show
> actions.
>
> While the GPL'ed Linux kernel does not allow proprietary device drivers
> to be included in the kernel itself, they can be easilly added as
> loadable modules. A number of yum/apt repositories have been constructed
> to make loading these modules painless. Several Linux distributions
> (e.g., Ubuntu, PCLinuxOS, etc.) even pre-load those proprietary drivers,
> thus erasing one of the main advantages CDDL might have over the GPL.
My personal experience tells me that this statement is totally inaccurate.
Why, because with the kernel interfaces constantly changing, most Linux
driver developers have been unable to provide drivers as loadable modules
or in binary form. Even the module loaders requirements change. And why
is this? Well because Linus believes that stable APIs and ABIs stiffle
innovation. Has he looked at Solaris 10 and DTrace recently - no impact on
Solaris API/ABI stability while providing *lots* of innovation!
Case in point: I "tried" to build a Linux system about 12 months ago to
take advantage of the excellent 3Ware 9500 SATA RAID controller. I wanted
to build a system to act as disk based backup archiver and SVN (subversion)
server. I picked Suse Linux Professional 9.0 (then current) and got the
box up and running without too many headaches. Then here's what happened
next (excuse cut/paste from an earlier email):
--- begin cut/paste ----
- after running the system for about a week, upgraded the Linux kernel to
resolve a published kernel exploit and the system refused to boot. You
know - after it's been running long enough that you've invested some man
hours into it!
+ the driver is a loadable module with a "rev number" tied to the
particular kernel release. Upgrade the kernel and the version #s
don't match and the module won't load.
- According to 3Ware tech support [7], I should have (in this order):
+ patched the new kernel - step 1 (did that)
+ downloaded/installed the corresponding kernel build environment - step 2
+ built a new kernel - step 3
+ downloaded the 3Ware driver source kit - step 4
+ built a new driver from source - step 5
+ updated the module/kernel rev level "stuff" - step 6
+ then rebooted - step 7 (did that!)
Of course I did step 1 & step 7. Silly me! About 2 1/2 man days later I
had installed the OS onto another drive and used that to mount my RAID
drive, and after several unsuccessful iterations, succeeded in doing the
above and recovering the system intact. My software development schedule
took a serious hit! :(
Epilog: After all that I decided that this solution was also too kludgey
for me to live with. Perhaps I've been spoiled by Sol x86, or perhaps
there are'nt enough hours in the day to deal with Linux madness. The usual
Linux story - you bleed serious man hours to get it running. You bleed
serious manhours to keep it running.
[7] nice guy, very knowledgeable/helpful. We both whined about Linux,
talked through the recovery plan, then he wished me luck!
--- end cut/paste ----
Even the 3Ware tech support guy whined about how hard it was to try to
deliver a binary driver into Linux. They wanted to - so as to reduce
their maintenance burden and having to take calls from users like myself
whose RAID subsystem became inaccessible after a security patch was
applied. And they had been able to do so under earlier Linux releases by
programming around Linux interfaces - but then those interfaces changed and
forced them to deliver source code and their user community to build a new
loadable module from source every time they have to patch the kernel.
Some users would say (and I'm *not* saying this), that the Linux zealots
will do whatever it takes to prevent someone from shipping binary only code
into the Linux environment.
Regards,
Al Hopper Logical Approach Inc, Plano, TX. [EMAIL PROTECTED]
Voice: 972.379.2133 Fax: 972.379.2134
OpenSolaris Community Advisory Board (CAB) Member - Apr 2005
_______________________________________________
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
