>When a program I'm developing under linux hits a bad pointer, it core dumps. > >When a program I'm developing under Windows hits a bad pointer, the entire system freezes solid. > >This can increase bug hunting time from a few minutes to a few hours
I hope everyone who reads this will take time to reflect on the fact that this phenomenon of much slower debug cycles affects every driver programmer on (just about) every OS platform, and goes a long way to explain why drivers often aren't available for everyone's OS of choice the day the hardware ships. Sometimes we driver writers actually hold up release of a driver for a particular platform because...*gasp*...it still has bugs that we haven't had time to fix.
>>The only time I have ever managed to crash any *nix system during development was driver development. Otherwise, coredump, load the debugger. > >That's dumb. OSs like Windows and Unix allow considerable extension. If you don't do it right it's your fault.
Mostly I agree with you. However, the OS vendor can be held responsible for driver bugs in two ways:
If the vendor forces things to be done in-kernel because that's the only way they're possible, when those same things could be done out-of-kernel given a reasonable OS structure, then they share responsibility. There are a lot of people writing Windows drivers who shouldn't be writing drivers, and a lot of bugs result from it, all because MS gives them no other option.
The OS vendor can make it easier or harder to write a "correct" driver, and can make it easier or harder for common types of errors (e.g. memory overwrites) to crash the whole system instead of just halting the offending subsystem.
One of my fondest dreams is that sometime before I retire I'll get to work on an OS that adequately isolates the kernel, drivers, filesystems, etc. from one another without tossing performance out the window. So far it's just a dream, though, and will probably remain so as long as address-space manipulation is so inefficient.
>There is at least one problem with this approach: bugfixes.
In the end it depends mostly on whether you expect later DLL versions to fix or introduce bugs. Both happen, but I'd have to say that with MS the latter is more common. That's sad, because statically linked executables are a waste of both disk space and memory, but that's life.
The thing I really hate about MS wrt DLLs is the double standard they apply to distribution. Any MS app is likely to "upgrade" anywhere from a couple to a couple of dozen widely-shared DLLs to the latest version for its own benefit, making each browser upgrade (for example) an OS upgrade in disguise. However, this privilege exists only for MS products. Other vendors can't even ship the official MS-approved versions of system libraries without special permission - rarely given - from MS, let alone versions that have been hacked to their own app's nefarious ends. It's very frustrating to see your app trashed repeatedly by MS apps, and you can't even make sure you're loading the correct version as shipped by MS at some prior time to remain operational.
>one of Linux' strengths is it's well documented source code
I've seen source code for about a half-dozen UNIX flavors, some open and some proprietary. In terms of readability, modularity, and extensibility/maintainability, Linux is at the bottom of the heap - and it's a pretty smelly heap.
One of Linux's strengths is that you _get_ the source code, and that there are many other people around who have already invested the effort to understand it and may be willing to help you if they're not too busy getting off on flaming newbies. That's powerful, and many people quite reasonably believe that these factors matter more than the essential quality of the code. Personally, I'm undecided.
>Only free beer. You don't have the source, and you can't redistribute it.
It doesn't take a rocket scientist to see that there are two questions here, and that people often aren't being clear which they're addressing:
(1) Would Linux survive if Solaris were free(beer)?
(2) Would Linux survive if Solaris were free (libre)?
You seem to think you know the answer to 1, but 2 is the much more interesting question. Sun certainly could open up the source if they wanted to. If people could get Solaris, including source, for free, would they still use Linux?
There seem to be two critical parts of what they're trying to claim:
>having a host processor capable of executing a first instruction set to assist in running instructions of a different instruction set
...and...
>including circuitry for temporarily storing memory stores...
The first part is simply translation of one instruction set into another, something that has been done many times in the past both in software and in hardware including many x86 clones. Nothing new here.
The second part is simply speculative execution, a technique that has been used in bunches of processors already.
To give them credit, they at least attempt to address the non-novelty of the first part in the "prior art" section, but they seem oddly silent regarding prior art relating to the second part. IMNSHO this patent could never hold up in court.
As happens way too often nowadays, the patent office has screwed up and allowed someone to patent what they did not invent. The total inadequacy of the patent office's review process is the real story here.
As someone else already pointed out (but it bears repeating): FPGA = Field Programmable Gate Array.
The problem with FPGA-based computing is that the reprogramming time is very large, so it only yields performance gains when that cost can be amortized over an extremely large number of operations using the current "instruction set". In some specialized cases this can yield amazing performance, and it's way cool, but it's not suitable for general-purpose computing. There is work going on to reduce reprogramming time and/or allow partial reprogramming, but AFAIK there haven't been any major breakthroughs recently.
BTW, I think there were some good discussions of this in an earlier/. article about StarBridge Systems. You might want to give it a look.
>Transmeta seems to have an excellent idea here. They're caching optimized translations of the incoming instructions, so rather than have to translate and optimize over and over each time you see that bit of code, you do it once and then just grab it from the cache.
NexGen already did this, just as you describe, i.e. the i-cache stored instructions in their translated form. I don't know if this approach was retained after AMD bought NexGen, though.
I for one am not saying that gun control shouldn't be discussed. I think it should be discussed passionately and at great length, just as abortion and drug legalization and East Timor and lots of other things should be discussed...but not here. This is not an appropriate or productive forum in which to conduct those particular discussions.
It's really very simple. You may disagree with my attitude, but please don't misrepresent it as apathy.
[Editorial note: I'd give a lot for enough moderation points to moderate down every one of the off-topic gun-control or Katz posts. Get your own damn soapbox.]
I have a theory about why Harris and Klebold didn't go into the cafeteria and shoot lots more people. I suspect the thought process was something like this: We put two propane bombs there and they didn't go off...yet. This may be a suicide mission, but if I go near the bombs I may get my limbs blown off...and live. No, thanks. I think I'll stay away from that area for a while.
Or maybe that wasn't it. These two were clearly not the brightest bulbs in the fixture, especially once the adrenaline got pumping. Maybe they were just in such a frantic hurry that they never sat down and though about how to achieve their goals. Any military veteran could tell you that's common among people who haven't become acclimated to these sorts of stresses, and that's why veteran troops are so much more effective than green ones.
>I swear, by my life and love of it, that I will never live for the sake of another man nor ask another man to live for mine. -- Galt's oath, from Atlas Shrugged >... No Microsoft could live by that oath. However, the GPL does seem to resonate with it, doesn't it?
Au contraire. The GPL, as much as any manifesto I've ever seen, actually tends to devalue original contributions if they're based to any degree on somebody else's prior work - and just about everything in computing is based to some degree on prior work somewhere - by not allowing them to profit even from their own contributions. I won't go quite so far as to say the GPL is socialist, but it's certainly not resonant with Galt's Oath.
Perhaps more importantly, the attitudes of the many people who insist everything be GPLed not out of principle but primarily so they personally can get their grubby little paws all over it and possibly adapt it to their own use without giving anything at all back to "the community" seem to be in direct violation of Galt's Oath. These people most definitely want others to live for their benefit.
Of course, Rand's appeal is mostly based on the observation that simple ideas appeal to simple minds. Most people realize that life is more complex than that, and outgrow Rand before they leave college. Nonetheless, if you're going to base your argument on those ideas, at least try to do it honestly.
>GFS, from the way I understand it, requires that all disk devices need to be shared between multiple servers by physical bus connections and specifically SCSI connections. A lot of the "wasted" space on my network is IDE.
Say no more, say no more.;-) Network and distributed filesystems with independent storage are one thing, cluster filesystems with shared storage quite another. I've done both, BTW, but unfortunately those projects have not (yet) seen the light of day due mostly to non-technical concerns. The sad thing is that many of the techniques involved are common across the two classes, but very few people have tried to tackle both at once with a common approach - Ed Lee's work first on Echo and then on Petal/Frangipani at DEC SRC come to mind.
Your answers to my earlier questions actually lead me to believe that yours is a relatively easy case. I can see three ways to go:
Use NFS and automount, put up with the lousy coherency (which doesn't seem to matter for your situation) and just make sure you don't get into nasty cross-mounting messes etc. NFS may be totally unsuited for many more demanding environments, but as of v3 it really does handle the easy cases pretty well.
Reconsider Coda. Yes, the local-cache issue is annoying and the result will be less than ideal, but it may still be "good enough".
Consider combining GFS with a "virtual shared disk" driver to resolve the expectation of shared storage. I strongly encourage you to contact Matt O'Keeffe and friends at UMN about this; they're bright guys who would probably be delighted to brainstorm with you, and it might very well be that something near-ideal can be worked out.
I don't usually respond to such petty comments, but I can't resist pointing out that I didn't mention what I'm working on now. I don't believe in peddling vapor.
Many people seem to be jumping in with suggested solutions, but it seems to me that the problem has not yet been adequately described. For example:
What kind of sharing do you anticipate? Some systems that handle read-only sharing well fall down when even a single writer enters the picture.
Aside from efficiency, what kind of coherency guarantees are you comfortable with? Some systems will behave exactly like a local filesystem in terms of what happens when one client writes and another reads, and can be used for "network-unaware" applications. Others, notably NFS, play "fast and loose" so you have to do explicit performance-robbing flushes to have any sort of guarantees. If you put build trees on a distributed/network filesystem you have to worry about when file modification times get updated, as well as about the file contents themselves; having "make" mistakenly tell you nothing needs to be done can be more than a little annoying.
What kind of failure-recovery guarantees do you need? Is it OK to lose the odd unflushed write every now and then after a failure?
Do you need support for either advisory or mandatory byte-range locks?
I'm also curious what you found lacking in GFS. I have my own different ideas about "how things should be done" but perhaps explaining why you consider it inappropriate will shed some light on your needs.
As far as practical advice goes, I think most of the relevant products and approaches have been mentioned; I don't promise to have secret knowledge of any "magic bullets". DFS technology is an area where I feel we're still looking for the right answers (sometimes even the right questions). That's why I enjoy working on DFSes, but it does mean that there's a large element of "choose your poison" in evaluating current offerings.
>but is already faster than Ext2fs, and way ahead of XFS and NTFS.
By what measures and for what workloads? Such claims are meaningless without describing the environment, and are the realm of marketroids (particularly the MS kind) not scientists or engineers.
I find it most odd that you would tout the system's distributed nature and then compare it only against local FSes. How well does it perform in sharing situations, either locally or through slow WAN links? What level of coherency does it guarantee? How is failure recovery (a very tricky issue for a DFS) handled? How about disconnected operation?
To be perfectly blunt, the lack of even an attempt to address these sorts of crucial issues makes me wonder whether the part about Charon being distributed is "part of the plan" that hasn't actually been implemented (or even designed) yet. The DFS literature is littered with papers about systems that would supposedly blow everything else away, but that never actually got implemented. I've been there, I've done that, and the sad truth is that the realities of implementing a usable DFS - i.e. one that isn't pathologically ill-behaved in at least one of the areas alluded to above - generally shred naive ideals of superfast coolness.
>Only changed disk blocks and metadata are replicated, as opposed to entire files (and only on close)
If this is really what you meant to say, it's great performance but has dire implications for recoverability. This only strengthens my suspicion that you haven't really climbed into the mud pit in earnest yet.
I went to work at Mango once because I believe in the general concept of a location-transparent distributed file system and at a theoretical level they seemed to be on the right track. I no longer work at Mango because at a practical level their implementation is an overburdened pile of junk.
What Windows calls "DFS" is a joke to anyone who has any experience with real Distributed File Systems. They're just kludges on top of an old-fashioned network file system - a term with its own precise taxonomic meaning, not necessarily referring to Sun's presumptuously-named instance of that class - much like adding automount and NIS to Sun's NFS.
>Theseus Logic and Cogency are two that come to mind
Good links, and thank you. Cogency looked very real and very interesting to me, and I encourage others to check it out. Theseus, though...well, that's different. I couldn't decide whether it was a buzzword-filled scam a la Starbridge, or a deliberate parody. Treated as humor, I particularly liked the "Critical Review of the Notion of the Algorithm in Computer Science".
>I doubt there will be anything usable in that area for several years, if not decades
I think you're too pessimistic. IIRC, there was an asynchronous implementation of the ARM ISA called Amulet, which was just a hair away from going commercial. If they could get that close a few years ago, it's no stretch to think someone else might go all the way this year or next.
>I was advocating going beyond this to defining multiple levels of locking granularity, i.e., allowing you to control how finely threaded the kernel is. That is not currently done, AFAIK.
I don't think it's done in either Linux or NT, but I certainly have seen it done. One variant of UNIX that I worked on could be configured to lock STREAMS modules either globally, per-major, or per-minor. Another did much of its locking using hashed locks; the degenerate case was one bucket, but you could add buckets to increase parallelism.
The problem that arises with these approaches is that the deadlock possibilities tend to be different at each level of locking, and need to be addressed separately. It's like having to do the locking three times three different ways for the same code. Once finer-grain locking has been implemented for a component or subsystem, the developers would generally prefer to turn their backs on the coarser stuff immediately.
>I am also tired of people not understanding the difference between someone who is just different and someone who is functionally impaired and needs help.
This reminds me of a behavior that is the bane of code reviews: wasting everyone's time criticizing things because "I would have done it differently" instead of sticking to things that actually fail. I agree with you: the world would be better off if people could distinguish between matters of personal taste and matters of objectively measurable difference.
>Now, I imagine that we could define multiple "levels" of locks in the kernel...
Yes, this has been done many times, and it works great. I know NT has multiprocessor and uniprocessor kernels that are distinguished from one another in pretty much the way you describe, and I thought Linux had build flags to that effect too (but there I'm less certain).
One gotcha: it's a good idea to install the MP kernel if the hardware is MP-capable even if it only actually has one proc installed. Otherwise, you add the second CPU later, reboot and BLAM! Race conditions etc. out the wazoo. MS screwed this up with NT, burning lots of people who installed with a single processor and then upgraded to two later. You pretty much have to reinstall the OS. IMX, copying ntkrnlmp.exe from your install CD over ntoskrnl.exe works, but I wouldn't count on that being universal. Some platforms may have separate HAL modules, and MS may have extended their broken thinking to drivers since I last tried this.
Forget conflicts of interest, how about outright intellectual property theft? At one company I worked for, a contractor walked out with a tape of our source code, which as little as a month later started showing up in a direct competitor's product. I know because my next employer licensed the code from the recipient of stolen goods, and I recognized some of it as my own.
OTOH, I've seen regular employees carry code from one job to another and reuse it in their new projects without a twinge of conscience too. I think it's only the sheer turnover rate that makes this more of a problem with contractors.
>The best developers are worth upwards of $150/hr, and if you want to keep them on your staff, PAY THE MONEY.
There's a problem with this. Management generally doesn't have the slightest clue who's performing and who's not. They sure as heck can't pay everyone $150/hour, and if they can't tell the difference between diamonds and coal there's a very real risk they'll be rewarding the wrong people. This will create even greater alienation among the good employees, and hasten their departure out the door. Maybe in the long term allowing poorly-managed companies to fail in this way would be a good thing, but in the short term I'm not sure the industry can tolerate such a high mortality rate.
Slashdot Mirror
>When a program I'm developing under linux hits a bad pointer, it core dumps.
>
>When a program I'm developing under Windows hits a bad pointer, the entire system freezes solid.
>
>This can increase bug hunting time from a few minutes to a few hours
I hope everyone who reads this will take time to reflect on the fact that this phenomenon of much slower debug cycles affects every driver programmer on (just about) every OS platform, and goes a long way to explain why drivers often aren't available for everyone's OS of choice the day the hardware ships. Sometimes we driver writers actually hold up release of a driver for a particular platform because...*gasp*...it still has bugs that we haven't had time to fix.
>
>That's dumb. OSs like Windows and Unix allow considerable extension. If you don't do it right it's your fault.
Mostly I agree with you. However, the OS vendor can be held responsible for driver bugs in two ways:
One of my fondest dreams is that sometime before I retire I'll get to work on an OS that adequately isolates the kernel, drivers, filesystems, etc. from one another without tossing performance out the window. So far it's just a dream, though, and will probably remain so as long as address-space manipulation is so inefficient.
>There is at least one problem with this approach: bugfixes.
In the end it depends mostly on whether you expect later DLL versions to fix or introduce bugs. Both happen, but I'd have to say that with MS the latter is more common. That's sad, because statically linked executables are a waste of both disk space and memory, but that's life.
The thing I really hate about MS wrt DLLs is the double standard they apply to distribution. Any MS app is likely to "upgrade" anywhere from a couple to a couple of dozen widely-shared DLLs to the latest version for its own benefit, making each browser upgrade (for example) an OS upgrade in disguise. However, this privilege exists only for MS products. Other vendors can't even ship the official MS-approved versions of system libraries without special permission - rarely given - from MS, let alone versions that have been hacked to their own app's nefarious ends. It's very frustrating to see your app trashed repeatedly by MS apps, and you can't even make sure you're loading the correct version as shipped by MS at some prior time to remain operational.
>one of Linux' strengths is it's well documented source code
I've seen source code for about a half-dozen UNIX flavors, some open and some proprietary. In terms of readability, modularity, and extensibility/maintainability, Linux is at the bottom of the heap - and it's a pretty smelly heap.
One of Linux's strengths is that you _get_ the source code, and that there are many other people around who have already invested the effort to understand it and may be willing to help you if they're not too busy getting off on flaming newbies. That's powerful, and many people quite reasonably believe that these factors matter more than the essential quality of the code. Personally, I'm undecided.
>Only free beer. You don't have the source, and you can't redistribute it.
It doesn't take a rocket scientist to see that there are two questions here, and that people often aren't being clear which they're addressing:
(1) Would Linux survive if Solaris were free(beer)?
(2) Would Linux survive if Solaris were free (libre)?
You seem to think you know the answer to 1, but 2 is the much more interesting question. Sun certainly could open up the source if they wanted to. If people could get Solaris, including source, for free, would they still use Linux?
There seem to be two critical parts of what they're trying to claim:
>having a host processor capable of executing a first instruction set to assist in running instructions of a different instruction set
...and...
>including circuitry for temporarily storing memory stores...
The first part is simply translation of one instruction set into another, something that has been done many times in the past both in software and in hardware including many x86 clones. Nothing new here.
The second part is simply speculative execution, a technique that has been used in bunches of processors already.
To give them credit, they at least attempt to address the non-novelty of the first part in the "prior art" section, but they seem oddly silent regarding prior art relating to the second part. IMNSHO this patent could never hold up in court.
As happens way too often nowadays, the patent office has screwed up and allowed someone to patent what they did not invent. The total inadequacy of the patent office's review process is the real story here.
As someone else already pointed out (but it bears repeating): FPGA = Field Programmable Gate Array.
/. article about StarBridge Systems. You might want to give it a look.
The problem with FPGA-based computing is that the reprogramming time is very large, so it only yields performance gains when that cost can be amortized over an extremely large number of operations using the current "instruction set". In some specialized cases this can yield amazing performance, and it's way cool, but it's not suitable for general-purpose computing. There is work going on to reduce reprogramming time and/or allow partial reprogramming, but AFAIK there haven't been any major breakthroughs recently.
BTW, I think there were some good discussions of this in an earlier
>Transmeta seems to have an excellent idea here. They're caching optimized translations of the incoming instructions, so rather than have to translate and optimize over and over each time you see that bit of code, you do it once and then just grab it from the cache.
NexGen already did this, just as you describe, i.e. the i-cache stored instructions in their translated form. I don't know if this approach was retained after AMD bought NexGen, though.
>of course, you're also an insulting prick. Why do you always make personal attacks? Small penis?
The irony meter is pegged, sir.
I for one am not saying that gun control shouldn't be discussed. I think it should be discussed passionately and at great length, just as abortion and drug legalization and East Timor and lots of other things should be discussed...but not here. This is not an appropriate or productive forum in which to conduct those particular discussions.
It's really very simple. You may disagree with my attitude, but please don't misrepresent it as apathy.
[Editorial note: I'd give a lot for enough moderation points to moderate down every one of the off-topic gun-control or Katz posts. Get your own damn soapbox.]
I have a theory about why Harris and Klebold didn't go into the cafeteria and shoot lots more people. I suspect the thought process was something like this: We put two propane bombs there and they didn't go off...yet. This may be a suicide mission, but if I go near the bombs I may get my limbs blown off...and live. No, thanks. I think I'll stay away from that area for a while.
Or maybe that wasn't it. These two were clearly not the brightest bulbs in the fixture, especially once the adrenaline got pumping. Maybe they were just in such a frantic hurry that they never sat down and though about how to achieve their goals. Any military veteran could tell you that's common among people who haven't become acclimated to these sorts of stresses, and that's why veteran troops are so much more effective than green ones.
>I swear, by my life and love of it, that I will never live for the sake of another man nor ask another man to live for mine.
-- Galt's oath, from Atlas Shrugged
>... No Microsoft could live by that oath. However, the GPL does seem to resonate with it, doesn't it?
Au contraire. The GPL, as much as any manifesto I've ever seen, actually tends to devalue original contributions if they're based to any degree on somebody else's prior work - and just about everything in computing is based to some degree on prior work somewhere - by not allowing them to profit even from their own contributions. I won't go quite so far as to say the GPL is socialist, but it's certainly not resonant with Galt's Oath.
Perhaps more importantly, the attitudes of the many people who insist everything be GPLed not out of principle but primarily so they personally can get their grubby little paws all over it and possibly adapt it to their own use without giving anything at all back to "the community" seem to be in direct violation of Galt's Oath. These people most definitely want others to live for their benefit.
Of course, Rand's appeal is mostly based on the observation that simple ideas appeal to simple minds. Most people realize that life is more complex than that, and outgrow Rand before they leave college. Nonetheless, if you're going to base your argument on those ideas, at least try to do it honestly.
Say no more, say no more.
Your answers to my earlier questions actually lead me to believe that yours is a relatively easy case. I can see three ways to go:
>Just because you didn't succeed...
I don't usually respond to such petty comments, but I can't resist pointing out that I didn't mention what I'm working on now. I don't believe in peddling vapor.
I'm also curious what you found lacking in GFS. I have my own different ideas about "how things should be done" but perhaps explaining why you consider it inappropriate will shed some light on your needs.
As far as practical advice goes, I think most of the relevant products and approaches have been mentioned; I don't promise to have secret knowledge of any "magic bullets". DFS technology is an area where I feel we're still looking for the right answers (sometimes even the right questions). That's why I enjoy working on DFSes, but it does mean that there's a large element of "choose your poison" in evaluating current offerings.
>but is already faster than Ext2fs, and way ahead of XFS and NTFS.
By what measures and for what workloads? Such claims are meaningless without describing the environment, and are the realm of marketroids (particularly the MS kind) not scientists or engineers.
I find it most odd that you would tout the system's distributed nature and then compare it only against local FSes. How well does it perform in sharing situations, either locally or through slow WAN links? What level of coherency does it guarantee? How is failure recovery (a very tricky issue for a DFS) handled? How about disconnected operation?
To be perfectly blunt, the lack of even an attempt to address these sorts of crucial issues makes me wonder whether the part about Charon being distributed is "part of the plan" that hasn't actually been implemented (or even designed) yet. The DFS literature is littered with papers about systems that would supposedly blow everything else away, but that never actually got implemented. I've been there, I've done that, and the sad truth is that the realities of implementing a usable DFS - i.e. one that isn't pathologically ill-behaved in at least one of the areas alluded to above - generally shred naive ideals of superfast coolness.
>Only changed disk blocks and metadata are replicated, as opposed to entire files (and only on close)
If this is really what you meant to say, it's great performance but has dire implications for recoverability. This only strengthens my suspicion that you haven't really climbed into the mud pit in earnest yet.
I went to work at Mango once because I believe in the general concept of a location-transparent distributed file system and at a theoretical level they seemed to be on the right track. I no longer work at Mango because at a practical level their implementation is an overburdened pile of junk.
What Windows calls "DFS" is a joke to anyone who has any experience with real Distributed File Systems. They're just kludges on top of an old-fashioned network file system - a term with its own precise taxonomic meaning, not necessarily referring to Sun's presumptuously-named instance of that class - much like adding automount and NIS to Sun's NFS.
>Theseus Logic and Cogency are two that come to mind
Good links, and thank you. Cogency looked very real and very interesting to me, and I encourage others to check it out. Theseus, though...well, that's different. I couldn't decide whether it was a buzzword-filled scam a la Starbridge, or a deliberate parody. Treated as humor, I particularly liked the "Critical Review of the Notion of the Algorithm in Computer Science".
>I doubt there will be anything usable in that area for several years, if not decades
I think you're too pessimistic. IIRC, there was an asynchronous implementation of the ARM ISA called Amulet, which was just a hair away from going commercial. If they could get that close a few years ago, it's no stretch to think someone else might go all the way this year or next.
>I was advocating going beyond this to defining multiple levels of locking granularity, i.e., allowing you to control how finely threaded the kernel is. That is not currently done, AFAIK.
I don't think it's done in either Linux or NT, but I certainly have seen it done. One variant of UNIX that I worked on could be configured to lock STREAMS modules either globally, per-major, or per-minor. Another did much of its locking using hashed locks; the degenerate case was one bucket, but you could add buckets to increase parallelism.
The problem that arises with these approaches is that the deadlock possibilities tend to be different at each level of locking, and need to be addressed separately. It's like having to do the locking three times three different ways for the same code. Once finer-grain locking has been implemented for a component or subsystem, the developers would generally prefer to turn their backs on the coarser stuff immediately.
>I am also tired of people not understanding the difference between someone who is just different and someone who is functionally impaired and needs help.
This reminds me of a behavior that is the bane of code reviews: wasting everyone's time criticizing things because "I would have done it differently" instead of sticking to things that actually fail. I agree with you: the world would be better off if people could distinguish between matters of personal taste and matters of objectively measurable difference.
>Now, I imagine that we could define multiple "levels" of locks in the kernel...
Yes, this has been done many times, and it works great. I know NT has multiprocessor and uniprocessor kernels that are distinguished from one another in pretty much the way you describe, and I thought Linux had build flags to that effect too (but there I'm less certain).
One gotcha: it's a good idea to install the MP kernel if the hardware is MP-capable even if it only actually has one proc installed. Otherwise, you add the second CPU later, reboot and BLAM! Race conditions etc. out the wazoo. MS screwed this up with NT, burning lots of people who installed with a single processor and then upgraded to two later. You pretty much have to reinstall the OS. IMX, copying ntkrnlmp.exe from your install CD over ntoskrnl.exe works, but I wouldn't count on that being universal. Some platforms may have separate HAL modules, and MS may have extended their broken thinking to drivers since I last tried this.
>Conflicts of interest often arise
Forget conflicts of interest, how about outright intellectual property theft? At one company I worked for, a contractor walked out with a tape of our source code, which as little as a month later started showing up in a direct competitor's product. I know because my next employer licensed the code from the recipient of stolen goods, and I recognized some of it as my own.
OTOH, I've seen regular employees carry code from one job to another and reuse it in their new projects without a twinge of conscience too. I think it's only the sheer turnover rate that makes this more of a problem with contractors.
>The best developers are worth upwards of $150/hr, and if you want to keep them on your staff, PAY THE MONEY.
There's a problem with this. Management generally doesn't have the slightest clue who's performing and who's not. They sure as heck can't pay everyone $150/hour, and if they can't tell the difference between diamonds and coal there's a very real risk they'll be rewarding the wrong people. This will create even greater alienation among the good employees, and hasten their departure out the door. Maybe in the long term allowing poorly-managed companies to fail in this way would be a good thing, but in the short term I'm not sure the industry can tolerate such a high mortality rate.