But let's not apply it too narrowly. The top 2%-5% in a *lot* of fields are substantially better than the next 10%. I see a lot of people here complaining about H1B abuses, and I agree that's real, but I think that attracting the top 5% would broaden opportunities for everyone. The catch is to do it in a way that aligns the incentives with the objectives, and I think there's a simple way to accomplish that:
Any company that pays an H1B employee at or above the 95th salary percentile for *domestic* labor can have an H1B that doesn't count against the annual visa quota. At least five American workers in the same band at the same company have to certify under penalty of perjury that the band level for the job is appropriately selected. That way the incentives match the objectives.
Folks: losing your job to an underpaid foreigner who is basically getting treated as slave labor is bad for both of you. Bringing in people who will open up opportunities to create new products or manage new groups is one way to stimulate demand. If they have to be *paid* at the 95th percentile, they won't get brought in willy-nilly.
Oh. Requiring those certifications would also put a fast end to the "captive Indian contracting company" practice, and would save a lot of visiting workers from slave trade types of abuses.
Probably so. The problem is that each safe language implements its own garbage collection method. Most implement conservative collection so that they can call the C library. Conservative collection is very easy to break with randomization, which is what happened to GCL when Fedora enabled randomization.
Randomization breaks a large number of de facto contracts about memory layout that certain applications have historically relied on, and each of those applications now needs to be fixed. Safe bet that the Objective C garbage collector was one of the things they either needed to fix or had already fixed.
Breaking things may be worth it if you get some value in exchange for the pain, but randomization of the address space doesn't provide any value.
I don't remember whether the result appeared in the USENIX security conference or the IEEE Security and Privacy conference, and I don't have time right now to go look. The summary is that it is not at all difficult for a remote attacker to determine where a randomized memory range has actually gone. My recollection from memory is that it increased the actual attack cost by a (very) small constant; not enough to serve as a useful defense or to buy the defender any useful amount of time.
Given which, the downsides are worth considering. The biggest casualty of this technique is garbage collection. That's kind of an unfortunate thing to lose, given that safe programming languages *are* a sustainable defense against this class of attack. We use a couple of applications (provers) that run on top of Common LISP, and we had to spend a fair bit of time getting GCL working again after this "improvement" was introduced in Fedora.
Some of the things that Apple is doing in this pass are good and useful things. ASLR isn't one of them. It is pretty amazing to see a company adding something like this four years after the research literature has that ASLR is trivial for an attacker to beat. The question is: why add something that is so disruptive to legitimate code when it doesn't do any good?
An interesting twist here is that if your assets are seized, you cannot pay counsel to defend you. If counsel donates their time, they are aiding you, which renders them subject to seizure...
While I don't entirely agree, there is a real and valid point to consider here, but let's look at it more closely:
Writing a program in BitC doesn't mean you have to verify it, only that perhaps you can. BitC has merit over existing systems programming languages purely on grounds of expressiveness and safety.
Ada83 was both excessively restrictive and provided insufficiently expressive abstraction capability to be useful. It was a 1960's language (okay, perhaps 1970's) language standardized when better languages were coming into play.
That being said, it also needs to be said that there is a small body of programs whose correctness is critical: operating systems, power substation control systems, flight control systems, medical systems, and so forth. It simply isn't a goal (for us) to take over the entire systems programming world with this language. It's our goal to be able to do a smaller set of critical things well enough that I'ld be willing to run the resulting code on my (personal) pacemaker when the time comes to need one.
And contrary to what one reply said, BitC is memory safe.
It is true that in general program verification is undecidable. This means that there exist some programs whose correctness cannot be decided. In practice, there is an even bigger class of programs whose correctness we don't know how to even define. But there is a large class of programs that are both definable and verifiable, and operating systems and compilers (correctly implemented) both appear to be in the class. There is a long list of work demonstrating verification success on similar things. I should put up a page referencing it.
Yes, we probably should have answered this. Bear in mind that the Coyotos project is very new, and the website is only a week or two old.
All of the work done in SRL is done under open source licenses. It is our strongly held philosphy that real security cannot be accomplished without the light of regular public exposure. If you want it done wrong, check with Redmond.
We haven't selected a license yet, but it will almost certainly be GPL/LGPL as EROS was.
It may surprise you to learn that the BitC group agrees. I have a fair bit of lisp/scheme experience, but nobody else likes it.
The current, lisp-like syntax is only an interim choice of surface syntax. It's one compelling advantage is that it is trivial to parse, which lets us get on with focusing on making a productive compiler. It also lends itself well to representing the program text as data that can be manipulated within the language, which is going to be extremely useful in the verifier.
Still, when the time is right (not yet -- BitC is still stabilizing) we should perhaps hold a syntax contest.
Early on, the VNC team made a dissatrous decision to be ``policy neutral'' about security. This terrible decision remains predominant today in all implementations of VNC.
The concrete result is that users (a) have to add extra options to get secure connections, they have a VNC variant that supports them at all, and (b) are able to start a non-secured vnc server, effectively poking an authentication security hole through the entire machine. On student machines, this is even an issue when -localhost is used, so firewalling is insufficient.
In my lab, we simply refuse to run vnc-server on any of our machines, because the security implications are unacceptable. It's a shame, because it's a great tool.
What really worries me is that the many proliferations of VNC have all propagated this error to new implementations. Apparently we did not learn this lesson with telnet.
Because the VNC team did not define any standard, common security protocols for VNC, the people who distribute vncserver are now stuck with a problem. They can either secure the server, breaking compatibility with the majority of VNC clients, or they can perpetuate the insecurity, making VNC an unacceptably risky install for administrators.
If the wrong thing is possible, many users will do it. If the wrong thing is default, then to first order all users will do it. The position of the VNC team on this issue was extremely irresponsible.
And yes, I know about VNC over ssh. In my experience, PhD students can't work out how to set up the tunneling on windows, never mind my mom. The objective is to solve the problem for people like my mom. VNC needs to behave reasonably in the hands of a non-expert.
Both the KeyKOS factory (US patent 4,584,639) and the EROS Constructor appear to do what MS has apparently patented. The KeyKOS patent was issues in 1986, and expired this year. The design pattern that MS has patented is so fundamental to how EROS works that we don't even emphasize it anymore -- it's old news!
The memory management cost for GC is basically the same as for malloc/free. It's just amortized in a different place.
It turns out, however, that there are natural places to do GC, and a little help from the application can go a very long ways. In the OpenCM collector, we mark procedures that return pointers using a special GC_RETURN macro. This works because at the return from a procedure all of its local variables are known to be unreachable. The only surviving objects are the ones that are reachable from the returned pointer (idea for this is due to Keith Packard).
By using this discipline, we actually blur the distinction between managed and unmanaged collection. The results look very good from a performance perspective.
However, I should acknowledge that this is partly due to the structure of our application. Servers are "in and out". They generate a lot of garbage during a given query and then release essentially all of it. Procedure return is therefore a natural collection point. The same experience might not apply in systems that hold large amounts of memory in the heap during long-running computations, with lots of temporary allocation.
We made a decision early to use GC and exceptions in OpenCM, even though the application is written in C. Conceptually, it was a big success, but there were a number of hurdles along the way. Here are some things we learned:
The Boehm-Weiser (BW) collector is not as portable as we had hoped. There are a number of platforms we wanted to run on where it just doesn't run at all. Relatively small changes to the target runtime can create a need to port it all over again. OpenBSD, in particular, was an ongoing hassle until we abandoned BW. Hans, I hasten to add, was quite encouraging, but he simply doesn't have time to adequately support the collector.
The BW collector doesn't work in our application. OpenCM has a few very large objects. For reasons we don't really understand, this tends to cause a great deal of garbage retention when running the BW collector. Enough so that the OpenCM server crashed a lot when using it. Please note that this was NOT a bug involving falsely retained pointers, as later experience showed.
Conservative collectors are actually too conservative. If you are willing to make very modest changes in your source code as you design the app, there prove to be very natural places in the code for collection, and the resulting collector is quite efficient.
Independent of the collector, we also hacked together an exceptions package. This was also the right thing to do, but it's easy to trip over it in certain ways. The point of mentioning this is that once you do exceptions the pointer tracking becomes damned near hopeless and you essentially have to go to GC.
I think the way to say this is: exceptions + GC reduces your error handling code by a lot. Instead of three lines of error check on every procedure call, the error checking is confined to logical recovery points in the program, and you don't have to mess around simulating multiple return values in order to return a result code in parallel with the actually intended return value.
To provide malloc pluggability, we implemented an explicit free operation. This lets us interoperate compatibly with other libraries and do leak detection. Turns out to be very handy in lots of ways.
Hybrid storage management works very well. For example, our diff routine explicitly frees some of its local storage (example) [Sorry -- this link will go stale within the next few weeks because the OpenCM web interface will change in a way that makes it obsolete. If the link doesn't work for you, try looking for the same file in.../DEV/opencm/...] This is actually quite wonderful, as it lets us build certain libraries to be GC compatible without being GC dependent. One of the challenges in using a GC'd runtime in a library is compatibility with an enclosing application that doesn't use GC. We haven't tried it yet, but it looks like our gcmalloc code will handle this.
Eventually, we gave up on the BW collector and wrote our own. Our collector is conceptually very similar to the collector that Keith Packard built for Nickle, though we've since built from there. A variant of the Nickle collector is also used as a debugging leak tracer for X11.
The OpenCM GC system is reasonably well standalone. We need to document it, but others might want to look at it when we cut our next release.
On the whole, I'ld say that GC for this app was definitely the right thing to do. Once you get into object caches it becomes very hard to locate all of the objects and decide when to free them. We were able to use a conservative approach with no real hassle, and heap size is fairly well bounded by the assisted GC approach we took.
On the other hand, I would not recommend a pure conservative collector for a pro
Ah. Then I misunderstood your earlier post, and I apologize.
Given the official statement from DARPA, it's entirely possible that this termination had nothing at all to do with Theo's comments or Smith's warnings. Given the timing, it seems unlikely that we will ever know for sure one way of the other. Most unfortunate.
Yes, Smith was my thesis advisor and remains a colleague. Perhaps I should have identified this.
If you re-read my post, you will not find the word "bias" anywhere. You will find an assemblage of facts and observations about facts. These facts and observations should be judged on merit, not on association. Theo's statements should be judged likewise. In my opinion, they don't hold up well when evaluated against the facts.
If I stood up and said "Smith is a nice guy, and you should take my word for it." I am offering an opinion that you, as a reader, are unable to judge independently. In that circumstance, it's appropriate to disclose relationships. In this case, everything I said is independently verifiable fact. The fact that Smith is my advisor does not alter the terms of government contracts. It does not alter the definition of the role of a PI. It does not alter the fact that Theo knew the terms of his contract. It does not alter the fact that as a contractor, issues of academic freedom don't apply to Theo. It does not alter the fact that Theo is engaged in slander.
Perhaps your energy would be better spent examining the merits of the issue rather than examining the people who are speaking.
Theo isn't an academic, so it's not clear that he has any academic freedoms to guard.
That said, there is always a tension when you advise employees. If they behave stupidly, you have an obligation as a manager to advise them that they are putting themselves at risk. Would it be somehow more appropriate if Smith, hypothetically, recognized that Theo was placing himself at risk and failed to alert him?
While I'm personally sympathetic to Theo de Raadt, his accusations against Jonathan Smith are a vicious slander and a lie. The reporters simply haven't done their homework -- they haven't even bothered to look at the contracting terms. Let's try looking at the facts.
We know from a notesent by Theo that DARPA made a decision to cancel this project. Theo himself confirms that the source of the funding cut was DARPA, not Smith. So that you can understand the issues, let me explain briefly how these contracts work.
The cancelled contract was originally "let" by DARPA. Jonathan Smith is the "principal investigator" (PI) for this project. A principal investigator basically has two responsibilities: (1) manage the activities required by the contract (i.e. get the job done), and (2) provide periodic reporting to the funding agency (in this case DARPA).
One of the rules with any U.S. government contract is that the government can stop work and cancel any remaining funding at any time. This is clearly stated in the applicable FARS and DFARS contracting regulations, which are a part of every contract signed with the U.S. Government, including the Department of Defense. The POSSE contract is just like any other contract: DARPA has the right to stop work on it at any time. DARPA is not required to give a reason for stopping work. Usually such actions are the results of budget changes, but cancellations can and do occur for other reasons. Theo and his team were subcontractors on this project. They knew that these were the terms when they were hired to do the job. They have reason to be unhappy, but no basis for wild accusations.
A principal investigator has no control over cancellation of funding. Theo knew the risk that his contract could be cancelled. He chose to speak out about something important to him, and he is now dealing with the consequences.
Theo is clearly he is frustrated, but there are two important points to remember:
Neither Jonathan Smith nor the University of Pennsylvania have broken their contract with Theo, and
Jonathan Smith has absolutely no control over DARPA's decision to terminate the POSSE project.
This is not a free speech issue. It is a consequences of free speech issue. Theo spoke negatively about his employer (DARPA). DARPA cut him off. Jonathan Smith is not curtailing Theo's free speech -- in fact, Smith and Penn had no decision making power in this situation at all! DARPA is not curtailing Theo's free speech -- Theo isn't in jail or under any threat of legal consequences for his words.
Free speech doesn't mean what Theo and some irresponsible reporters might like it to mean. Free speech does not mean "speech without consequences". Free speech means you can say what you wish without being prosecuted as long as you don't actively harm someone else (e.g. by libel and slander, for example the statements that Theo has made about Smith that Theo clearly knows are false). You have the right to speak, but the people who associate with you, either personally or professionally, have the right to respond to your speech. I do not know why DARPA cancelled this contract. DARPA is not required to give a reason. I do know that their actions are completely acceptable within the terms of the contract.
It is a little puzzling to me that Theo seems to feel that it is okay to slander someone who has generously assisted the OpenBSD team in getting a large amount of funding (remember: the contract was almost complete).
It is even more puzzling to me that various newspaper editors feel that such one-sided and selective reporting of the facts constitutes responsible journalism.
But the most puzzling thing to me is why so many people appear to be lining up on the side of the slanderer, and forgetting that Jonathan Smith's role in this who
You are arguing about lexicon. As I said earlier, the software industry made it's selection here 15 years ago, and it isn't going to change. I understand why you think a new term isn't called for. In fact, I probably agree. That said, arguing about it is kind of like trying to reopen because you don't think the armistice lines were drawn in the right places.
CVS uses various tricks to straddle the boundary between revision control and configuration management. Features like "tags" are an approximation to configurations. There are things we need that CVS doesn't (and can't) do, like rename, but CVS is presently the best available tool (or it was two weeks ago:-)
We describe OpenCM as a replacement to CVS because the command interfaces are intentionally similar and because most of the target users of OpenCM are currently using CVS.
CM isn't needed for programming in the large. It's only easiest to see there. CM starts to be needed the minute your program is spread across more than one file and you might need to recover older versions. The missing piece in RCS is that it does not know how versions relate between one file and the next.
If you are managing sets of versions of files, instead of versions of a single file, then you are doing configuration management. I understand why you don't want to give a separate name to configuration management, but the naming debate ended in the SCM industry almost 15 years ago. Arguing about it now is pointless.
SCM isn't about what files go where. That's system CM. SCM is about which versions of which files go together to build a particular application version.
Actually, software CM is in some sense the dual of system configuration management. SCM is about getting consistent configurations in to a repository. System CM is about blowing those configurations out to a bunch of machines. The first step, of course, is to know what constitutes a consistent set of configurations.
System CM is a lot more than preferences. Think about what happens when you get dynamic library versions wrong.
OpenCM actually could be used for system CM when the bundle model goes in, but it's different enough from the way existing system CM is done that I don't expect it will catch on for that purpose.
Slashdot Mirror
But let's not apply it too narrowly. The top 2%-5% in a *lot* of fields are substantially better than the next 10%. I see a lot of people here complaining about H1B abuses, and I agree that's real, but I think that attracting the top 5% would broaden opportunities for everyone. The catch is to do it in a way that aligns the incentives with the objectives, and I think there's a simple way to accomplish that:
Any company that pays an H1B employee at or above the 95th salary percentile for *domestic* labor can have an H1B that doesn't count against the annual visa quota. At least five American workers in the same band at the same company have to certify under penalty of perjury that the band level for the job is appropriately selected. That way the incentives match the objectives.
Folks: losing your job to an underpaid foreigner who is basically getting treated as slave labor is bad for both of you. Bringing in people who will open up opportunities to create new products or manage new groups is one way to stimulate demand. If they have to be *paid* at the 95th percentile, they won't get brought in willy-nilly.
Oh. Requiring those certifications would also put a fast end to the "captive Indian contracting company" practice, and would save a lot of visiting workers from slave trade types of abuses.
Of course it's a cluster. It runs on his microwave, his refrigerator, and his lawn sprinkler controller.
An increasing number of projects are using mercurial these days. Seems like a not-small oversight.
Probably so. The problem is that each safe language implements its own garbage collection method. Most implement conservative collection so that they can call the C library. Conservative collection is very easy to break with randomization, which is what happened to GCL when Fedora enabled randomization.
Randomization breaks a large number of de facto contracts about memory layout that certain applications have historically relied on, and each of those applications now needs to be fixed. Safe bet that the Objective C garbage collector was one of the things they either needed to fix or had already fixed.
Breaking things may be worth it if you get some value in exchange for the pain, but randomization of the address space doesn't provide any value.
I don't remember whether the result appeared in the USENIX security conference or the IEEE Security and Privacy conference, and I don't have time right now to go look. The summary is that it is not at all difficult for a remote attacker to determine where a randomized memory range has actually gone. My recollection from memory is that it increased the actual attack cost by a (very) small constant; not enough to serve as a useful defense or to buy the defender any useful amount of time.
Given which, the downsides are worth considering. The biggest casualty of this technique is garbage collection. That's kind of an unfortunate thing to lose, given that safe programming languages *are* a sustainable defense against this class of attack. We use a couple of applications (provers) that run on top of Common LISP, and we had to spend a fair bit of time getting GCL working again after this "improvement" was introduced in Fedora.
Some of the things that Apple is doing in this pass are good and useful things. ASLR isn't one of them. It is pretty amazing to see a company adding something like this four years after the research literature has that ASLR is trivial for an attacker to beat. The question is: why add something that is so disruptive to legitimate code when it doesn't do any good?
An interesting twist here is that if your assets are seized, you cannot pay counsel to defend you. If counsel donates their time, they are aiding you, which renders them subject to seizure...
That being said, it also needs to be said that there is a small body of programs whose correctness is critical: operating systems, power substation control systems, flight control systems, medical systems, and so forth. It simply isn't a goal (for us) to take over the entire systems programming world with this language. It's our goal to be able to do a smaller set of critical things well enough that I'ld be willing to run the resulting code on my (personal) pacemaker when the time comes to need one.
shap
In fact, Jonathan was at Bell Labs when the first validated implementation of Ada83 was completed by a guy down the hall: Charlie Weatherall.
And contrary to what one reply said, BitC is memory safe.
It is true that in general program verification is undecidable. This means that there exist some programs whose correctness cannot be decided. In practice, there is an even bigger class of programs whose correctness we don't know how to even define. But there is a large class of programs that are both definable and verifiable, and operating systems and compilers (correctly implemented) both appear to be in the class. There is a long list of work demonstrating verification success on similar things. I should put up a page referencing it.
shap
All of the work done in SRL is done under open source licenses. It is our strongly held philosphy that real security cannot be accomplished without the light of regular public exposure. If you want it done wrong, check with Redmond.
We haven't selected a license yet, but it will almost certainly be GPL/LGPL as EROS was.
shap
The current, lisp-like syntax is only an interim choice of surface syntax. It's one compelling advantage is that it is trivial to parse, which lets us get on with focusing on making a productive compiler. It also lends itself well to representing the program text as data that can be manipulated within the language, which is going to be extremely useful in the verifier.
Still, when the time is right (not yet -- BitC is still stabilizing) we should perhaps hold a syntax contest.
shap
Early on, the VNC team made a dissatrous decision to be ``policy neutral'' about security. This terrible decision remains predominant today in all implementations of VNC. The concrete result is that users (a) have to add extra options to get secure connections, they have a VNC variant that supports them at all, and (b) are able to start a non-secured vnc server, effectively poking an authentication security hole through the entire machine. On student machines, this is even an issue when -localhost is used, so firewalling is insufficient. In my lab, we simply refuse to run vnc-server on any of our machines, because the security implications are unacceptable. It's a shame, because it's a great tool. What really worries me is that the many proliferations of VNC have all propagated this error to new implementations. Apparently we did not learn this lesson with telnet.
Because the VNC team did not define any standard, common security protocols for VNC, the people who distribute vncserver are now stuck with a problem. They can either secure the server, breaking compatibility with the majority of VNC clients, or they can perpetuate the insecurity, making VNC an unacceptably risky install for administrators.
If the wrong thing is possible, many users will do it. If the wrong thing is default, then to first order all users will do it. The position of the VNC team on this issue was extremely irresponsible.
And yes, I know about VNC over ssh. In my experience, PhD students can't work out how to set up the tunneling on windows, never mind my mom. The objective is to solve the problem for people like my mom. VNC needs to behave reasonably in the hands of a non-expert.
Both the KeyKOS factory (US patent 4,584,639) and the EROS Constructor appear to do what MS has apparently patented. The KeyKOS patent was issues in 1986, and expired this year. The design pattern that MS has patented is so fundamental to how EROS works that we don't even emphasize it anymore -- it's old news!
It turns out, however, that there are natural places to do GC, and a little help from the application can go a very long ways. In the OpenCM collector, we mark procedures that return pointers using a special GC_RETURN macro. This works because at the return from a procedure all of its local variables are known to be unreachable. The only surviving objects are the ones that are reachable from the returned pointer (idea for this is due to Keith Packard).
By using this discipline, we actually blur the distinction between managed and unmanaged collection. The results look very good from a performance perspective.
However, I should acknowledge that this is partly due to the structure of our application. Servers are "in and out". They generate a lot of garbage during a given query and then release essentially all of it. Procedure return is therefore a natural collection point. The same experience might not apply in systems that hold large amounts of memory in the heap during long-running computations, with lots of temporary allocation.
The Boehm-Weiser (BW) collector is not as portable as we had hoped. There are a number of platforms we wanted to run on where it just doesn't run at all. Relatively small changes to the target runtime can create a need to port it all over again. OpenBSD, in particular, was an ongoing hassle until we abandoned BW. Hans, I hasten to add, was quite encouraging, but he simply doesn't have time to adequately support the collector.
The BW collector doesn't work in our application. OpenCM has a few very large objects. For reasons we don't really understand, this tends to cause a great deal of garbage retention when running the BW collector. Enough so that the OpenCM server crashed a lot when using it. Please note that this was NOT a bug involving falsely retained pointers, as later experience showed.
Conservative collectors are actually too conservative. If you are willing to make very modest changes in your source code as you design the app, there prove to be very natural places in the code for collection, and the resulting collector is quite efficient.
Independent of the collector, we also hacked together an exceptions package. This was also the right thing to do, but it's easy to trip over it in certain ways. The point of mentioning this is that once you do exceptions the pointer tracking becomes damned near hopeless and you essentially have to go to GC.
I think the way to say this is: exceptions + GC reduces your error handling code by a lot. Instead of three lines of error check on every procedure call, the error checking is confined to logical recovery points in the program, and you don't have to mess around simulating multiple return values in order to return a result code in parallel with the actually intended return value.
To provide malloc pluggability, we implemented an explicit free operation. This lets us interoperate compatibly with other libraries and do leak detection. Turns out to be very handy in lots of ways.
Hybrid storage management works very well. For example, our diff routine explicitly frees some of its local storage (example) [Sorry -- this link will go stale within the next few weeks because the OpenCM web interface will change in a way that makes it obsolete. If the link doesn't work for you, try looking for the same file in .../DEV/opencm/...] This is actually quite wonderful, as it lets us build certain libraries to be GC compatible without being GC dependent. One of the challenges in using a GC'd runtime in a library is compatibility with an enclosing application that doesn't use GC. We haven't tried it yet, but it looks like our gcmalloc code will handle this.
Eventually, we gave up on the BW collector and wrote our own. Our collector is conceptually very similar to the collector that Keith Packard built for Nickle, though we've since built from there. A variant of the Nickle collector is also used as a debugging leak tracer for X11.
The OpenCM GC system is reasonably well standalone. We need to document it, but others might want to look at it when we cut our next release.
On the whole, I'ld say that GC for this app was definitely the right thing to do. Once you get into object caches it becomes very hard to locate all of the objects and decide when to free them. We were able to use a conservative approach with no real hassle, and heap size is fairly well bounded by the assisted GC approach we took.
On the other hand, I would not recommend a pure conservative collector for a pro
Given the official statement from DARPA, it's entirely possible that this termination had nothing at all to do with Theo's comments or Smith's warnings. Given the timing, it seems unlikely that we will ever know for sure one way of the other. Most unfortunate.
If you re-read my post, you will not find the word "bias" anywhere. You will find an assemblage of facts and observations about facts. These facts and observations should be judged on merit, not on association. Theo's statements should be judged likewise. In my opinion, they don't hold up well when evaluated against the facts.
If I stood up and said "Smith is a nice guy, and you should take my word for it." I am offering an opinion that you, as a reader, are unable to judge independently. In that circumstance, it's appropriate to disclose relationships. In this case, everything I said is independently verifiable fact. The fact that Smith is my advisor does not alter the terms of government contracts. It does not alter the definition of the role of a PI. It does not alter the fact that Theo knew the terms of his contract. It does not alter the fact that as a contractor, issues of academic freedom don't apply to Theo. It does not alter the fact that Theo is engaged in slander.
Perhaps your energy would be better spent examining the merits of the issue rather than examining the people who are speaking.
That said, there is always a tension when you advise employees. If they behave stupidly, you have an obligation as a manager to advise them that they are putting themselves at risk. Would it be somehow more appropriate if Smith, hypothetically, recognized that Theo was placing himself at risk and failed to alert him?
While I'm personally sympathetic to Theo de Raadt, his accusations against Jonathan Smith are a vicious slander and a lie. The reporters simply haven't done their homework -- they haven't even bothered to look at the contracting terms. Let's try looking at the facts.
We know from a note sent by Theo that DARPA made a decision to cancel this project. Theo himself confirms that the source of the funding cut was DARPA, not Smith. So that you can understand the issues, let me explain briefly how these contracts work.
The cancelled contract was originally "let" by DARPA. Jonathan Smith is the "principal investigator" (PI) for this project. A principal investigator basically has two responsibilities: (1) manage the activities required by the contract (i.e. get the job done), and (2) provide periodic reporting to the funding agency (in this case DARPA).
One of the rules with any U.S. government contract is that the government can stop work and cancel any remaining funding at any time. This is clearly stated in the applicable FARS and DFARS contracting regulations, which are a part of every contract signed with the U.S. Government, including the Department of Defense. The POSSE contract is just like any other contract: DARPA has the right to stop work on it at any time. DARPA is not required to give a reason for stopping work. Usually such actions are the results of budget changes, but cancellations can and do occur for other reasons. Theo and his team were subcontractors on this project. They knew that these were the terms when they were hired to do the job. They have reason to be unhappy, but no basis for wild accusations.
A principal investigator has no control over cancellation of funding. Theo knew the risk that his contract could be cancelled. He chose to speak out about something important to him, and he is now dealing with the consequences.
Theo is clearly he is frustrated, but there are two important points to remember:
This is not a free speech issue. It is a consequences of free speech issue. Theo spoke negatively about his employer (DARPA). DARPA cut him off. Jonathan Smith is not curtailing Theo's free speech -- in fact, Smith and Penn had no decision making power in this situation at all! DARPA is not curtailing Theo's free speech -- Theo isn't in jail or under any threat of legal consequences for his words.
Free speech doesn't mean what Theo and some irresponsible reporters might like it to mean. Free speech does not mean "speech without consequences". Free speech means you can say what you wish without being prosecuted as long as you don't actively harm someone else (e.g. by libel and slander, for example the statements that Theo has made about Smith that Theo clearly knows are false). You have the right to speak, but the people who associate with you, either personally or professionally, have the right to respond to your speech. I do not know why DARPA cancelled this contract. DARPA is not required to give a reason. I do know that their actions are completely acceptable within the terms of the contract.
It is a little puzzling to me that Theo seems to feel that it is okay to slander someone who has generously assisted the OpenBSD team in getting a large amount of funding (remember: the contract was almost complete).
It is even more puzzling to me that various newspaper editors feel that such one-sided and selective reporting of the facts constitutes responsible journalism.
But the most puzzling thing to me is why so many people appear to be lining up on the side of the slanderer, and forgetting that Jonathan Smith's role in this who
Yes. Like SourceSafe or PVCS, only better. :-)
We have been having some crash problems with the OpenCM server, so if the connection is refused it's always worth trying back later.
You are arguing about lexicon. As I said earlier, the software industry made it's selection here 15 years ago, and it isn't going to change. I understand why you think a new term isn't called for. In fact, I probably agree. That said, arguing about it is kind of like trying to reopen because you don't think the armistice lines were drawn in the right places.
CVS uses various tricks to straddle the boundary between revision control and configuration management. Features like "tags" are an approximation to configurations. There are things we need that CVS doesn't (and can't) do, like rename, but CVS is presently the best available tool (or it was two weeks ago :-)
We describe OpenCM as a replacement to CVS because the command interfaces are intentionally similar and because most of the target users of OpenCM are currently using CVS.
CM isn't needed for programming in the large. It's only easiest to see there. CM starts to be needed the minute your program is spread across more than one file and you might need to recover older versions. The missing piece in RCS is that it does not know how versions relate between one file and the next.
If you are managing sets of versions of files, instead of versions of a single file, then you are doing configuration management. I understand why you don't want to give a separate name to configuration management, but the naming debate ended in the SCM industry almost 15 years ago. Arguing about it now is pointless.
SCM isn't about what files go where. That's system CM. SCM is about which versions of which files go together to build a particular application version.
System CM is a lot more than preferences. Think about what happens when you get dynamic library versions wrong.
OpenCM actually could be used for system CM when the bundle model goes in, but it's different enough from the way existing system CM is done that I don't expect it will catch on for that purpose.
Linuxconf is for configuring a system. OpenCM is for managing software source code configuration. Different problems, different tools.