I suspect the reason why they won't release their driver code is because it may reveal too much about the specialized workings of their hardware. I suspect they have hundreds of man-years of work tied up there.
It's the double standards about this argument that bother me. If it was not for proprietary software, the GPL movement and the GNU free software directory would not exist. The GNU tools were all initially developed on Solaris and other proprietary operating systems before a kernel even existed.
Even the Linux kernel is far from perfect. On 90%+ of the installations out there it is bootstrapped by a proprietary bootloader/BIOS. I don't hear any of the GPL zealots complaining about that. It supports the loading of non-GPL proprietary modules because - gasp - most users would rather have their graphics hardware supported rather than get religious about the GPL - what a disgrace that people expect to be able to *use* the hardware they paid for with their favourite OS. How shocking it is that people would abandon their free software convictions just so that they could use the wireless access device on their laptop! Isn't that outrageous ?
Well no it isn't actually. Free software has made outstanding achievements and in many ways has revolutionized the way many people and corporations think about their software infrastructure. However there are gaps that must be plugged by proprietary tools in the highly specialized areas that open source - for some reason or another - does not seem to be able to reach.
Great idea. Linus should stop writing kernel code (what everyone seems to think he's good at) and create *yet another* GPL revision control system to add to the 20-odd that already exist.
I wish I could shoot anyone who uses the cliched catchphrase "I for one".
Microsoft allegedly use Perforce. VSS is an absolute turd.
Clearcase is nice in many respects, but to get that niceness you have to pay top dollar. Not only do you pay for the licenses, but then there's the training (Clearcase usage - particularly administration - is highly specialized), the Clearcase admin ($$$$) and the big machines you need to run the view and VOB servers. But what you get is ideal - the revision control database is completely transparent to userspace applications, and it's impossible of users to delete or corrupt the metadata. The Multisite extension, while expensive, allows a lot of powerful options when dealing with a distributed source base. The nicest feature of all is the build avoidance capability.
However there are many aspects about it which are thoroughly unsatisfying. It's the little details that cause all the time to be wasted. One particularly irritating thing that bugs me is that if you edit your configuration spec and make a typo in a label or branch, Clearcase doesn't tell you, and you'll be working away merrily, blissfully unaware that the baseline you're working with is not the one you intended. Another irritating aspect is that some of the commands are long and have all kinds of detailed options. What you end up doing is writing a whole bunch of wrapper scripts, and the upshot of that of course is that no two Clearcase sites are the same so your experience does not transfer so easily from one place to another. For example in base Clearcase the command to find out what changes are in another branch the command is:
Nobody can be penalized for using software licensed under the existing GPL version 2 license, and the article is quite misleading to suggest that that may be the case. Licenses cannot be applied retrospectively.
However new works distributed under the GPL 3.0 license would be subject to this restriction. That isn't likely to cause considerable pain to either Google or Amazon.
Unfortunately the license has rather more serious implications particularly for things like embedded devices. Say you are an ISP and you use a particular router, which includes some GPL code, to support 250 customers. Since those customers are benefitting from a GPL-inclusive service, are all of those customers entitled to download the sourcecode ? In many respects this new license could be unattractive for many commercial vendors who may chose not to deal with works licensed under it.
About as happy as they have been with GCC bugs. They have seen more than their share of those, and they will deal with them in the same way.
I don't think it's the same issue, Bruce. If GCC is broken you use the previous version. Easy.
If your revision control database gets corrupted due to a bug, you need to wait for someone to fix it. Integration work is suspended while it gets sorted out. Testers can't grab the latest kernel because the database is offline, their work stops too. Unless there is someone employed as a full time SCM administrator how will development proceed unimpeded ?
Couldn't I apply all of your arguments to Open Source in general? Shouldn't they be using Microsoft C and Visual SourceSafe for the wonderful support they'd get?
For these things to work properly you need support. I use "support" in it's loosest term, ie "someone nearby who knows about the program and is able to help". You need people who know how it works to fix it for you when it breaks. VSS isn't very good, in fact M$ don't even use it for their own work internally, bit of a sham really. I wouldn't tell anyone to use a product the vendor itself didn't even trust. Even CVS is better than VSS.
Regarding MS C, the thing is that GCC, unlike the various OSS SCM systems, meets the "good enough" definition. That brings me to the next big question which I have, which is - would GCC or the rest of the GNU toolset ever have reached the point they have if proprietary operating systems such as Solaris or HP-UX did not exist for Stallman and his successors to develop on ? It seemed more than acceptable to the GNU people to work along with proprietary systems when no usable alternative was available (it's a pity that does not apply in the case we are discussing). How fortunate we are that Bell/AT&T were not a little more careful when it came to looking after their source code.
Linux has developed quickly (compared with ideologically pure examples such as the Hurd) because it bends the rules a little bit and borrowed the rich pickings from the commercial world. Strictly speaking binary modules are a breach of the GPL, but Linus and the developers bent the rules. If they didn't, a significant number of machines today would not run Linux or would not support advanced graphics or wireless devices under Linux. An even stricter application of the GPL might suggest that BIOSs and bootloaders used to bootstrap machines, not only your x86s but your SPARC boxen and IBM big-iron, come under it's licensing remit.
What you have to accept is that successful open source projects are where they are today because a proprietary platform existed to bootstrap them into feasibility. Commercial organizations are playing along because they expect to get out what they put in. It doesn't matter who it is - IBM, Red Hat, Intel with their drivers, Bitmover or anyone else. In each of those cases you can bet your bottom dollar that if any of those companies start to believe that open source involvement is undermining their intellectual property base, they'll pull out and start invoking their patents.
Whatever they were thinking of, it didn't work. That's business - sometimes you lose. It seems that others have better ideas than Subversion.
That's the other problem, there's about a zillion of them, and all of them are so-so. Especially when it comes to SCM, for some unfathomable reason, people seem to prefer to go and reinvent the wheel to build their own system, rather than step in to help improve someone else's. After the BK flamewars on LKML go away, the next series of fun and exciting instalments to look forward to will be long drawn out criticism over the system that Linus eventually chooses as a replacement.
Will kernel developers be happy to wait around while the bugs gets sorted out ? Will they tolerate having the integration tree rolled back to an earlier state to remove corrupt data ? That's the question. They are used to a pace of development, a degree of change, and a degree of participation which outstrips that seen on other major open source projects such as GCC or *BSD for example. They've spent three years under a regime where they don't have to wait around. How will they react to SCM problems cropping up ?
They will support it as well as they can without leaving their day jobs.
Time will tell if that is good enough. I'm concerned that it will not be. Linus obviously did not think so given that he has consistently rejected the alternatives to BK to date. As we all know the kernel people are a prickly bunch and some of them aren't so well known for their tolerance when it comes to matters like this. I hope the developers of $(new_kernel_SCM) will take the abuse for as long as Larry did.
This was already going on, anyway - there are several folks funding various sorts of Open Source version control.
And how long are they going to keep doing that ? I can't imagine how much money Tigris have put into Subversion at this stage, and look at the criticism the product continues to incur and the major back-end overhauls that have been taking place. What are they going to do when the day comes when shareholders or investors start looking for RoI ? It's a cold hard reality.
Seems to be that a lot of the open source movement - with it's gargantuan achievements over recent years - still relies on private support and private funding in one way or another. In some respects I might go so far as to say that the ostensible "freedom" is underpinned in many cases by the marketing and R&D departments of several large corporations. I would love to believe that eventually the community will come to have momentum all by itself, but I'm concerned that it might not and I hope people don't take their eye off the ball on that matter.
I've never seen handing your data over to be managed by proprietary software product as "practical".
Obviously you don't work in the real world, where tens of thousands of companies pay money for proprietary software that their entire business is based on in exchange for products that work and reliable support. They continue to do so because in a pragmatic world, the ideological objective of software freedom doesn't stand up to the practical reality of running a business.
Sure you can make a business out of open source, but you have to put up a fight, in the way that Red Hat are doing. And even with Red Hat, they have to add proprietary components to the mix (cluster manager, GFS..) to make it competitive. If Red Hat were nothing other than a few experts on the end of the phone they'd have been gone long ago.
Have you ever tried to use arch ? The command set and user interface is plain cryptic. The weird idiosynchracies such as the {arch} subdirectory for metadata and the weird commands make it very hard to remember.
Arch and Darcs are the right way to proceed, but make crucial mistakes in their implementation. Maybe monotone will not repeat those mistakes.
The trouble is though, the kernel community who were behind causing the end of this win-win productive relationship are people who are more interested in creating a revolution of their own rather than producing great free software. Despite the project leader repeatedly laying down the rules in clear terms they sought to undermine them. In the end you got a power-struggle and as a result the zealots got what they wanted.
Well now the folks out there who said "arch is good" will now have to put their money where their mouth is and show how those alternative tools can take the place of BK for kernel maintenance. I hope that when the flamewars on the mailing list over dropped patches or corruption commence they too will be able to take what they gave on the "I told you so" front.
Bruce, I greatly respect your opinions and your contribution on most subjects but I don't agree on this one.
There are serious consequences to making the wrong choice when it comes to revision control. You've got a choice between the tried and tested such as CVS, which took years to get right, and which work but are frankly crap and get in the way - let's face it. On the other hand you can try out the new and experimental systems which dramatically improve productivity but are not tried and tested. BK bridged that gulf and provided the best of both worlds, but certain loud whiners denounced it as being against their religion and worked to undermine it ever since.
You talk about those 1000 developers - what do they do when the revision control system hits a bug or the database gets corrupted, and no-one is available to fix it ? I'd love to believe that there would be an army of dedicated people waiting in the wings, ready to step in and immediately fix the bug or the corruption in the same way that Bitkeeper did. Who is going to pay for people to do that ? Are the monotone developers going to walk out of their day-jobs and support the kernel SCM for nothing ?
Of course what might happen is one of the big corporations such as RH or IBM will generously fund an engineer to work on one of these SCM systems (notwithstanding IBM's Clearcase commitment) in which case you're back right where you were - dependency on the whims of a corporation.
I think the kernel community will live to regret making life unnecessarily hard for the BK people and will come to miss the scalability that it provided. True, in 18 months or so monotone or whatever Linus chooses may well get to the point where it is usable - no doubt after a few nasty crashes and dropped patches.
But it's true, linus didn't consider the nature of what he was using and got burned.
Burned ? This statement is utterly ignorant of the dynamics within the kernel development process whenever BK was adopted. Linus, outstanding engineer that he is, was overloaded and was at the brink of hitting the bricks - the volume of work coming into the kernel was too much. The adoption of BK not only rescued the kernel development process from the brink of the abyss but increased by an order of magnitude the degree of change getting integrated.
Linus and Greg KH have both put out statements to the effect that they have greatly valued BK's use in the kernel and that they will learn lessons from it. If they got burned don't you think they'd have said so ?
Fusion reactors don't work yet, they are still experimental. The record energy output so far at JET is something like 70% of the input energy. ITER is expected to exceed the break-even point but that will be at least another ten years away.
Sorry but it's completely ignorant to talk about people failing to follow procedure regarding the Chernobyl accident. To use terms like "stupidity" to describe the people involved is an insult, unless you are referring to the Soviet powers that were in which case it applies entirely.
Like everything else about the way things were done in the Soviet Union, the procedures weren't well defined and half of the plant's design was shrouded in secrecy. The workers in the plant were not told about the positive void coefficient characteristic which led directly to the accident, it was regarded as a military secret. They were improperly trained in the plant operation in general.
The international authority which investigated Chernobyl, AFAIK, revised the cause of the accident such that it was blamed on the design of the plant and the positive void coefficient, rather than the personnel operating it.
SOB is the well known record, but Carlos improved considerably on the techniques used. The Well Tempered Synthesizer is a much better album in many respects, and by the time of the Switched-On Brandenburgs she'd taken the Moog synth as far as it could go in that area.
Well worth checking out are the Sonic Seasonings album (very early ambient soundscapes) and the soundtrack to Tron which features loads of Moog bass goodness together with live orchestra and early digitial synthesis.
I find it hard to see that Microsoft's license would be any more liberal than the one that Sun have used to open up Solaris 10.
"Sure you can look at it, but you can't use it without relicensing your code under our license. And if we find our code in any of your work we'll sue you. "
Thanks for that. I confess to not knowing much about the low-level implementations of these algorithms in the major OSs but I suspect what you say is true, the OS probably does page out unfrequently used stuff when it sees that memory is running low.
I agree with you, I can't see how anyone would claim that forcing the page swapper to pass through the filesystem layer, rather than writing the pages directly at the device level, is somehow better.
The Windows method of going through the filesystem is going to be pretty inefficient, especially given that we're talking about NTFS here.
I am not sure about the article's validity when it claims that swapfiles are distinct from paging files. There are other claims, such as the implication that Microsoft invented the term "virtual memory", that are also rather misleading.
It's not a matter of swapping "pre-emptively". The whole business is invisible to the user space and the locking is essentially done by the kernel. The CPU hardware (ie the MMU) basically watches every single memory access when the CPU is in the appropriate mode (ie protected mode on an x86). It has a list of mappings of address spaces in it's own small internal page table.
What happens is that every time you access a region of virtual memory (for example anywhere in user space), the MMU looks up the address in it's own list of pages. If the associated region is not mapped by the MMU, a page fault occurs which is essentially an interrupt which gets trapped by the operating system. The operating system checks to see if it has a mapping for that address.
If it does, it checks to see if that mapping is either resident, or a block which has been paged out to disk (ie to the paging file). If it has been page out to disk, another block of memory gets paged out and the requested region is paged back in.
The MMU's cache of pages gets cleared on most CPUs whenever there is a process context switch (but not a thread context switch), this is one of the big reasons why threads are less expensive than processes because the MMU's cache of pages has to be repopulated.
The algorithm used to select which region of memory gets paged out is where the real trickery is. Obviously if you are low on memory and switch repeatedly between two busy proesses, you will be constantly thrashing those pages on and off the disk.
There are good arguments in favour of keeping your file sizes down, eg to something like 10K, and splitting your functions over several files. The big one being turnaround time; if you have a multiprocessor machine your parallel builds can compile all the parts in parallel. Also if you make a change to a function in one of the files the compiler only needs to recompile that file and not your entire driver.
Obviously though there are reasonable constraints to this.
Yes I know, there are a few of the lower-end SCM systems that show you the price. However the higher end ones don't. That list includes BitKeeper, Clearcase, MKS Integrity, AccuRev, CM Synergy, etc. This is true of a lot of large-scale corporate application suites.
Slashdot Mirror
I suspect the reason why they won't release their driver code is because it may reveal too much about the specialized workings of their hardware. I suspect they have hundreds of man-years of work tied up there.
That's the thing, he doesn't have a new opinion.
It's the double standards about this argument that bother me. If it was not for proprietary software, the GPL movement and the GNU free software directory would not exist. The GNU tools were all initially developed on Solaris and other proprietary operating systems before a kernel even existed.
Even the Linux kernel is far from perfect. On 90%+ of the installations out there it is bootstrapped by a proprietary bootloader/BIOS. I don't hear any of the GPL zealots complaining about that. It supports the loading of non-GPL proprietary modules because - gasp - most users would rather have their graphics hardware supported rather than get religious about the GPL - what a disgrace that people expect to be able to *use* the hardware they paid for with their favourite OS. How shocking it is that people would abandon their free software convictions just so that they could use the wireless access device on their laptop! Isn't that outrageous ?
Well no it isn't actually. Free software has made outstanding achievements and in many ways has revolutionized the way many people and corporations think about their software infrastructure. However there are gaps that must be plugged by proprietary tools in the highly specialized areas that open source - for some reason or another - does not seem to be able to reach.
Great idea. Linus should stop writing kernel code (what everyone seems to think he's good at) and create *yet another* GPL revision control system to add to the 20-odd that already exist.
I wish I could shoot anyone who uses the cliched catchphrase "I for one".
Microsoft allegedly use Perforce. VSS is an absolute turd.
:
.../ -print
:
Clearcase is nice in many respects, but to get that niceness you have to pay top dollar. Not only do you pay for the licenses, but then there's the training (Clearcase usage - particularly administration - is highly specialized), the Clearcase admin ($$$$) and the big machines you need to run the view and VOB servers. But what you get is ideal - the revision control database is completely transparent to userspace applications, and it's impossible of users to delete or corrupt the metadata. The Multisite extension, while expensive, allows a lot of powerful options when dealing with a distributed source base. The nicest feature of all is the build avoidance capability.
However there are many aspects about it which are thoroughly unsatisfying. It's the little details that cause all the time to be wasted. One particularly irritating thing that bugs me is that if you edit your configuration spec and make a typo in a label or branch, Clearcase doesn't tell you, and you'll be working away merrily, blissfully unaware that the baseline you're working with is not the one you intended. Another irritating aspect is that some of the commands are long and have all kinds of detailed options. What you end up doing is writing a whole bunch of wrapper scripts, and the upshot of that of course is that no two Clearcase sites are the same so your experience does not transfer so easily from one place to another. For example in base Clearcase the command to find out what changes are in another branch the command is
ct findmerge -avobs -fversion
in Bitkeeper it's
bk changes -R
in Clearcase to list all the labels in a VOB
ct lstype -kind lbtype
in BK or CVS or similar it's
bk tags
etc.
Nobody can be penalized for using software licensed under the existing GPL version 2 license, and the article is quite misleading to suggest that that may be the case. Licenses cannot be applied retrospectively.
However new works distributed under the GPL 3.0 license would be subject to this restriction. That isn't likely to cause considerable pain to either Google or Amazon.
Unfortunately the license has rather more serious implications particularly for things like embedded devices. Say you are an ISP and you use a particular router, which includes some GPL code, to support 250 customers. Since those customers are benefitting from a GPL-inclusive service, are all of those customers entitled to download the sourcecode ? In many respects this new license could be unattractive for many commercial vendors who may chose not to deal with works licensed under it.
I immediately read "Mandrivel", not a good idea to have a distro which is drivel.
About as happy as they have been with GCC bugs. They have seen more than their share of those, and they will deal with them in the same way.
I don't think it's the same issue, Bruce. If GCC is broken you use the previous version. Easy.
If your revision control database gets corrupted due to a bug, you need to wait for someone to fix it. Integration work is suspended while it gets sorted out. Testers can't grab the latest kernel because the database is offline, their work stops too. Unless there is someone employed as a full time SCM administrator how will development proceed unimpeded ?
Couldn't I apply all of your arguments to Open Source in general? Shouldn't they be using Microsoft C and Visual SourceSafe for the wonderful support they'd get?
For these things to work properly you need support. I use "support" in it's loosest term, ie "someone nearby who knows about the program and is able to help". You need people who know how it works to fix it for you when it breaks. VSS isn't very good, in fact M$ don't even use it for their own work internally, bit of a sham really. I wouldn't tell anyone to use a product the vendor itself didn't even trust. Even CVS is better than VSS.
Regarding MS C, the thing is that GCC, unlike the various OSS SCM systems, meets the "good enough" definition. That brings me to the next big question which I have, which is - would GCC or the rest of the GNU toolset ever have reached the point they have if proprietary operating systems such as Solaris or HP-UX did not exist for Stallman and his successors to develop on ? It seemed more than acceptable to the GNU people to work along with proprietary systems when no usable alternative was available (it's a pity that does not apply in the case we are discussing). How fortunate we are that Bell/AT&T were not a little more careful when it came to looking after their source code.
Linux has developed quickly (compared with ideologically pure examples such as the Hurd) because it bends the rules a little bit and borrowed the rich pickings from the commercial world. Strictly speaking binary modules are a breach of the GPL, but Linus and the developers bent the rules. If they didn't, a significant number of machines today would not run Linux or would not support advanced graphics or wireless devices under Linux. An even stricter application of the GPL might suggest that BIOSs and bootloaders used to bootstrap machines, not only your x86s but your SPARC boxen and IBM big-iron, come under it's licensing remit.
What you have to accept is that successful open source projects are where they are today because a proprietary platform existed to bootstrap them into feasibility. Commercial organizations are playing along because they expect to get out what they put in. It doesn't matter who it is - IBM, Red Hat, Intel with their drivers, Bitmover or anyone else. In each of those cases you can bet your bottom dollar that if any of those companies start to believe that open source involvement is undermining their intellectual property base, they'll pull out and start invoking their patents.
Whatever they were thinking of, it didn't work. That's business - sometimes you lose. It seems that others have better ideas than Subversion.
That's the other problem, there's about a zillion of them, and all of them are so-so. Especially when it comes to SCM, for some unfathomable reason, people seem to prefer to go and reinvent the wheel to build their own system, rather than step in to help improve someone else's. After the BK flamewars on LKML go away, the next series of fun and exciting instalments to look forward to will be long drawn out criticism over the system that Linus eventually chooses as a replacement.
They fix it. That's our way.
Will kernel developers be happy to wait around while the bugs gets sorted out ? Will they tolerate having the integration tree rolled back to an earlier state to remove corrupt data ? That's the question. They are used to a pace of development, a degree of change, and a degree of participation which outstrips that seen on other major open source projects such as GCC or *BSD for example. They've spent three years under a regime where they don't have to wait around. How will they react to SCM problems cropping up ?
They will support it as well as they can without leaving their day jobs.
Time will tell if that is good enough. I'm concerned that it will not be. Linus obviously did not think so given that he has consistently rejected the alternatives to BK to date. As we all know the kernel people are a prickly bunch and some of them aren't so well known for their tolerance when it comes to matters like this. I hope the developers of $(new_kernel_SCM) will take the abuse for as long as Larry did.
This was already going on, anyway - there are several folks funding various sorts of Open Source version control.
And how long are they going to keep doing that ? I can't imagine how much money Tigris have put into Subversion at this stage, and look at the criticism the product continues to incur and the major back-end overhauls that have been taking place. What are they going to do when the day comes when shareholders or investors start looking for RoI ? It's a cold hard reality.
Seems to be that a lot of the open source movement - with it's gargantuan achievements over recent years - still relies on private support and private funding in one way or another. In some respects I might go so far as to say that the ostensible "freedom" is underpinned in many cases by the marketing and R&D departments of several large corporations. I would love to believe that eventually the community will come to have momentum all by itself, but I'm concerned that it might not and I hope people don't take their eye off the ball on that matter.
BTW it's a great privilege to speak with you.
I've never seen handing your data over to be managed by proprietary software product as "practical".
..) to make it competitive. If Red Hat were nothing other than a few experts on the end of the phone they'd have been gone long ago.
Obviously you don't work in the real world, where tens of thousands of companies pay money for proprietary software that their entire business is based on in exchange for products that work and reliable support. They continue to do so because in a pragmatic world, the ideological objective of software freedom doesn't stand up to the practical reality of running a business.
Sure you can make a business out of open source, but you have to put up a fight, in the way that Red Hat are doing. And even with Red Hat, they have to add proprietary components to the mix (cluster manager, GFS
Have you ever tried to use arch ? The command set and user interface is plain cryptic. The weird idiosynchracies such as the {arch} subdirectory for metadata and the weird commands make it very hard to remember.
Arch and Darcs are the right way to proceed, but make crucial mistakes in their implementation. Maybe monotone will not repeat those mistakes.
Excellent post.
The trouble is though, the kernel community who were behind causing the end of this win-win productive relationship are people who are more interested in creating a revolution of their own rather than producing great free software. Despite the project leader repeatedly laying down the rules in clear terms they sought to undermine them. In the end you got a power-struggle and as a result the zealots got what they wanted.
Well now the folks out there who said "arch is good" will now have to put their money where their mouth is and show how those alternative tools can take the place of BK for kernel maintenance. I hope that when the flamewars on the mailing list over dropped patches or corruption commence they too will be able to take what they gave on the "I told you so" front.
Bruce, I greatly respect your opinions and your contribution on most subjects but I don't agree on this one.
There are serious consequences to making the wrong choice when it comes to revision control. You've got a choice between the tried and tested such as CVS, which took years to get right, and which work but are frankly crap and get in the way - let's face it. On the other hand you can try out the new and experimental systems which dramatically improve productivity but are not tried and tested. BK bridged that gulf and provided the best of both worlds, but certain loud whiners denounced it as being against their religion and worked to undermine it ever since.
You talk about those 1000 developers - what do they do when the revision control system hits a bug or the database gets corrupted, and no-one is available to fix it ? I'd love to believe that there would be an army of dedicated people waiting in the wings, ready to step in and immediately fix the bug or the corruption in the same way that Bitkeeper did. Who is going to pay for people to do that ? Are the monotone developers going to walk out of their day-jobs and support the kernel SCM for nothing ?
Of course what might happen is one of the big corporations such as RH or IBM will generously fund an engineer to work on one of these SCM systems (notwithstanding IBM's Clearcase commitment) in which case you're back right where you were - dependency on the whims of a corporation.
I think the kernel community will live to regret making life unnecessarily hard for the BK people and will come to miss the scalability that it provided. True, in 18 months or so monotone or whatever Linus chooses may well get to the point where it is usable - no doubt after a few nasty crashes and dropped patches.
But it's true, linus didn't consider the nature of what he was using and got burned.
Burned ? This statement is utterly ignorant of the dynamics within the kernel development process whenever BK was adopted. Linus, outstanding engineer that he is, was overloaded and was at the brink of hitting the bricks - the volume of work coming into the kernel was too much. The adoption of BK not only rescued the kernel development process from the brink of the abyss but increased by an order of magnitude the degree of change getting integrated.
Linus and Greg KH have both put out statements to the effect that they have greatly valued BK's use in the kernel and that they will learn lessons from it. If they got burned don't you think they'd have said so ?
Fusion reactors don't work yet, they are still experimental. The record energy output so far at JET is something like 70% of the input energy. ITER is expected to exceed the break-even point but that will be at least another ten years away.
Sorry but it's completely ignorant to talk about people failing to follow procedure regarding the Chernobyl accident. To use terms like "stupidity" to describe the people involved is an insult, unless you are referring to the Soviet powers that were in which case it applies entirely.
Like everything else about the way things were done in the Soviet Union, the procedures weren't well defined and half of the plant's design was shrouded in secrecy. The workers in the plant were not told about the positive void coefficient characteristic which led directly to the accident, it was regarded as a military secret. They were improperly trained in the plant operation in general.
The international authority which investigated Chernobyl, AFAIK, revised the cause of the accident such that it was blamed on the design of the plant and the positive void coefficient, rather than the personnel operating it.
SOB is the well known record, but Carlos improved considerably on the techniques used. The Well Tempered Synthesizer is a much better album in many respects, and by the time of the Switched-On Brandenburgs she'd taken the Moog synth as far as it could go in that area.
Well worth checking out are the Sonic Seasonings album (very early ambient soundscapes) and the soundtrack to Tron which features loads of Moog bass goodness together with live orchestra and early digitial synthesis.
I find it hard to see that Microsoft's license would be any more liberal than the one that Sun have used to open up Solaris 10.
"Sure you can look at it, but you can't use it without relicensing your code under our license. And if we find our code in any of your work we'll sue you. "
Thanks for that. I confess to not knowing much about the low-level implementations of these algorithms in the major OSs but I suspect what you say is true, the OS probably does page out unfrequently used stuff when it sees that memory is running low.
I agree with you, I can't see how anyone would claim that forcing the page swapper to pass through the filesystem layer, rather than writing the pages directly at the device level, is somehow better.
The Windows method of going through the filesystem is going to be pretty inefficient, especially given that we're talking about NTFS here.
I am not sure about the article's validity when it claims that swapfiles are distinct from paging files. There are other claims, such as the implication that Microsoft invented the term "virtual memory", that are also rather misleading.
It's not a matter of swapping "pre-emptively". The whole business is invisible to the user space and the locking is essentially done by the kernel. The CPU hardware (ie the MMU) basically watches every single memory access when the CPU is in the appropriate mode (ie protected mode on an x86). It has a list of mappings of address spaces in it's own small internal page table.
What happens is that every time you access a region of virtual memory (for example anywhere in user space), the MMU looks up the address in it's own list of pages. If the associated region is not mapped by the MMU, a page fault occurs which is essentially an interrupt which gets trapped by the operating system. The operating system checks to see if it has a mapping for that address.
If it does, it checks to see if that mapping is either resident, or a block which has been paged out to disk (ie to the paging file). If it has been page out to disk, another block of memory gets paged out and the requested region is paged back in.
The MMU's cache of pages gets cleared on most CPUs whenever there is a process context switch (but not a thread context switch), this is one of the big reasons why threads are less expensive than processes because the MMU's cache of pages has to be repopulated.
The algorithm used to select which region of memory gets paged out is where the real trickery is. Obviously if you are low on memory and switch repeatedly between two busy proesses, you will be constantly thrashing those pages on and off the disk.
Your driver doesn't necessarily have to go into the kernel tree to be a useful open source driver release.
There are good arguments in favour of keeping your file sizes down, eg to something like 10K, and splitting your functions over several files. The big one being turnaround time; if you have a multiprocessor machine your parallel builds can compile all the parts in parallel. Also if you make a change to a function in one of the files the compiler only needs to recompile that file and not your entire driver.
Obviously though there are reasonable constraints to this.
perforce does
Yes I know, there are a few of the lower-end SCM systems that show you the price. However the higher end ones don't. That list includes BitKeeper, Clearcase, MKS Integrity, AccuRev, CM Synergy, etc. This is true of a lot of large-scale corporate application suites.
So do IBM (with Clearcase). In fact any fairly serious SCM system that's available out there doesn't quote a price on the front page.