You've hit on the point where Dijkstra's hypothesis fails. He wants Computer Scientists to formally think about programs and write code that can be formally proven to meet the equally formal specification. There are important problems (like cryptography, banking, secure kernels, and more) that can benefit from that approach, but many more programs in the real world are mostly solving user interface problems. Sure, they access databases and implement business logic, but the primary drive is what the user wants the system to do.
The vast majority of development money spent today is on user-centric programs where there is no single solution; where we do not have the language to create formal specifications, at least to the point of being able to prove compliance; and even if we had such a language, the users and customers who specify programs would not want to bother with it. The people who pay the bills typically do not want to spend the time and money to create that kind of specification for piddling details like keeping private data private -- not when there are real dollars that can be saved by __(fill in the blank)__.
The fact that it is an LLC offers only some protection -- courts regularly judge whether principals and investors in a corporation are liable for the corporation's torts. This is called, among other things, piercing the corporate veil, and is easier if the corporation was formed specifically in an attempt to provide that kind of isolation and if the corporation did not have life beyond that goal. (This hints that the corporation is a mere "alter ego" of the principals.)
I have no idea whether this "American Rights Counsel" (how Orwellian!) has enough of an independent history and existence to maintain its corporate entity in the face of a lawsuit or not.
Copyright infringement is obviously a conclusion of law, so someone cannot reasonably be asked to state under penalty of perjury that infringement occurred before a court has ruled that it has occurred.
However, the statement that is required under penalty of perjury does include that the complainant is authorized to act on behalf of the owner of an allegedly infringed reserved right. If there is no allegedly infringed reserved right (in the take-down notice), perjury. If there is no authorization by the owner (for the allegedly infringed work), perjury. I would guess that there are no reserved rights to the town meeting footage linked by the EFF, and that the whiner in this case is not authorized to act on behalf of some of the television stations or networks.
I suppose it is possible that the notices are of the form "We have a good-faith belief that XYZ video infringes our client's rights in work ABC", where they do have authorization to act on behalf of work ABC. I would hope that would become actionable if there is a pattern of complaints where it is hard to imagine any good-faith belief of infringement.
The perjury statement for the take-down notice requires a statement "that the complaining party is authorized to act on behalf of the owner of an exclusive right that is allegedly infringed". As I read it, that requires that the notice contain some other allegation that an exclusive right is infringed, and that the work and the exclusive right be identified accurately. If the notice does not accurately identify a work (and right) that the complainer is authorized to act on, the complainer might have answer for perjury.
He should have received a warning, but being kicked out of his house for three days and having probably thousands of dollars worth of materials taken -- in the absence of any clearly stated hazard, even when the government had that much time to find anything -- is somehow acceptable? I, for one, don't think so.
Your argument about speed limit laws is a straw man: Nowhere did I suggest that zoning or storage laws were groundless. What I said was that if the police did arrest him, that would allow them to perform certain kinds of search and seizure. They did not arrest him, so that reason for seizing his property is not available to them.
As to your lame defense of "vessel" versus "vat" as semantics: that was precisely my point. There is a definite semantic difference between the two words, and you -- whether intentionally or carelessly -- used the one that is scarier than what the closer sources chose.
Finally, for your edification, what I closed with was not argumentum ad hominem, which is an invalid logical device that I avoid using. It was a simple personal attack. I am not afraid to deal out sharp words where they have been earned.
Some sort of background? The first line of TFA says he's a retired chemist; later it says he continues to perform experiments. As for "moderately dangerous", the second paragraph of TFA says none were more dangerous than household cleaning products. It also characterized the containers as "vessels", rather than the "vats" you used. Vessels can be much smaller and might normally be closed. I suspect that if the authorities could have legitimately called them vats, they would have used that word rather than "vessels".
In other news, fire departments do not have the authority to confiscate rags covered in paint. Additionally, the fact that he was not arrested and will not be charged makes it more likely that the seizure was unconstitutional: search and seizure incident to arrest is one of the permitted forms of warrant-less search.
You totally fail at reading and at knowing civil rights in the USA.
How many small appliance fires require the police to maintain order?
But taking his stuff is the objectionable part, which is why I added the bit about the television. This was not a plain search (short of arrest, incident to arrest or vehicular) -- it was outright seizure without a warrant, in rather clear violation of the Fourth Amendment. What background would you want that would excuse the police taking that material?
Let me rephrase my question, then. When you invite a friend over for a party, do they also have permission to take your television? If so, I'd like to make your acquaintance. I think I'd get a lot of new gadgets.
It is people like you who enable abusive police. As penance, read a hundred articles by Radley Balko and ask a qualified lawyer about search and seizure laws in the USA.
"[T]he home owner invited the cops in when he called the fire department"? Tell me, when you invite a friend over for a party, do you invite their roommate over to steal your television? If so, I'd like to make your acquaintance. I think I'd get a lot of other new friends.
The owner of a music CD may make a backup/archive copy of that CD for $0.00. That doesn't stop the RIAA (or FSF, as the case may be) from having a legitimate claim that unauthorized mass copying does equate to actual damages. You're focusing on one -- irrelevant -- aspect of the copying and ignoring the aspects relevant to the alleged tort.
My group at work recently bought one of these. They catch a lot of things that compilers don't -- for example, code like this:
int array[4], count, ii;
scanf("%d", &count); for (ii = 0; ii < count; ++ii) { scanf("%d", &array[ii]); }
.. where invalid input causes arbitrarily bad behavior. They also tend to be better at inter-procedural analysis than compilers, so they can warn you that you're passing a short literal string to a function that will memcpy() from the region after that string. They do have a lot of false positives, but what escapes from compilers to be caught by static analysis tools tend to be dynamic behavior problems that are easy to overlook in testing. (If the problem were so obvious, the coder would have avoided it in the first place, right?)
No, they were both garden variety race conditions. This is single-threaded application code that doesn't do anything particularly novel or clever. IRC servers deal with new connections more often than most applications except high-traffic web servers, so the racy paths (in the system calls implementing accept() and getpeername() respectively) run a lot more often on large IRC servers than most places. To quantify "a lot", the server where the first problem was most troublesome sees upwards of 230 incoming connections per second -- both over the last ~50 days and over one recent minute.
I don't think that the FreeBSD guy fudged his benchmarks -- more likely, other FreeBSD people fudged the OS. Working with large-scale IRC servers, I have seen a few serious kernel-level race conditions on FreeBSD cause problems (like server processes that stop accepting connections in an unkillable state -- rebooting the server is a good way to fix things, right? -- and clients that appear to have the IP address 0.0.0.0). What's worse is that the unkillable process bug took many months to resolve. Linux and Solaris servers on the same IRC network never seem to have OS-related problems. It goes back to the old saw: make your code correct, *then* make it fast.
Not quite -- you're talking about depositions. Discovery is the entire process where each side in a civil case drafts written questions (the interrogatories mentioned by queequeg1 above) and asks for other information (requests for production [of documents or other tangible evidence]) in addition to real-time interviews (depositions) to the other. Interrogatories and requests for production typically do not involve stenographers.
Normally, the acceptable scope of discovery is pretty broad, and a court will allow a lot of discovery of proprietary or confidential information if it is covered by a suitable protective order. In this kind of case, where the defendant has no trade interest in the proprietary or confidential information, and where it is clearly relevant to the evidence relating to trying the claims, getting it through discovery and allowing an expert witness to review it should be nearly a slam dunk.
Even without signing that piece of paper, most software would be considered works for hire anyway, meaning copyright would initially be owned by the employer. In the software world, the core requirement for this is that the employee's writing of the software is "within the scope of his or her employment" (17 USC 101). Courts have set forth guidelines on determining whether it is within the scope of employment, most of which are hit on by a post farther down: being done on company time, guidance from the employer (in terms of requirements, management, or others), using tools provided by the employer, and so forth. Having a signature on paper removes any doubt and should help the employee understand the issues of ownership.
Maybe I've been lucky, but I only had really objectionable terms in one contract when joining a company. That company was small enough that they listened -- and changed the contract -- when I said I worked on unrelated open source software in my free time and wanted to retain ownership, rather than having every thought in my head automatically owned by the company.
Proper merge tracking has been on the "we plan to introduce it" list for Subversion since well before 1.0, along with a few other things that most strongly-formal customers expect from version control systems (like useful history tracking/recovery in the face of file renames; issue #928). At least they claim merge tracking is actually on trunk now (issue #820) -- I'll believe it works decently when I see it.
If the security patrols teleport instantly from one checkpoint to the next, your complaint might be significant. Most patrols I have seen move smoothly (in a mathematical sense) between points, which means that they will be at intermediate points in space at intermediate points in time. It's not hard to set checkpoints so that viable attack paths must cross one or more patrol paths -- the randomized patrol path and timing can be easily constrained to do that.
(In more detail: Enumerate building corners, junctions, important infrastructure, and other places that you can see a wide area, potential weaknesses or hiding spots. Record the expected time to travel between any pair of those points that you want to use in the randomized patrols. Stitch together several random walks through the graph. Use your favorite optimizer to ensure the collection of patrols meets whatever constraints you have for coverage. For bonus points, analyze a number of outputs to identify bias or weakness, and remove those problems.)
Quite the opposite. The bit about strategies given "perfect knowledge" by the opponent assumes that any information about practices or techniques could leak out. Given that, it seems obvious that the proper response is to determine an appropriate level of coverage, and then implement a randomized search pattern that conforms to those constraints. The security is not through obscurity but through a smaller window for discovering and exploiting the search pattern.
I manage a software development team for a living. Before putting on the pointy-haired manager hat, I wrote software full time. I still write code when necessary. The applications and customers for my day work require close and careful revision control as part of larger configuration management efforts. I would not use Perforce (the software) even if Perforce (the company) paid me to use it. At work, we use Subversion primarily because it has reasonable Windows support.
You avoided my question and introduced the "fanboy" ad hominem. I can only conclude that means that you have never used Perforce. You are the one acting like a Perforce/Google fanboy: you have provided exactly zero mention of technical merits and offered no rebuttal of my points. You are the one who was advocating for Perforce: it is not *my* job to defend your foolish argument, especially when you are obviously unwilling and/or unable to do so.
I also write software as a hobby. I wouldn't use Perforce for that, either. I use git for my own projects, and other revision control systems when there is a legacy repository in place.
By that standard, you made no point in your original post -- "one company uses Perforce" is not a point.
Have you used Perforce? I have used it in an academic environment and a corporate environment. It sucked both places, for the reasons I listed and a few I've probably forgotten. GIT is vastly superior for people who are developing on Unix-like operating systems. GIT is faster, more elegant, and much more functional than Perforce. On Windows, Subversion -- in the form of TortoiseSVN -- is generally better than Perforce, but not by the margin that GIT has. Subversion doesn't have *quite* as many features as Perforce, but the TortoiseSVN UI is better and Subversion is generally easier to use (because of the clientspec-stored-on-server part of Perforce).
Perforce is a pretty lousy configuration management system. Wide cross-platform support is the only positive aspect it really has going for it. Other aspects just suck less than certain alternatives: price, ease of use, SCM model, etc. Google probably developed easier front-ends in-house, but things like client specifications are maddeningly unintuitive in Perforce, branching is baroque, and having the *server* keep track of client workspace state is a mind-blowingly stupid performance optimization.
(GIT has several GUIs -- nicer than what Subversion and CVS have on Unix systems, but not as nice as TortoiseSVN or good commercial offerings. GIT can version binary files. The core-git CLI is continuously getting usability improvements, and there are other porcelains that try to make it even easier.)
SVN keeps a.svn metadata folder in each normal directory; hence if you have 1000 normal directories you get 2000 directories.
Not only that, for each file, Subversion keeps a copy of the last version you checked out of (or in to) the repository, so if you have 10 MB of source code, you end up with 20 MB used on disk. GIT's pack file support lets you keep the entire history of a project in space that is usually comparable to the size of the source code.
In one of my projects that uses GIT, I have 7.5 MB of tracked source files, about 7.5 MB of compiled binaries and an 8.8 MB.git directory. That 8.8 MB fully describes every commit to every branch of the project for the last eight years. If I want to check out the first commit ever, I can do that. If I want to dig out a commit message from three years ago, no sweat. If I want to switch from one branch to another, it takes a second or two. Best of all, I can do all of those things entirely unplugged.
It's called "framing" -- as in framing the debate by choosing the terms.
This way anyone who might be sitting on the fence can clearly understand the consequences: If you think Microsoft is a stinky abusive monopolist but you are successful at offering large-scale 24x7 support to large customers, you're *community* Linux, not corporate, and your customers will leave you! Likewise, if you haven't upgrade to Shared Source Linux.NET, you will -- just as soon as Microsoft sends out the lawyers.
Civil trials in the United States -- at least any that people bother about -- must give the option for a trial by jury, per the Seventh Amendment. Either side may demand that a jury decide the facts in question.
They need a lot more than to claim a new use in order to have a valid patent. They also need it to be a useful and novel advancement in the field. I suspect the problem here will be novelty -- the various disc layering architectures are not novel to this patent, I suspect the alloy compositions (especially given in ranges as this patent apparently does) are not sufficiently novel, and combining shiny substances with a particular layering to produce an optical disc is *definitely* not novel.
Slashdot Mirror
You've hit on the point where Dijkstra's hypothesis fails. He wants Computer Scientists to formally think about programs and write code that can be formally proven to meet the equally formal specification. There are important problems (like cryptography, banking, secure kernels, and more) that can benefit from that approach, but many more programs in the real world are mostly solving user interface problems. Sure, they access databases and implement business logic, but the primary drive is what the user wants the system to do.
The vast majority of development money spent today is on user-centric programs where there is no single solution; where we do not have the language to create formal specifications, at least to the point of being able to prove compliance; and even if we had such a language, the users and customers who specify programs would not want to bother with it. The people who pay the bills typically do not want to spend the time and money to create that kind of specification for piddling details like keeping private data private -- not when there are real dollars that can be saved by __(fill in the blank)__.
The fact that it is an LLC offers only some protection -- courts regularly judge whether principals and investors in a corporation are liable for the corporation's torts. This is called, among other things, piercing the corporate veil, and is easier if the corporation was formed specifically in an attempt to provide that kind of isolation and if the corporation did not have life beyond that goal. (This hints that the corporation is a mere "alter ego" of the principals.)
I have no idea whether this "American Rights Counsel" (how Orwellian!) has enough of an independent history and existence to maintain its corporate entity in the face of a lawsuit or not.
Copyright infringement is obviously a conclusion of law, so someone cannot reasonably be asked to state under penalty of perjury that infringement occurred before a court has ruled that it has occurred.
However, the statement that is required under penalty of perjury does include that the complainant is authorized to act on behalf of the owner of an allegedly infringed reserved right. If there is no allegedly infringed reserved right (in the take-down notice), perjury. If there is no authorization by the owner (for the allegedly infringed work), perjury. I would guess that there are no reserved rights to the town meeting footage linked by the EFF, and that the whiner in this case is not authorized to act on behalf of some of the television stations or networks.
I suppose it is possible that the notices are of the form "We have a good-faith belief that XYZ video infringes our client's rights in work ABC", where they do have authorization to act on behalf of work ABC. I would hope that would become actionable if there is a pattern of complaints where it is hard to imagine any good-faith belief of infringement.
The perjury statement for the take-down notice requires a statement "that the complaining party is authorized to act on behalf of the owner of an exclusive right that is allegedly infringed". As I read it, that requires that the notice contain some other allegation that an exclusive right is infringed, and that the work and the exclusive right be identified accurately. If the notice does not accurately identify a work (and right) that the complainer is authorized to act on, the complainer might have answer for perjury.
He should have received a warning, but being kicked out of his house for three days and having probably thousands of dollars worth of materials taken -- in the absence of any clearly stated hazard, even when the government had that much time to find anything -- is somehow acceptable? I, for one, don't think so.
Your argument about speed limit laws is a straw man: Nowhere did I suggest that zoning or storage laws were groundless. What I said was that if the police did arrest him, that would allow them to perform certain kinds of search and seizure. They did not arrest him, so that reason for seizing his property is not available to them.
As to your lame defense of "vessel" versus "vat" as semantics: that was precisely my point. There is a definite semantic difference between the two words, and you -- whether intentionally or carelessly -- used the one that is scarier than what the closer sources chose.
Finally, for your edification, what I closed with was not argumentum ad hominem, which is an invalid logical device that I avoid using. It was a simple personal attack. I am not afraid to deal out sharp words where they have been earned.
Some sort of background? The first line of TFA says he's a retired chemist; later it says he continues to perform experiments. As for "moderately dangerous", the second paragraph of TFA says none were more dangerous than household cleaning products. It also characterized the containers as "vessels", rather than the "vats" you used. Vessels can be much smaller and might normally be closed. I suspect that if the authorities could have legitimately called them vats, they would have used that word rather than "vessels".
In other news, fire departments do not have the authority to confiscate rags covered in paint. Additionally, the fact that he was not arrested and will not be charged makes it more likely that the seizure was unconstitutional: search and seizure incident to arrest is one of the permitted forms of warrant-less search.
You totally fail at reading and at knowing civil rights in the USA.
How many small appliance fires require the police to maintain order?
But taking his stuff is the objectionable part, which is why I added the bit about the television. This was not a plain search (short of arrest, incident to arrest or vehicular) -- it was outright seizure without a warrant, in rather clear violation of the Fourth Amendment. What background would you want that would excuse the police taking that material?
Let me rephrase my question, then. When you invite a friend over for a party, do they also have permission to take your television? If so, I'd like to make your acquaintance. I think I'd get a lot of new gadgets.
It is people like you who enable abusive police. As penance, read a hundred articles by Radley Balko and ask a qualified lawyer about search and seizure laws in the USA.
"[T]he home owner invited the cops in when he called the fire department"? Tell me, when you invite a friend over for a party, do you invite their roommate over to steal your television? If so, I'd like to make your acquaintance. I think I'd get a lot of other new friends.
The owner of a music CD may make a backup/archive copy of that CD for $0.00. That doesn't stop the RIAA (or FSF, as the case may be) from having a legitimate claim that unauthorized mass copying does equate to actual damages. You're focusing on one -- irrelevant -- aspect of the copying and ignoring the aspects relevant to the alleged tort.
My group at work recently bought one of these. They catch a lot of things that compilers don't -- for example, code like this:
.. where invalid input causes arbitrarily bad behavior. They also tend to be better at inter-procedural analysis than compilers, so they can warn you that you're passing a short literal string to a function that will memcpy() from the region after that string. They do have a lot of false positives, but what escapes from compilers to be caught by static analysis tools tend to be dynamic behavior problems that are easy to overlook in testing. (If the problem were so obvious, the coder would have avoided it in the first place, right?)
No, they were both garden variety race conditions. This is single-threaded application code that doesn't do anything particularly novel or clever. IRC servers deal with new connections more often than most applications except high-traffic web servers, so the racy paths (in the system calls implementing accept() and getpeername() respectively) run a lot more often on large IRC servers than most places. To quantify "a lot", the server where the first problem was most troublesome sees upwards of 230 incoming connections per second -- both over the last ~50 days and over one recent minute.
I don't think that the FreeBSD guy fudged his benchmarks -- more likely, other FreeBSD people fudged the OS. Working with large-scale IRC servers, I have seen a few serious kernel-level race conditions on FreeBSD cause problems (like server processes that stop accepting connections in an unkillable state -- rebooting the server is a good way to fix things, right? -- and clients that appear to have the IP address 0.0.0.0). What's worse is that the unkillable process bug took many months to resolve. Linux and Solaris servers on the same IRC network never seem to have OS-related problems. It goes back to the old saw: make your code correct, *then* make it fast.
Not quite -- you're talking about depositions. Discovery is the entire process where each side in a civil case drafts written questions (the interrogatories mentioned by queequeg1 above) and asks for other information (requests for production [of documents or other tangible evidence]) in addition to real-time interviews (depositions) to the other. Interrogatories and requests for production typically do not involve stenographers.
Normally, the acceptable scope of discovery is pretty broad, and a court will allow a lot of discovery of proprietary or confidential information if it is covered by a suitable protective order. In this kind of case, where the defendant has no trade interest in the proprietary or confidential information, and where it is clearly relevant to the evidence relating to trying the claims, getting it through discovery and allowing an expert witness to review it should be nearly a slam dunk.
Even without signing that piece of paper, most software would be considered works for hire anyway, meaning copyright would initially be owned by the employer. In the software world, the core requirement for this is that the employee's writing of the software is "within the scope of his or her employment" (17 USC 101). Courts have set forth guidelines on determining whether it is within the scope of employment, most of which are hit on by a post farther down: being done on company time, guidance from the employer (in terms of requirements, management, or others), using tools provided by the employer, and so forth. Having a signature on paper removes any doubt and should help the employee understand the issues of ownership.
Maybe I've been lucky, but I only had really objectionable terms in one contract when joining a company. That company was small enough that they listened -- and changed the contract -- when I said I worked on unrelated open source software in my free time and wanted to retain ownership, rather than having every thought in my head automatically owned by the company.
Proper merge tracking has been on the "we plan to introduce it" list for Subversion since well before 1.0, along with a few other things that most strongly-formal customers expect from version control systems (like useful history tracking/recovery in the face of file renames; issue #928). At least they claim merge tracking is actually on trunk now (issue #820) -- I'll believe it works decently when I see it.
If the security patrols teleport instantly from one checkpoint to the next, your complaint might be significant. Most patrols I have seen move smoothly (in a mathematical sense) between points, which means that they will be at intermediate points in space at intermediate points in time. It's not hard to set checkpoints so that viable attack paths must cross one or more patrol paths -- the randomized patrol path and timing can be easily constrained to do that.
(In more detail: Enumerate building corners, junctions, important infrastructure, and other places that you can see a wide area, potential weaknesses or hiding spots. Record the expected time to travel between any pair of those points that you want to use in the randomized patrols. Stitch together several random walks through the graph. Use your favorite optimizer to ensure the collection of patrols meets whatever constraints you have for coverage. For bonus points, analyze a number of outputs to identify bias or weakness, and remove those problems.)
Quite the opposite. The bit about strategies given "perfect knowledge" by the opponent assumes that any information about practices or techniques could leak out. Given that, it seems obvious that the proper response is to determine an appropriate level of coverage, and then implement a randomized search pattern that conforms to those constraints. The security is not through obscurity but through a smaller window for discovering and exploiting the search pattern.
I manage a software development team for a living. Before putting on the pointy-haired manager hat, I wrote software full time. I still write code when necessary. The applications and customers for my day work require close and careful revision control as part of larger configuration management efforts. I would not use Perforce (the software) even if Perforce (the company) paid me to use it. At work, we use Subversion primarily because it has reasonable Windows support.
You avoided my question and introduced the "fanboy" ad hominem. I can only conclude that means that you have never used Perforce. You are the one acting like a Perforce/Google fanboy: you have provided exactly zero mention of technical merits and offered no rebuttal of my points. You are the one who was advocating for Perforce: it is not *my* job to defend your foolish argument, especially when you are obviously unwilling and/or unable to do so.
I also write software as a hobby. I wouldn't use Perforce for that, either. I use git for my own projects, and other revision control systems when there is a legacy repository in place.
By that standard, you made no point in your original post -- "one company uses Perforce" is not a point.
Have you used Perforce? I have used it in an academic environment and a corporate environment. It sucked both places, for the reasons I listed and a few I've probably forgotten. GIT is vastly superior for people who are developing on Unix-like operating systems. GIT is faster, more elegant, and much more functional than Perforce. On Windows, Subversion -- in the form of TortoiseSVN -- is generally better than Perforce, but not by the margin that GIT has. Subversion doesn't have *quite* as many features as Perforce, but the TortoiseSVN UI is better and Subversion is generally easier to use (because of the clientspec-stored-on-server part of Perforce).
Perforce is a pretty lousy configuration management system. Wide cross-platform support is the only positive aspect it really has going for it. Other aspects just suck less than certain alternatives: price, ease of use, SCM model, etc. Google probably developed easier front-ends in-house, but things like client specifications are maddeningly unintuitive in Perforce, branching is baroque, and having the *server* keep track of client workspace state is a mind-blowingly stupid performance optimization.
(GIT has several GUIs -- nicer than what Subversion and CVS have on Unix systems, but not as nice as TortoiseSVN or good commercial offerings. GIT can version binary files. The core-git CLI is continuously getting usability improvements, and there are other porcelains that try to make it even easier.)
Not only that, for each file, Subversion keeps a copy of the last version you checked out of (or in to) the repository, so if you have 10 MB of source code, you end up with 20 MB used on disk. GIT's pack file support lets you keep the entire history of a project in space that is usually comparable to the size of the source code.
In one of my projects that uses GIT, I have 7.5 MB of tracked source files, about 7.5 MB of compiled binaries and an 8.8 MB .git directory. That 8.8 MB fully describes every commit to every branch of the project for the last eight years. If I want to check out the first commit ever, I can do that. If I want to dig out a commit message from three years ago, no sweat. If I want to switch from one branch to another, it takes a second or two. Best of all, I can do all of those things entirely unplugged.
It's called "framing" -- as in framing the debate by choosing the terms.
This way anyone who might be sitting on the fence can clearly understand the consequences: If you think Microsoft is a stinky abusive monopolist but you are successful at offering large-scale 24x7 support to large customers, you're *community* Linux, not corporate, and your customers will leave you! Likewise, if you haven't upgrade to Shared Source Linux.NET, you will -- just as soon as Microsoft sends out the lawyers.
Civil trials in the United States -- at least any that people bother about -- must give the option for a trial by jury, per the Seventh Amendment. Either side may demand that a jury decide the facts in question.
They need a lot more than to claim a new use in order to have a valid patent. They also need it to be a useful and novel advancement in the field. I suspect the problem here will be novelty -- the various disc layering architectures are not novel to this patent, I suspect the alloy compositions (especially given in ranges as this patent apparently does) are not sufficiently novel, and combining shiny substances with a particular layering to produce an optical disc is *definitely* not novel.