That seems like an interesting thing to say, given what you said next.
even if you do have "many eyes" (and the vast majority of projects do not) and even if you assume they are the right ones looking in the right place at the right time you will likely find at least some bugs at some point in time.
First, "I agree, but nobody said or [implied] [otherwise]"; the argument is that many eyes make bugs shallow, not spontaneously and instantaneously evaporate. Second, of course "you" will find some bugs at some point. The whole idea is that people will find bugs at some point, and in fact at some sooner point, because more people are looking.
it's hardly a reliable and practical advantage, more of a shot in the dark
I'd say it's an unreliable but highly fucking practical advantage, actually, because when there's only one target it's more likely you'll hit the guy with a thousand shots in the dark than just one or two.
in this case
In this case, the specific bug found seems by all accounts to be something very difficult to find via code review, especially given the OpenSSL codebase.
given the profile of the project this is an absolute best-case scenario
The fact it is a high profile project seems to be the only positive factor in this case, apart from the bare minimum fact that it is open source. There are many, many problems with this case that make it more difficult for this bug to have been found any earlier than it was. A new feature that passed review by one person on the core team was included, then found and fixed less than three years later. It was found by people outside the core team who only had access to the codebase because it was open source. The guts of OpenSSL are heavily compromised by eons of feature creep, which seems to be common to every major/widespread TLS package on the planet. While the wisdom in secure coding of the core team is open to question, for a number of reasons, the team at least seems to be universally pretty clear on some basic concepts of not relying on magic security-through-obscurity fairy dust. The best case scenario for pretty much every closed source TLS package that competes with it differs from these conditions mostly in one or two ways: they are not open source, so they would not have been backed up by the people who found the bug in OpenSSL; they may use magic security-through-obscurity fairy dust to make their code "secure". On top of that, the public nature of the discovery combined with the necessarily public nature of the project's handling of bug patching ensures that the bug got fixed very damned quickly.
Now . . . not all bugs (even critical security bugs) will be found more quickly just because it's open source. See above where I paraphrased: "nobody said or [implied]" that it's always perfect all the time immediately with zero delays so nobody ever has bugs in their software. The actual, reasonable, rational claim is that it provides enough of a benefit, often enough, to make smart open source development processes a very good idea, especially for security software. I think it's pretty reasonable to say that, given the exact same conditions apart from the things that would necessarily be different just due to the intrinsic nature of open vs. closed development models, the best you could reasonably expect from a closed source project in the same situation is almost exactly what happened -- but, much more realistically, it would have taken longer, because someone would have to have nailed down the particulars of the problem without access to the source code.
. . . so no, I don't agree with your point.
it didn't work effectively enough to stop this from being extremely widely distributed.
I'm not endorsing OpenSSL. I think its best endorsement is "It's probably 3% worse than the major competing options, both open source and closed, which all universally suck -- at least until something like LibreSSL is release-worthy." That's a pretty sucky endorsement, but it's the best we can do for OpenSSL -- to say that it's the (marginally) least awful of a pretty uniformly awful category of software.
I just think it's beyond stupid to say "This bug was found, therefore the software's development methodology ensures we never find bugs!" or some such twaddle.
Coverity: We won't tell anyone you're involved unless you want us to -- but we'll include your defect count in the overall numbers, because we want to use the same marketing tactic on other PSDs that we successfully used on you.
The (lack of) constraints on who can see the code is not the only difference. There's another difference, that for some reason gets explicitly denied as a difference by the preceding anonymous coward:
I would, in fact, expect that the passion and interest of coders in the open source world is actually far greater on average than in the closed source world, rather than exactly the same as the anonymous coward suggests. I have met many "professional" coders who write closed source software for some part of their typical eight hour workdays, and never think about code outside of that time if they can avoid it. Many of them hate coding, in fact, but do it for the paycheck, then go watch American Idol in the evenings and try to avoid having anything "boring" like computer programming intrude on their off-time.
Open source developers are the people who are interested and passionate enough about what they do to do it on their own time, or even to seek out jobs where they're allowed to contribute to open source projects on company time. That takes more dedication and honest interest in producing something good than just working in a cubicle for eight hours a day where they honestly couldn't give a shit whether what they were doing was writing code or picking their noses, as long as the paycheck keeps coming in.
Thus, I think there are some distinct benefits to open source software above and beyond the mere fact that given enough eyes, all bugs are shallow.
So, yeah . . . your second paragraph, only more so. That's my opinion.
. . . and yet, eyeballs finding this bug, and their owners fixing it, actually happened. How is it that proof that people looking for bugs and fixing them actually works turns into some kind of claim of proof that it doesn't work?
Only if they're actually is sufficient enough people looking at the code. OpenSSL proves that there isn't.
It's difficult to get enough eyes on the project when its design is such a mess that people who take a look at it have no idea what they're seeing.
Every major TLS software package available is crap, from what I've seen. OpenSSL only "proves" that with a sufficiently hyped marketing campaign, a bug in one package can ruin its reputation relative to others with similarly bad security issues that did not get the same marketing. In some respects, it could be argued that the recently discovered bugs in GnuTLS and Apple's TLS code were actually worse than the heartbeat feature's bug in OpenSSL, if only because the kind of coding stupidity that produced those bugs would almost certainly never have been made by someone who would even be capable of fixing the OpenSSL bug, while the OpenSSL heartbeat bug (aka "Heartbleed") is basically just a mistake made by an at least marginally competent coder.
So, take your pick: "Heartbleed", a bug introduced as a possibly understandable mistake by an at least marginally competent coder, but comes with tremendous marketing hype -- or the GnuTLS and Apple bugs of the "we check to make sure it's a verified connection, but then do nothing about it when it's not verified", which are the kinds of errors that require the relevant coders to actually be incompetent, drunk, or otherwise so out of whack that it makes those of us who understand the problem scratch our heads and wonder how that could ever possibly have happened, but did not come with tremendous marketing hype, so nobody really thinks about the shaky ground on which they're standing when using that software.
The key fact to keep in mind, though, is that basically every major, widely used TLS package in the world (open source or closed) seems to be rickety garbage mostly maintained by manifestly unqualified programmers. Worse, many of them don't seem to realize they're unqualified. OpenSSL appears, from what I've seen (which admittedly isn't enough to be sure of my conclusions), to be at least slightly less awful than Apple's, GNU's, and Microsoft's equivalents, but even optimistically it is the best of a bad breed. There is one ray of hope here, however: some people in the OpenBSD project have undertaken the herculean task of forking OpenSSL and rehabilitating it. Given the relatively high density of people with secure coding skills in the OpenBSD developer community, and the OpenBSD project's practice of performing extensive code reviews, as well as the early evidence that these guys are doing what it takes to make a good TLS package out of OpenSSL -- throwing away huge swaths of unnecessary code and cleaning up some horrendous bugs that have been around forever -- I have high expectations, assuming the fork project doesn't die before reaching stable release state.
Has it ever occurred to you that despite having done some things wrong the Linux world has developed some very solid technology and BSD might, just might, benefit from pulling it's head out of the sand adopting some of them.
What are you talking about? FreeBSD makes use of Linux-based technology all the damned time -- just as soon as it can port it (because for some reason Linux developers are increasingly hostile to software portability) or reimplement it (because the Linux community seems inextricably wedded to using licenses that create compatibility problems with other licenses, thus making it illegal for BSD Unix projects to use the original implementations). The fact not all technologies are deemed worthy for adoption does not mean that all Linux-based technologies are avoided just because they came from the Linux world, y'know.
You can't have rational conversations with people who think the word "bloat" belongs in a discussion where the difference is like a meg.
I'm not sure it's possible to have a rational conversation with someone who makes comments like that as though intentionally creating a rift between participants in discussion as a pre-condition for conversation.
Hell last I checked BSD's still come with vi and not vim out of the box.
Vim potentially creates licensing problems for BSD Unix base systems.
Is there any legitimate justification for the fact I have a more capable tar out of the box on a Linux system than BSD?
citation needed
Also . . . licensing.
The Linux world has it's problems and if you use the cutting edge stuff you will have some glitches here and there. But at least it is doing SOMETHING. Those glitches will be worked out. Some things will be discarded in time others will stabilize into solid technology.
. . . by which point it will have already been deprecated in the community at large by something else half-created that is buggy and problematic. Some Linux distributions will of course be resisting the sudden jump to a new, unfinished replacement for the last unfinished replacement, but they'll have problems because other things that they want to use will jump to dependence on the new, unfinished toy.
BSDland is doing a whole lot of nothing and calling it a feature
I guess we can ignore all the stuff being created in "BSDland", including stuff that keeps getting ported to "Linuxland" because the Linux developers were too busy building half of something and making it technically very difficult to port to BSD Unix systems.
most of the software running on BSD is developed in projects that are cross platform because it is easy to be but those projects exist and thrive because they run on Linux not because of BSD.
Say what? I suppose new capabilities of, say, pf "only exist and thrive because they run on Linux not because of BSD", even though pf isn't portable to Linux. Right? Then, of course, there's the BSD ACL framework on FreeBSD that is widely regarded as being as capable as SELinux and easier to use. I think you just don't know what the hell you're talking about.
BSD has some nice technology but the only reason it continues to exist and talented people waste effort developing that technology there instead of on Linux (where more people will benefit from it) is because some people who felt l33t running a hard to use Linux in the 90's hated Linux going mainstream and because nostalgic old UNIX admins still perpetrate the myth that it is more stable/secure/somehow betterer because much of it originates from the old UNIX(TM) code base.
. . . or maybe you're just an OS bigot, and what you're saying is complete claptrap.
Of course, thanks to SCO we all know that any of that code that was worth having migrated into Linux a long long time ago
I've just noticed that whenever someone asks if FreeBSD has a feature that is already in Linux or if someone asks how they can do action ABC on FreeBSD that they do on Linux, the result is typically a flame fest. People in the FreeBSD community often use their hatred of Linux to defend their own lack of progress.
I haven't really seen that on the mailing lists and in IRC. Maybe what you observe is a problem with the forum, specifically.
Which you comment, appropriately enough, demonstrates.
I think this statement of yours demonstrates that you're just looking for reasons to hate FreeBSD users.
I'll use pkgng on the rare occasion that I need something huge and ugly like OpenOffice.org, in part because that won't pull in a bunch of asinine build dependencies and in part because I don't want to wait three days for something almost as big as MS Windows that I don't want anyway except for the fact some knucklehead sent me an Excel spreadsheet. Otherwise, I like the ports system (with portmaster as the front end, these days) just fine.
- a *lot* of times a software gets a new version and the ports skip it. So you install mediawiki 1.18.1 and then update to 1.18.4. (just an example).
That's not the fault of the ports system. That's the fault of the maintainer of that specific port.
- patch backport: I really hate backporting of patches. so sometimes you have version 1.1 of a software and then you get version 1.1_1 which is actually almost 1.2. never liked it, I prefer the vanilla software.
That's kind of a strange gripe. Are you really complaining about how version numbers are represented?
- there *are* software conflicts. Try to install a couple of things that requires icu and keep them up to date. most likely you will not be able to update une of the packages 'cause it doesn't work with the old/new version of icu. Avahi still requires icu 3.8, guess what, it's not in the ports anymore.
It was stated that software conflicts are rare -- not that they never happen. They happen for every software management system, including those used by popular Linux distributions and what we might, with a laugh, call a software management system on MS Windows. Such is life.
Ironically, PulseAudio works better on BSD Unix systems than on Linux-based systems, generally. PulseAudio is a complete disaster area on the platform for which it was designed (Linux).
After entering protected mode and going to _main with the far jump simply return EOL; or something similar. That's all there is for a new BSD release. Nothing else.
alternative interpretation:
Woohoo! FreeBSD 9.1-RELEASE comes with support for new Intel HD graphics. Hot damn. I finally get to get rid of the non-deterministic, obese, constantly agonizing experience of dicking around with half-baked bullshit in the Linux world on this laptop.
I mean, really . . . who wouldn't want to get out from under the horrid experiences Lennart Poettering, the GNU Project, and Canonical have foisted onto the Linux world in recent years?
If the driver needs to be integrated into a monolithic whole with the code that makes it compatible with something distributed under the GPL (such as the Linux kernel), there's some danger of being liable for license violation if someone wants to make a stink about it -- and it's not just the GPL that may be the problem, remember: Oracle is the owner of the ZFS copyrights, and the ZFS is distributed under the terms of a copyleft license.
How you go about getting the pieces of software to play well with each other determines the potential for being sued or otherwise having issues related to license incompatibility. The current thinking on the matter in the Linux world seems to be "Well . . . I doubt anyone will sue us for making the ZFS driver into a module. I guess we're safe. Hope so, anyway."
Some of the push to relax and just use stuff together had something to do with embarrassment over licensing conflicts with the GPL, I think -- more so than because of actual honest analysis of the GPL resulting in a feeling that it's safe to use ZFS as a distinct module.
What license do you mean? That does not describe CDDL. There are licenses with "advertising clauses" and so on with which the GPL conflicts, but that's not the reason for CDDL incompatibility.
Slashdot Mirror
That seems like an interesting thing to say, given what you said next.
First, "I agree, but nobody said or [implied] [otherwise]"; the argument is that many eyes make bugs shallow, not spontaneously and instantaneously evaporate. Second, of course "you" will find some bugs at some point. The whole idea is that people will find bugs at some point, and in fact at some sooner point, because more people are looking.
I'd say it's an unreliable but highly fucking practical advantage, actually, because when there's only one target it's more likely you'll hit the guy with a thousand shots in the dark than just one or two.
In this case, the specific bug found seems by all accounts to be something very difficult to find via code review, especially given the OpenSSL codebase.
The fact it is a high profile project seems to be the only positive factor in this case, apart from the bare minimum fact that it is open source. There are many, many problems with this case that make it more difficult for this bug to have been found any earlier than it was. A new feature that passed review by one person on the core team was included, then found and fixed less than three years later. It was found by people outside the core team who only had access to the codebase because it was open source. The guts of OpenSSL are heavily compromised by eons of feature creep, which seems to be common to every major/widespread TLS package on the planet. While the wisdom in secure coding of the core team is open to question, for a number of reasons, the team at least seems to be universally pretty clear on some basic concepts of not relying on magic security-through-obscurity fairy dust. The best case scenario for pretty much every closed source TLS package that competes with it differs from these conditions mostly in one or two ways: they are not open source, so they would not have been backed up by the people who found the bug in OpenSSL; they may use magic security-through-obscurity fairy dust to make their code "secure". On top of that, the public nature of the discovery combined with the necessarily public nature of the project's handling of bug patching ensures that the bug got fixed very damned quickly.
Now . . . not all bugs (even critical security bugs) will be found more quickly just because it's open source. See above where I paraphrased: "nobody said or [implied]" that it's always perfect all the time immediately with zero delays so nobody ever has bugs in their software. The actual, reasonable, rational claim is that it provides enough of a benefit, often enough, to make smart open source development processes a very good idea, especially for security software. I think it's pretty reasonable to say that, given the exact same conditions apart from the things that would necessarily be different just due to the intrinsic nature of open vs. closed development models, the best you could reasonably expect from a closed source project in the same situation is almost exactly what happened -- but, much more realistically, it would have taken longer, because someone would have to have nailed down the particulars of the problem without access to the source code.
. . . so no, I don't agree with your point.
This is true fo
I'm not endorsing OpenSSL. I think its best endorsement is "It's probably 3% worse than the major competing options, both open source and closed, which all universally suck -- at least until something like LibreSSL is release-worthy." That's a pretty sucky endorsement, but it's the best we can do for OpenSSL -- to say that it's the (marginally) least awful of a pretty uniformly awful category of software.
I just think it's beyond stupid to say "This bug was found, therefore the software's development methodology ensures we never find bugs!" or some such twaddle.
It's a helluva lot better than the likely closed source alternative: exactly the same, but it won't be discovered for another five years at least.
Coverity: We won't tell anyone you're involved unless you want us to -- but we'll include your defect count in the overall numbers, because we want to use the same marketing tactic on other PSDs that we successfully used on you.
The (lack of) constraints on who can see the code is not the only difference. There's another difference, that for some reason gets explicitly denied as a difference by the preceding anonymous coward:
I would, in fact, expect that the passion and interest of coders in the open source world is actually far greater on average than in the closed source world, rather than exactly the same as the anonymous coward suggests. I have met many "professional" coders who write closed source software for some part of their typical eight hour workdays, and never think about code outside of that time if they can avoid it. Many of them hate coding, in fact, but do it for the paycheck, then go watch American Idol in the evenings and try to avoid having anything "boring" like computer programming intrude on their off-time.
Open source developers are the people who are interested and passionate enough about what they do to do it on their own time, or even to seek out jobs where they're allowed to contribute to open source projects on company time. That takes more dedication and honest interest in producing something good than just working in a cubicle for eight hours a day where they honestly couldn't give a shit whether what they were doing was writing code or picking their noses, as long as the paycheck keeps coming in.
Thus, I think there are some distinct benefits to open source software above and beyond the mere fact that given enough eyes, all bugs are shallow.
So, yeah . . . your second paragraph, only more so. That's my opinion.
PostGRES
Are you sure you don't mean PostgreSQL?
I don't think you understand copyright at all. That makes zero sense.
Most people are doing it wrong. Is this a surprise to you?
Remember that most programmers are far from half as good as the Linux coders, and thus should avoid writing code as much as possible.
FTFY
. . . and yet, eyeballs finding this bug, and their owners fixing it, actually happened. How is it that proof that people looking for bugs and fixing them actually works turns into some kind of claim of proof that it doesn't work?
Good point. The bug was found . . . and fixed. How does this prove that nobody's looking at the code and fixing bugs?
Only if they're actually is sufficient enough people looking at the code. OpenSSL proves that there isn't.
It's difficult to get enough eyes on the project when its design is such a mess that people who take a look at it have no idea what they're seeing.
Every major TLS software package available is crap, from what I've seen. OpenSSL only "proves" that with a sufficiently hyped marketing campaign, a bug in one package can ruin its reputation relative to others with similarly bad security issues that did not get the same marketing. In some respects, it could be argued that the recently discovered bugs in GnuTLS and Apple's TLS code were actually worse than the heartbeat feature's bug in OpenSSL, if only because the kind of coding stupidity that produced those bugs would almost certainly never have been made by someone who would even be capable of fixing the OpenSSL bug, while the OpenSSL heartbeat bug (aka "Heartbleed") is basically just a mistake made by an at least marginally competent coder.
So, take your pick: "Heartbleed", a bug introduced as a possibly understandable mistake by an at least marginally competent coder, but comes with tremendous marketing hype -- or the GnuTLS and Apple bugs of the "we check to make sure it's a verified connection, but then do nothing about it when it's not verified", which are the kinds of errors that require the relevant coders to actually be incompetent, drunk, or otherwise so out of whack that it makes those of us who understand the problem scratch our heads and wonder how that could ever possibly have happened, but did not come with tremendous marketing hype, so nobody really thinks about the shaky ground on which they're standing when using that software.
The key fact to keep in mind, though, is that basically every major, widely used TLS package in the world (open source or closed) seems to be rickety garbage mostly maintained by manifestly unqualified programmers. Worse, many of them don't seem to realize they're unqualified. OpenSSL appears, from what I've seen (which admittedly isn't enough to be sure of my conclusions), to be at least slightly less awful than Apple's, GNU's, and Microsoft's equivalents, but even optimistically it is the best of a bad breed. There is one ray of hope here, however: some people in the OpenBSD project have undertaken the herculean task of forking OpenSSL and rehabilitating it. Given the relatively high density of people with secure coding skills in the OpenBSD developer community, and the OpenBSD project's practice of performing extensive code reviews, as well as the early evidence that these guys are doing what it takes to make a good TLS package out of OpenSSL -- throwing away huge swaths of unnecessary code and cleaning up some horrendous bugs that have been around forever -- I have high expectations, assuming the fork project doesn't die before reaching stable release state.
I find the situation somewhat the opposite, and have some wedged updates on a Debian system right now to prove it. I guess your mileage differs.
Has it ever occurred to you that despite having done some things wrong the Linux world has developed some very solid technology and BSD might, just might, benefit from pulling it's head out of the sand adopting some of them.
What are you talking about? FreeBSD makes use of Linux-based technology all the damned time -- just as soon as it can port it (because for some reason Linux developers are increasingly hostile to software portability) or reimplement it (because the Linux community seems inextricably wedded to using licenses that create compatibility problems with other licenses, thus making it illegal for BSD Unix projects to use the original implementations). The fact not all technologies are deemed worthy for adoption does not mean that all Linux-based technologies are avoided just because they came from the Linux world, y'know.
You can't have rational conversations with people who think the word "bloat" belongs in a discussion where the difference is like a meg.
I'm not sure it's possible to have a rational conversation with someone who makes comments like that as though intentionally creating a rift between participants in discussion as a pre-condition for conversation.
Hell last I checked BSD's still come with vi and not vim out of the box.
Vim potentially creates licensing problems for BSD Unix base systems.
Is there any legitimate justification for the fact I have a more capable tar out of the box on a Linux system than BSD?
citation needed
Also . . . licensing.
The Linux world has it's problems and if you use the cutting edge stuff you will have some glitches here and there. But at least it is doing SOMETHING. Those glitches will be worked out. Some things will be discarded in time others will stabilize into solid technology.
. . . by which point it will have already been deprecated in the community at large by something else half-created that is buggy and problematic. Some Linux distributions will of course be resisting the sudden jump to a new, unfinished replacement for the last unfinished replacement, but they'll have problems because other things that they want to use will jump to dependence on the new, unfinished toy.
BSDland is doing a whole lot of nothing and calling it a feature
I guess we can ignore all the stuff being created in "BSDland", including stuff that keeps getting ported to "Linuxland" because the Linux developers were too busy building half of something and making it technically very difficult to port to BSD Unix systems.
most of the software running on BSD is developed in projects that are cross platform because it is easy to be but those projects exist and thrive because they run on Linux not because of BSD.
Say what? I suppose new capabilities of, say, pf "only exist and thrive because they run on Linux not because of BSD", even though pf isn't portable to Linux. Right? Then, of course, there's the BSD ACL framework on FreeBSD that is widely regarded as being as capable as SELinux and easier to use. I think you just don't know what the hell you're talking about.
BSD has some nice technology but the only reason it continues to exist and talented people waste effort developing that technology there instead of on Linux (where more people will benefit from it) is because some people who felt l33t running a hard to use Linux in the 90's hated Linux going mainstream and because nostalgic old UNIX admins still perpetrate the myth that it is more stable/secure/somehow betterer because much of it originates from the old UNIX(TM) code base.
. . . or maybe you're just an OS bigot, and what you're saying is complete claptrap.
Of course, thanks to SCO we all know that any of that code that was worth having migrated into Linux a long long time ago
I've just noticed that whenever someone asks if FreeBSD has a feature that is already in Linux or if someone asks how they can do action ABC on FreeBSD that they do on Linux, the result is typically a flame fest. People in the FreeBSD community often use their hatred of Linux to defend their own lack of progress.
I haven't really seen that on the mailing lists and in IRC. Maybe what you observe is a problem with the forum, specifically.
Which you comment, appropriately enough, demonstrates.
I think this statement of yours demonstrates that you're just looking for reasons to hate FreeBSD users.
Have you never learned to use one of the optional front ends to the ports system? I guess so.
I'll use pkgng on the rare occasion that I need something huge and ugly like OpenOffice.org, in part because that won't pull in a bunch of asinine build dependencies and in part because I don't want to wait three days for something almost as big as MS Windows that I don't want anyway except for the fact some knucklehead sent me an Excel spreadsheet. Otherwise, I like the ports system (with portmaster as the front end, these days) just fine.
- a *lot* of times a software gets a new version and the ports skip it. So you install mediawiki 1.18.1 and then update to 1.18.4. (just an example).
That's not the fault of the ports system. That's the fault of the maintainer of that specific port.
- patch backport: I really hate backporting of patches. so sometimes you have version 1.1 of a software and then you get version 1.1_1 which is actually almost 1.2. never liked it, I prefer the vanilla software.
That's kind of a strange gripe. Are you really complaining about how version numbers are represented?
- there *are* software conflicts. Try to install a couple of things that requires icu and keep them up to date. most likely you will not be able to update une of the packages 'cause it doesn't work with the old/new version of icu. Avahi still requires icu 3.8, guess what, it's not in the ports anymore.
It was stated that software conflicts are rare -- not that they never happen. They happen for every software management system, including those used by popular Linux distributions and what we might, with a laugh, call a software management system on MS Windows. Such is life.
Oh, and . . . portmaster has built-in facilities for the same stuff that work even better than portversion.
It took over forty seconds(!!) on an otherwise idle system (Ivy Bridge i5 w/ SSD) to list all the installed ports and their versions (pkg_version).
Regarding your only specific problem mention . . .
Do people still use pkg_version? Are you aware portversion is faster, and has been for a long time -- and pkg_* tools are reaching EOL?
Ironically, PulseAudio works better on BSD Unix systems than on Linux-based systems, generally. PulseAudio is a complete disaster area on the platform for which it was designed (Linux).
Anytime Linux comes up on the FreeBSD forums it turns into a huge flame fest.
Maybe that wouldn't happen if you didn't keep trolling there with hostile claims about how awful FreeBSD is, and how unpleasant its users are.
After entering protected mode and going to _main with the far jump simply return EOL; or something similar. That's all there is for a new BSD release. Nothing else.
alternative interpretation:
Woohoo! FreeBSD 9.1-RELEASE comes with support for new Intel HD graphics. Hot damn. I finally get to get rid of the non-deterministic, obese, constantly agonizing experience of dicking around with half-baked bullshit in the Linux world on this laptop.
I mean, really . . . who wouldn't want to get out from under the horrid experiences Lennart Poettering, the GNU Project, and Canonical have foisted onto the Linux world in recent years?
If the driver needs to be integrated into a monolithic whole with the code that makes it compatible with something distributed under the GPL (such as the Linux kernel), there's some danger of being liable for license violation if someone wants to make a stink about it -- and it's not just the GPL that may be the problem, remember: Oracle is the owner of the ZFS copyrights, and the ZFS is distributed under the terms of a copyleft license.
How you go about getting the pieces of software to play well with each other determines the potential for being sued or otherwise having issues related to license incompatibility. The current thinking on the matter in the Linux world seems to be "Well . . . I doubt anyone will sue us for making the ZFS driver into a module. I guess we're safe. Hope so, anyway."
Some of the push to relax and just use stuff together had something to do with embarrassment over licensing conflicts with the GPL, I think -- more so than because of actual honest analysis of the GPL resulting in a feeling that it's safe to use ZFS as a distinct module.
What license do you mean? That does not describe CDDL. There are licenses with "advertising clauses" and so on with which the GPL conflicts, but that's not the reason for CDDL incompatibility.