once geeks realize that they can't compile the open source version to the binary
A small and ever-decreasing percentage of users compile their own binaries, let alone check the result. Also, not all of the exploits appear only in the binary; in at least one case the malefactors added a fairly hard-to-notice security hole to the CVS source, so the "official" binaries and checksums matched just fine.
Like others, I have modified most of the employment contracts I have signed. At one place, they thought their intellectual property was something special (it wasn't) so they had one of those really greedy, graspy, "everything you ever invented or will invent is ours" clauses. I replaced it with something more reasonable and handed it to the CFO. We went a couple of rounds this way, nothing rancorous, and then he dropped the ball. I guess it sat on his desk for a while and then he forgot about it; he certainly had other things to worry about. Net result is that I never signed.
Fast forward to the day I announced my resignation. Shortly afterward, I got an email from an admin, saying that they couldn't find my employee agreement and asking me to sign the enclosed copy. As you can imagine, I was sorely tempted to respond very rudely, but it wasn't her fault the CFO dropped it. I didn't feel like explaining what had happened, so I just ignored the email and the subject never came up again. It was very satisfying anyway.
There are necessary and beneficial rewrites, but the vast majority of rewrites occur because it's easier to write a new piece of code than to understand an old one. Yes, easier. The "rewrite bug" afflicts brash beginners the most, and top-notch experienced programmers the least. The best programmers tend to get that necessary rewrite out of the way during initial development, by writing a serious first-cut version, throwing it away, and then writing it a second time for real all before anyone else even sees it. Such code will often pass unit tests earlier than the "never refactor" code written by second-raters, and rarely requires a rewrite after that.
That's exactly the point I was going to make, and in fact already made on my own website when this showed up on the aptly-named USS Clueless (where the author of the article here undoubtedly saw it but didn't bother to note the fact). The several types of hypocrisy and dishonesty in how this article has been propagated are IMO the most interesting things about it.
The company (Constellation 3D) working on it finally failed several months ago. The problem didn't seem to be with the basic technology, which actually did work (so I wouldn't really call it vaporware), but with issues such as manufacturing the lens assemblies and the disks themselves for reasonable cost. I wouldn't be a bit surprised if the idea reappears after materials and manufacturing technologies have advanced a bit to make real-world products feasible. Or perhaps the manufacturing problems were truly intractable. It's really hard to tell, but I wouldn't write the whole idea off just yet. We may yet see LEP/OLED or iridescence displays too; it's just the nature of bleeding-edge technology that you have to try a couple of times before you know whether the second- and third-order problems are solvable.
Welcome to Garret Hardin's "tragedy of the commons". People occasionally cooperate voluntarily to manage a shared resource, but much more often each person just grabs whatever they can and nothing short of physical force or some other means backed up with the threat of physical force (e.g. a lawsuit) will make them do otherwise. You have just illustrated how laissez-faire fails in the real world.
Even the worst pointy-heads at DoE aren't claiming cold fusion is possible, so we're left with only the hot kind, and that's all well and good as long as you're plugged in but there's a slightly non-trivial need for something that lets you take power with you. Even while you're on the grid, there are issues such as 80% transmission loss that might justify the application of some basic science to overcome. The pedants will point out that such programs exist but the're not covered by a facilities-oriented document, but until such programs get more than a tiny fraction of the facilities budget and until they get enough publicity to start appearing on Slashot that response is just nitpicky BS. There's an anti-usefulness philosophy at DoE that is simply not acceptable in a taxpayer-funded organization, and I say that not as a Luddite (like some utterly ignorant and sociopathic mama's boys on this thread have tried to paint me) but as someone who thinks our overall science budget should be increased. It should just be realigned and its overseers held accountable for how our money is spent, that's all.
All of those are engineering problems, not science.
Bull. Maybe they're not "pure science" at the "fundamental nature of the universe" level, but they are squarely on the science side of the fence. There's still a lot we don't know about things like proton exchange, for example, or about how mitochondria or chloroplasts work so efficiently, or what's really going on in different types of solar cells. That knowledge is being sought by scientists, in academic labs, not engineers. The DoE actually funds some of it, but at a level that can only be described as a pittance compared to the items on the list. They're warped priorities. Maybe there should be two or three atom-smasher type projects, but not ten. The other money should go to other areas of scientific research that are currently resource-starved, and the fact that projects in some of those areas might have medium-term commercial applications should not disqualify them from consideration. Science should be funded without regard for commerce, not in a manner that's actively inimical to commerce.
Your grandchildren may write school papers on the discoveries these tools will make...
Not likely. I'm all for research, but most of the stuff on this list is "big science" only in terms of the money that will be spent, not the knowledge that will be gained. There's tons of biotech, materials-science, computing, optics, and other research that would be more rewarding. The most appalling omission is that the Department of Energy doesn't seem to think that battery technology - the thing holding back deployment of many other technologies - deserves even one project. Nothing on portable fuel cells, microturbines, biodiesel, wave power, or other energy-related technologies either, except fusion. What is the Department of Energy thinking?
There might be a few things in there to write papers about, but if we spend all of the money to fund these projects there won't be any left over for schools...or paper, for that matter. The only way my grandchildren will be writing papers on this stuff is if I or my children move somewhere with a sane science policy.
Between the terminology of some experienced Bell Labs researchers and you, frankly, I give precedence to their choice of terminology.
That appeal to authority, besides being fallacious, doesn't work too well when the person you're addressing is actually a peer to the authority you cite. Many people in this specialty would agree that the characterization of Venti as a block-level system is questionable.
If you think your product distinguishes itself, call it something different
We do. I'm in engineering, though, not marketing, so I didn't think it would be appropriate to introduce those terms into a technical discussion.
it doesn't sound like your user experience will be any better.
Can I use Venti with any old filesystem? No, because it uses its own API instead of the OS-native block read/write. Can I hook up my new Windows, Linux, or FubarOS machine to Venti storage without having to port their API? No, because it's embedded in a particular host environment. Saying Venti is block-level when it only works with one filesystem and OS is like saying that a libc hack is the same as a real distributed filesystem; it's cool as a prototype or research project, but in day-to-day use the limitations inevitably become obvious. I don't know if you've ever worked on actual shipping code, but I've worked on a dozen products that have actually shipped and made money and I can say that production code always differs greatly from its research/prototype forebears.
Venti is great work, I already had Quinlan and Dorwards' FAST 2002 paper on my desk before this conversation began, but it's only loosely related to and by no means the same as what I was talking about...and you were still not quite telling the truth when you said nobody found it useful.
Bell Labs had several versions of such a system, built into the research UNIX kernel
Venti. Filesystem-level, research project, and it was Plan 9 not UNIX. In other words, pretty much totally unlike what I was talking about. Furthermore, others have already mentioned it on this very thread and said it was useful to them, putting the lie to your claim that it's not useful.
Oh, please don't get me wrong; I love unison. I found it when I was doing some research for one of my own spare-time projects, and was very impressed. It really is better than rsync in a lot of ways. My point in mentioning rsync was just to say "even rsync can do that" in the same way I might say "even tar/cpio can do that" to make the point that non-versioned backup just isn't all that interesting or difficult. IMO file synchronization, backup/restore and source control are related but distinctly different program categories, with complexity in different areas - e.g. conflict detection and resolution for file sync, or branching and merging for source control. It's often possible to use one tool to do another's job, but mature examples in each category tend to specialize toward a particular purpose. There's a large set of "oops, someone screwed up" problems that simply aren't solved with single-version backup, but that are solved with even the most basic versioned backup. If I want to keep the contents of directories on multiple machines identical I'd use unison, but that's not the problem this thread is about. It's a great solution to a different problem.
rsync is a uni-directional file synchronizer and it doesn't have an interactive interface
Yes, but it's trivial to run it twice, once in each direction, with arguments that result in updates propagating in both directions. An interactive interface in this context is definitely in that category you refer to as "profoundly useless"; if I want to synchronize directories I usually have a pretty good idea how conflicts should be resolved and I don't want to be pestered to specify in each case. If I have versioning I can even resolve conflicts the "wrong" way and it's OK because both versions end up in the repository anyway.
Such systems have been around since at least the 1980's. Most people who have used them (including myself) have found them to be profoundly useless even though they worked exactly as advertised and were really easy to use.
Name one. No filesystem-level stuff please, and no snapshots either. I've worked on both kinds of systems before, and they're not what I was talking about. Block level, continuous rollback capability. Got it? Even the more limited kinds of systems, BTW, have proven immensely useful to people, which is probably why EMC and NetApp rake in billions of dollars selling them. I know dozens of people from hands-on sysadmins to Fortune 500 CIOs who have relied on them for years. Just because you couldn't figure out how to take advantage of them doesn't mean nobody else did. Some people are just smarter than others.
And, in the interest of full disclosure, I have no commercial interest whatsoever in any of these systems.)
...or in anything else, I'll guess. I'll wait for someone with an actual job to comment.
It's not quite the same thing as CVS, but that's probably a good thing. Most importantly, it won't give you versioning.
That's actually the key feature here. Unison is great if you want to have just the most recent copy available. Rsync can actually be used in that fashion too, BTW, right out of the box, and it works well too. However, versioning allows you to go back to the most useful prior version of the file, not just the most recent. What if you finally managed to get your configuration right last week, but that version got overwritten by the version with "just one more tweak" that was used for this week's rsync/unison run? Your backup is just as corrupt as your working version now. Backup becomes much more useful when there are multiple restore points, and versioning is an intuitive way to keep track of those restore points. Without that, there are several common "oops" scenarios that backups won't solve.
I guess I should mention, just for the sake of full disclosure (not because it's really relevant) that I'm a product architect at a company seeking to do provide just this sort of "go back to any time" functionality at the block level. Of course I have some strong opinions about the relative utility of "single point in time" vs. continuous backup/restoration, or I wouldn't have taken the job.
Yeah, Tk is great for quick prototyping. I've used it that way myself for years, and I very recently released some code for general use that was done that way. However, Tk is simply lower level and less polished than wxWindows. Tk has basic widgets that work which is fine for stuff I use myself or give to other developers, but I can recognize a Tk-based UI as such immediately on either Windows or Linux and that's a drawback. WxWindows has more advanced widgets that are indistinguishable from fully-native counterparts and can match the most polished professional applications. When I looked at a list of programs that used wxWindows (somewhere on the wxWindows site) I was actually surprised by some of them. I had used some of them, and it never occurred to me to wonder what framework they used. That's something I've never been able to say about any Tk-based UI, where the framework is in my face and many operations follow the framework model instead of the local UI standard unless someone has done a lot of per-application work to overcome the mismatch.
Yes, there are plenty of packages that attempt to "raise the semantic level" of Tk-based UIs, from grouping radio buttons to providing automagical tabbed dialogs with built-in scrolling canvases and checkbox tree controls. Follow that approach to its logical conclusion, and what do you get? WxWindows. Why use Tk plus this plus that with a little bit of the other and a whole bunch of your own time sanding off the rough edges, when somebody on the wxWindows team has probably already done it? Sure, you have to learn a little bit about how they did it, but that's really no harder than learning how to do it yourself with Tk, and the next programmer has a better chance of understanding what wxWindows did than what you did. Do you want to spend all of your programming time dicking around with character-set issues and varying focus/selection semantics on multiple platforms, or do you have other kinds of problems you'd rather be solving? I know I'd rather not get bogged down writing UI workarounds just to have something that's not butt-ugly. I have better things to do with my programming time.
I stand corrected, and my apologies to the Pastiche folks. I should have remembered that Pastiche is not from Microsoft even though it's based on Pastry which is.
Many responses, even highly-rated ones, seem to be talking about simple replication via NBD (worst-written code I've ever seen) or DRBD. That's not the same as what the original poster was asking about. Neither are fully-distributed but non-transparent file stores such as HiveCache. AFS/DFS/Coda/Intermezzo are probably the closest in the sense of being both transparent and resistant to failures. There have also been a couple of very closely related projects at Microsoft (Farsite and Pastiche) but I'm not sure if there's anything you can actually download and use.
if this were a 17-year-old instead of AOL, the FBI would be investigating.
According to AOL's online history, AOL is a 17-year-old. OK, it's a bit of a stretch, you have to count from when they went online instead of when they incorporated and they'd still be less than a month away from 18 years, but that's my story and I'm sticking with it.
In general it is not possible to use drivers under any other OS than the one it was developed for.
...and yet, it does seem to be possible for Windows NDIS drivers running under Linux. Keep in mind that NDIS drivers are, for the most part, not direct-hardware drivers. Many NDIS drivers' only interface is via an API, which could be implemented on any platform (though it is an ugly API so it can be painful).
any kernel developer will tell you it is not a good idea.
This kernel developer will tell you that whether or not it's a good idea depends very much on the type of driver and the disparity between OS platforms. I've worked on plenty of drivers where 90% or more of the code was shared between platforms, and in some cases the remainder could have been done by someone else via emulation instead of a linked-in abstraction layer. I don't think running non-native drivers is necessarily a good idea, and performance will always suffer, but it's often a better idea than the alternative which is to implement a complete new driver for poorly-documented hardware in the context of a project whose goal is probably something other than driver writing.
Actually they didn't fire me, and I am in a "leadership role" in my current company. People seem to have put great faith in my social/team skills. It's the anonymous cowards (whose identities are easily guessed) who have no social or team (or spelling) skills, and whose attempts at starting projects or companies always flop.
Slashdot Mirror
A small and ever-decreasing percentage of users compile their own binaries, let alone check the result. Also, not all of the exploits appear only in the binary; in at least one case the malefactors added a fairly hard-to-notice security hole to the CVS source, so the "official" binaries and checksums matched just fine.
Like others, I have modified most of the employment contracts I have signed. At one place, they thought their intellectual property was something special (it wasn't) so they had one of those really greedy, graspy, "everything you ever invented or will invent is ours" clauses. I replaced it with something more reasonable and handed it to the CFO. We went a couple of rounds this way, nothing rancorous, and then he dropped the ball. I guess it sat on his desk for a while and then he forgot about it; he certainly had other things to worry about. Net result is that I never signed.
Fast forward to the day I announced my resignation. Shortly afterward, I got an email from an admin, saying that they couldn't find my employee agreement and asking me to sign the enclosed copy. As you can imagine, I was sorely tempted to respond very rudely, but it wasn't her fault the CFO dropped it. I didn't feel like explaining what had happened, so I just ignored the email and the subject never came up again. It was very satisfying anyway.
There are necessary and beneficial rewrites, but the vast majority of rewrites occur because it's easier to write a new piece of code than to understand an old one. Yes, easier. The "rewrite bug" afflicts brash beginners the most, and top-notch experienced programmers the least. The best programmers tend to get that necessary rewrite out of the way during initial development, by writing a serious first-cut version, throwing it away, and then writing it a second time for real all before anyone else even sees it. Such code will often pass unit tests earlier than the "never refactor" code written by second-raters, and rarely requires a rewrite after that.
That's exactly the point I was going to make, and in fact already made on my own website when this showed up on the aptly-named USS Clueless (where the author of the article here undoubtedly saw it but didn't bother to note the fact). The several types of hypocrisy and dishonesty in how this article has been propagated are IMO the most interesting things about it.
The company (Constellation 3D) working on it finally failed several months ago. The problem didn't seem to be with the basic technology, which actually did work (so I wouldn't really call it vaporware), but with issues such as manufacturing the lens assemblies and the disks themselves for reasonable cost. I wouldn't be a bit surprised if the idea reappears after materials and manufacturing technologies have advanced a bit to make real-world products feasible. Or perhaps the manufacturing problems were truly intractable. It's really hard to tell, but I wouldn't write the whole idea off just yet. We may yet see LEP/OLED or iridescence displays too; it's just the nature of bleeding-edge technology that you have to try a couple of times before you know whether the second- and third-order problems are solvable.
That was revolting.
I don't know if you intended that to be funny, but I almost snorted milk all over my keyboard when I read it. Good one.
Welcome to Garret Hardin's "tragedy of the commons". People occasionally cooperate voluntarily to manage a shared resource, but much more often each person just grabs whatever they can and nothing short of physical force or some other means backed up with the threat of physical force (e.g. a lawsuit) will make them do otherwise. You have just illustrated how laissez-faire fails in the real world.
Even the worst pointy-heads at DoE aren't claiming cold fusion is possible, so we're left with only the hot kind, and that's all well and good as long as you're plugged in but there's a slightly non-trivial need for something that lets you take power with you. Even while you're on the grid, there are issues such as 80% transmission loss that might justify the application of some basic science to overcome. The pedants will point out that such programs exist but the're not covered by a facilities-oriented document, but until such programs get more than a tiny fraction of the facilities budget and until they get enough publicity to start appearing on Slashot that response is just nitpicky BS. There's an anti-usefulness philosophy at DoE that is simply not acceptable in a taxpayer-funded organization, and I say that not as a Luddite (like some utterly ignorant and sociopathic mama's boys on this thread have tried to paint me) but as someone who thinks our overall science budget should be increased. It should just be realigned and its overseers held accountable for how our money is spent, that's all.
Bull. Maybe they're not "pure science" at the "fundamental nature of the universe" level, but they are squarely on the science side of the fence. There's still a lot we don't know about things like proton exchange, for example, or about how mitochondria or chloroplasts work so efficiently, or what's really going on in different types of solar cells. That knowledge is being sought by scientists, in academic labs, not engineers. The DoE actually funds some of it, but at a level that can only be described as a pittance compared to the items on the list. They're warped priorities. Maybe there should be two or three atom-smasher type projects, but not ten. The other money should go to other areas of scientific research that are currently resource-starved, and the fact that projects in some of those areas might have medium-term commercial applications should not disqualify them from consideration. Science should be funded without regard for commerce, not in a manner that's actively inimical to commerce.
Not likely. I'm all for research, but most of the stuff on this list is "big science" only in terms of the money that will be spent, not the knowledge that will be gained. There's tons of biotech, materials-science, computing, optics, and other research that would be more rewarding. The most appalling omission is that the Department of Energy doesn't seem to think that battery technology - the thing holding back deployment of many other technologies - deserves even one project. Nothing on portable fuel cells, microturbines, biodiesel, wave power, or other energy-related technologies either, except fusion. What is the Department of Energy thinking?
There might be a few things in there to write papers about, but if we spend all of the money to fund these projects there won't be any left over for schools...or paper, for that matter. The only way my grandchildren will be writing papers on this stuff is if I or my children move somewhere with a sane science policy.
That appeal to authority, besides being fallacious, doesn't work too well when the person you're addressing is actually a peer to the authority you cite. Many people in this specialty would agree that the characterization of Venti as a block-level system is questionable.
We do. I'm in engineering, though, not marketing, so I didn't think it would be appropriate to introduce those terms into a technical discussion.
Can I use Venti with any old filesystem? No, because it uses its own API instead of the OS-native block read/write. Can I hook up my new Windows, Linux, or FubarOS machine to Venti storage without having to port their API? No, because it's embedded in a particular host environment. Saying Venti is block-level when it only works with one filesystem and OS is like saying that a libc hack is the same as a real distributed filesystem; it's cool as a prototype or research project, but in day-to-day use the limitations inevitably become obvious. I don't know if you've ever worked on actual shipping code, but I've worked on a dozen products that have actually shipped and made money and I can say that production code always differs greatly from its research/prototype forebears.
Venti is great work, I already had Quinlan and Dorwards' FAST 2002 paper on my desk before this conversation began, but it's only loosely related to and by no means the same as what I was talking about...and you were still not quite telling the truth when you said nobody found it useful.
Venti. Filesystem-level, research project, and it was Plan 9 not UNIX. In other words, pretty much totally unlike what I was talking about. Furthermore, others have already mentioned it on this very thread and said it was useful to them, putting the lie to your claim that it's not useful.
Nice troll, kid.
Oh, please don't get me wrong; I love unison. I found it when I was doing some research for one of my own spare-time projects, and was very impressed. It really is better than rsync in a lot of ways. My point in mentioning rsync was just to say "even rsync can do that" in the same way I might say "even tar/cpio can do that" to make the point that non-versioned backup just isn't all that interesting or difficult. IMO file synchronization, backup/restore and source control are related but distinctly different program categories, with complexity in different areas - e.g. conflict detection and resolution for file sync, or branching and merging for source control. It's often possible to use one tool to do another's job, but mature examples in each category tend to specialize toward a particular purpose. There's a large set of "oops, someone screwed up" problems that simply aren't solved with single-version backup, but that are solved with even the most basic versioned backup. If I want to keep the contents of directories on multiple machines identical I'd use unison, but that's not the problem this thread is about. It's a great solution to a different problem.
Yes, but it's trivial to run it twice, once in each direction, with arguments that result in updates propagating in both directions. An interactive interface in this context is definitely in that category you refer to as "profoundly useless"; if I want to synchronize directories I usually have a pretty good idea how conflicts should be resolved and I don't want to be pestered to specify in each case. If I have versioning I can even resolve conflicts the "wrong" way and it's OK because both versions end up in the repository anyway.
Name one. No filesystem-level stuff please, and no snapshots either. I've worked on both kinds of systems before, and they're not what I was talking about. Block level, continuous rollback capability. Got it? Even the more limited kinds of systems, BTW, have proven immensely useful to people, which is probably why EMC and NetApp rake in billions of dollars selling them. I know dozens of people from hands-on sysadmins to Fortune 500 CIOs who have relied on them for years. Just because you couldn't figure out how to take advantage of them doesn't mean nobody else did. Some people are just smarter than others.
...or in anything else, I'll guess. I'll wait for someone with an actual job to comment.
That's actually the key feature here. Unison is great if you want to have just the most recent copy available. Rsync can actually be used in that fashion too, BTW, right out of the box, and it works well too. However, versioning allows you to go back to the most useful prior version of the file, not just the most recent. What if you finally managed to get your configuration right last week, but that version got overwritten by the version with "just one more tweak" that was used for this week's rsync/unison run? Your backup is just as corrupt as your working version now. Backup becomes much more useful when there are multiple restore points, and versioning is an intuitive way to keep track of those restore points. Without that, there are several common "oops" scenarios that backups won't solve.
I guess I should mention, just for the sake of full disclosure (not because it's really relevant) that I'm a product architect at a company seeking to do provide just this sort of "go back to any time" functionality at the block level. Of course I have some strong opinions about the relative utility of "single point in time" vs. continuous backup/restoration, or I wouldn't have taken the job.
...except that the failover won't really be all that seamless, and performance will be in the toilet.
Yeah, Tk is great for quick prototyping. I've used it that way myself for years, and I very recently released some code for general use that was done that way. However, Tk is simply lower level and less polished than wxWindows. Tk has basic widgets that work which is fine for stuff I use myself or give to other developers, but I can recognize a Tk-based UI as such immediately on either Windows or Linux and that's a drawback. WxWindows has more advanced widgets that are indistinguishable from fully-native counterparts and can match the most polished professional applications. When I looked at a list of programs that used wxWindows (somewhere on the wxWindows site) I was actually surprised by some of them. I had used some of them, and it never occurred to me to wonder what framework they used. That's something I've never been able to say about any Tk-based UI, where the framework is in my face and many operations follow the framework model instead of the local UI standard unless someone has done a lot of per-application work to overcome the mismatch.
Yes, there are plenty of packages that attempt to "raise the semantic level" of Tk-based UIs, from grouping radio buttons to providing automagical tabbed dialogs with built-in scrolling canvases and checkbox tree controls. Follow that approach to its logical conclusion, and what do you get? WxWindows. Why use Tk plus this plus that with a little bit of the other and a whole bunch of your own time sanding off the rough edges, when somebody on the wxWindows team has probably already done it? Sure, you have to learn a little bit about how they did it, but that's really no harder than learning how to do it yourself with Tk, and the next programmer has a better chance of understanding what wxWindows did than what you did. Do you want to spend all of your programming time dicking around with character-set issues and varying focus/selection semantics on multiple platforms, or do you have other kinds of problems you'd rather be solving? I know I'd rather not get bogged down writing UI workarounds just to have something that's not butt-ugly. I have better things to do with my programming time.
I stand corrected, and my apologies to the Pastiche folks. I should have remembered that Pastiche is not from Microsoft even though it's based on Pastry which is.
Many responses, even highly-rated ones, seem to be talking about simple replication via NBD (worst-written code I've ever seen) or DRBD. That's not the same as what the original poster was asking about. Neither are fully-distributed but non-transparent file stores such as HiveCache. AFS/DFS/Coda/Intermezzo are probably the closest in the sense of being both transparent and resistant to failures. There have also been a couple of very closely related projects at Microsoft (Farsite and Pastiche) but I'm not sure if there's anything you can actually download and use.
Yeah, because the English are so much less likely than Americans to get sarcasm.
According to AOL's online history, AOL is a 17-year-old. OK, it's a bit of a stretch, you have to count from when they went online instead of when they incorporated and they'd still be less than a month away from 18 years, but that's my story and I'm sticking with it.
...and yet, it does seem to be possible for Windows NDIS drivers running under Linux. Keep in mind that NDIS drivers are, for the most part, not direct-hardware drivers. Many NDIS drivers' only interface is via an API, which could be implemented on any platform (though it is an ugly API so it can be painful).
This kernel developer will tell you that whether or not it's a good idea depends very much on the type of driver and the disparity between OS platforms. I've worked on plenty of drivers where 90% or more of the code was shared between platforms, and in some cases the remainder could have been done by someone else via emulation instead of a linked-in abstraction layer. I don't think running non-native drivers is necessarily a good idea, and performance will always suffer, but it's often a better idea than the alternative which is to implement a complete new driver for poorly-documented hardware in the context of a project whose goal is probably something other than driver writing.
Actually they didn't fire me, and I am in a "leadership role" in my current company. People seem to have put great faith in my social/team skills. It's the anonymous cowards (whose identities are easily guessed) who have no social or team (or spelling) skills, and whose attempts at starting projects or companies always flop.