CVS - Advantage: Supports multiple users, branching and merging (same server, DCVS variant provides some concept of distributed but should be avoided). Relatively easy to setup, and when restricted to ssh only access can be relatively secure. Disadvantage: no distributed support, very coarse security ( if you have access to the server and repository directory you have access, multiple projects on same server are clumsy to secure).
More disadvantages: can't rename files in a way that doesn't require coordination from everyone, must contact the repository for everything, no actual concept of changesets, and a bunch of other little things that add up to there being absolutely no reason that it should be used any more. Essentially everything that CVS does, SVN does as well or better. About the only exception to this is that you can't just peruse the actual SVN repository; whether this is a good or bad thing is left up to the reader.
SVN - better than CVS, but harder to setup ( less obvious ?). Distributed support (sort of), but no concept of locking checkouts, so not suitable for code that is not easily merged ( VHDL and Verilog can get ugly when you try to merge what appear to be trivial changes ).
What's wrong with 'svn lock'?
Perforce -... The only tool listed so far that supports atomic checkins.
You might want to check that fact again; Subversion has atomic commits.
It's possible I'm missing some shortcut syntax or something, but just the Subversion syntax for creating a branch and merging is just terrible. Compare git checkout -b my-new-branch to either remembering the whole repository URL or running svn info and copying and pasting it, then running svn copy some://really.long/url/to/your/repository/trunk some://really.long/url/to/your/repository/branches/my-new-branch then svn switch some://really.long/url/to/your/repository/branches/my-new-branch. And merging is similar.
You can avoid this syntax by checking out the whole damn repository and using working-copy paths, but this has its own set of severe drawbacks (e.g. now your svn copy takes a long time).
These drawbacks are made smaller by Tortoise (which is awesome) since you can just edit the existing URL in the switch dialog, but it's still pretty darn ugly.
I like Subversion, probably just because I know it, and use it for my home projects, but if there was an actual benefit... I'd love to switch to something better
I'd really encourage you to give Git a shot. Pick a project and use it for that project. It takes some getting used to, but it's not too bad, and once you are used to it it provides a number of really nice benefits even if you're just a single person working on your own projects. And there is a TortoiseGit that works well. (Just be aware that TortoiseGit attempts to hide what Git calls the index. This makes it act more like TortoiseSvn from your standpoint, but I did run into a problem once that was caused by mixing use of TortoiseGit and the command line git client in one repository.)
(From my own standpoint, I've heavily used all of CVS, Svn, and Git. I hate CVS with a passion, and for a long time thought that the improvements you get from moving from CVS to Svn were enormous in comparison to moving from Svn to Git. I still think this is true, but as I've used Git more and more, I think the Svn to Git change brought about rather more benefits than I initially considered even for single-person and centralized projects.)
Contrary to later comments in the article, I've used, and still use, CVS in several commercial products and it works just fine.
One of us is probably a basket case then. I whine about most programs I use, but a program is in rare company if I complain about it as much as CVS.
I hate it enough that if I was considering starting to contribute to an open source project and the project I was considering used CVS, that alone would be enough for me to drop that idea.
Indeed.. credit card companies _hate_ this. Not only are you not making them money, you are probably costing them money!
Eh, unlikely. Remember that they get a cut of the sale price too. My impression is that is around 3%, so even with a pretty generous 1% rewards thing leaves them with quite a bit of leeway. I can't imagine that administration costs of someone's card who isn't a problem would exceed that amount.
And yet there's the trademark dispute over the Apple brand...
Since apparently you weren't paying attention, there was the trademark dispute but it was permanently resolved years ago.
(BTW it's amusing that you use the sosumi example instead of when they later sued when Apple started iTunes -- which I felt they actually had a solid basis on which to stand.)
I'd argue that trackers and version control should not be taught in a CS curriculum.
Trackers... OK, I don't see those as essential. Version control? Disagree vehemently. There might be a couple programs in the country where you can specialize in theory enough to avoid all heavy programming, but most programs require you to do at least some practical courses (OS, compilers, etc.), and even in programs where you could avoid such classes probably most students don't. And IMO, if you're teaching a programming-heavy class and you don't at least strongly recommend using version control and give a quick overview of what that means and why you want it, you're doing your students a big disservice.
I'm not saying "spend a week going over CVS, SVN, Git, and Mecrcural" or anything like that, but a 15-minute quick intro to one of them of your choice is definitely not out of place in many CS classes.
...so if you're familiar with that, you can skip the next paragraph.
Um actually looking over my post, I should probably retract that statement; I'm thinking I probably didn't write the last paragraph in a way that makes much sense without at least getting the setting right. So you may want to skim over the second paragraph if you're familiar with Coverity instead of skipping it entirely.:-)
Buffer overrun happens when you are supposed to treat a block of bytes as void, hence you're not supposed to dereference the pointer, but you try to use it as char or int or float.
I know what you're saying, and lots of people call that sort of thing a type error. That said, to me it still feels very different than the 'x=y' case. One reason I think I feel that way is that you don't necessarily have to have a type error per se for something like that to cause a big bug. If you have in int array adjacent to an int, and you overflow the int array into the int, that's still a bug even though all the accesses are still consistent with the way the memory block is being used. Still, it's mostly a matter of perception.
How does linear constraint with no elementary recursion help verifying device driver code? How do I know if I'm programming hardware in an inconsistent state? How do I know if my program is having race condition with the hardware, say sending commands to the hardware when the hardware is not ready?
So the SDV works with a slightly different technique; assuming my memory is right, from the outside it actually looks pretty similar to my understanding of what Coverity does (and definitely Engler's Stanford Checker), so if you're familiar with that, you can skip the next paragraph.
In addition to the program you're testing, you give it a specification of a property that you want to check. This specification takes the form of a finite state machine, where the nodes are specific to the property you're interested in and the transitions are patterns in the source code the tool looks for. The sort of canonical example I use is checking for correct lock behavior. Suppose you want to check that a function (including those it transitively calls) behaves properly with respect to a lock: it always exits with the lock released and never tries to lock it twice. Your specification will have three states: unlocked, locked, and error. The pattern 'lock(x)' moves the machine from the unlocked state to the locked state, or the locked state to the error state (double lock). The pattern 'unlock(x)' moves the machine from the locked state to the unlocked state, or the unlocked state to the error state (double unlock). Finally, the return of the top-level function will move the machine from the locked state to the error state (return with the lock held). (Coverity, and I think SDV, will instantiate different copies of the machine for different lock variables, so if you have 'lock(x)' then 'lock(y)', this is OK.)
It's not too hard to adapt the techniques I discussed above to check a property specified in a similar manner. The techniques I described in my last post, in particular the verification work, can establish (well, given sufficient patience which may not happen) whether or not a particular program point is reachable. I'm not terribly familiar with the details of how the state-machine style checking, and there are probably a couple different ways to do it, but it basically consists of weaving the state machine code into the program code. Once that's done, you can check whether the code corresponding to the error state is reachable using the techniques above.
Huh? I don't understand how this is a reasonable argument in the larger context of disabling javascript being a bad thing. It just seems like a random retort.
It's only somewhat random. If your argument is that disabling JS means that your plugins are disabled so you won't get infected through them, then not running a browser also means that.
Just as you don't need to "not run a browser" to eliminate plugin-based security threats, you also don't need to "not run JS" to eliminate plugin-based security threats.
Disable javascript: Block all "raw" javascript exploits AND block almost all plugin exploits. Disable plugins: Only block plugin exploits.
True, but: "Disable javascript: Break a ton of websites Disable plugins: Break few websites and get almost all of the security benefit of disabling JS"
Look, I get annoyed at websites that require JS for stupid crap that shouldn't need JS too, and I browse with JS disabled too. But at the same time, rightly or wrongly, I do it almost exclusively to make tracking a tiny bit more difficult and almost not at all because of any sort of local security benefit.
Coverity can make (1) and (2), even for the bugs it finds. E.g. it can both say "this is a possible null-pointer dereference" when there can be no null-pointer dereference as well as "I did not find any null-pointer dereferences" in a program with null-pointer dereferences.
(2) characterizes almost every language where the type system is not expressive enough.
Fair enough; you can certainly argue that type systems are also (1) and (2); there's definitely some (1) for the reason I give.
I tend to see buffer overruns as a separate class of bugs than the sort of things that type systems tend to prevent (treating this block of bytes as a floating point when it's an int), and thus don't really count that as a "missed bug" for the purposes of classification. (There's no analysis out there that even remotely claims to be able to find all bugs, so all tools have at least some (2) in them. So I rate tools in terms of the bugs that they claim to be able to find so that the category is actually meaningful.)
As for (3), I vaguely remember a passing fact that type inference for impredicative polymorphism is undecidable. Maybe that's something you're working on? I'd like to hear about it.
Nah; it doesn't really have to do with type theory at all. So one of the things I mentioned was concolic execution. This is a portmanteau of "concrete" and "symbolic" execution. It was originally conceived as a way of generating a set of tests for a function, aiming for high path coverage. Basically the way it works is you execute the function with some random input. You collect up a formula that describes the path that the trace took through the function (e.g. if the input is 'x' and it executed 'x=x+1' then 'if(x>0)' you'd get a formula like 'x_0+1 > 0'). You then negate the part of the formula corresponding to one of the conditions and give it to a theorem prover; if it's satisfiable, then what you get back is a new input for the function that will cause execution to take almost the same path, except take the opposite branch at the condition that you negated. That's your second test. Collect up constraints, feed it to a theorem prover, get the result, that's your third test. Repeat. (The "concrete execution" is running the function with the inputs you get from the theorem prover; the "symbolic execution" is building up the path constraint formula.)
If the formula you give to the theorem prover is not satisfiable, then you have to discard it and try another. At some point, it's possible that you have tried all possible modifications of the formulas you've collected; if this occurs, congratulations, you now have a set of tests that gives you complete path coverage of the function. But if the function has a loop in it, then theoretically this will run forever, because you'll get tests that traverse the loop once, then twice, then thrice, etc. and you'll just keep increasing the number of times you go around the loop.
Concolic execution gives you an underapproximation of the program's behavior: you get a bunch of concrete test inputs, but it's in general possible that they don't explore all of the function's behavior. You can't do program verification with an underapproxmation, because to say a program is free of bugs, you have to know something about all possible behaviors.
Given this background, the recent work on verification I mentioned can be said to combine concolic execution with an overapproximation of the program. In this scheme, the overapproximation helps you discover new tests (in other words, get a more precise underapproximation) and the underapproximation helps you refine the overapproximation so it is more precise. In a nutshell, in cases where the theorem prover says a path constraint is unsatisfiable, instead of just tossing it out and trying another, you use that opportunity to make your underapproximation more precise.
(The technique was originally developed at MS Research and at some point might replace the current engine in their Static Driver Verifier; the research group I'm in has adapted the idea and developed some new techniques that makes it amenable to verifying machine code instead of source.)
However, I've not seen any formal soundness proof of Coverity itself. As a result, Coverity may very well accept buggy programs as correct. This would certainly limit the tool's usefulness.
Oh, it definitely does. And in some sense it limits its utility, but it also is what lets it be as successful as it is.
Rice's theorem says that the ultimate goal -- determine whether a program is buggy -- is literally impossible to be guaranteed to do completely accurately. Because of this, there are three possibilities that you can take when making a tool that attempts to do that; you must pick at least one.
1. You can say a program is (or may be) buggy when it isn't. 2. You can say a program is free of bugs when it is actually buggy. 3. You can accept the possibility that your tool will run forever.
Each of these occurs in practice. A familiar example of #1 is the type system of a statically-typed language: if x has type int and y has type SomeClass, the type system will say that a program containing the expression x = y is not legal even if it is impossible for that statement to actually execute (and thus the actual failure type systems are designed to prevent can't actually happen). I'm actually having a hard time thinking of a tool that picks just #2, but I'm sure there are some out there. #3 is the hallmark of some techniques such as concolic execution and some recent work on program verification. (I'm involved in one of the last tools.)
But there are also a number of tools out there that admit the possibility of both false positives and false negatives: in other words both #1 and #2 can happen. The benefit you can get by doing that is that you can get an analysis that can find errors that are rather deeper than, say, your type system and yet it'll still scale to very large programs.
There's no one perfect analysis; there's a spectrum based on how much you value finding bugs, how much you value gaining assurance that a program is bug-free, how deep of bugs you want to find, and how large of a code base you have to run on. Saying that Coverity "limits its usefulness" based on the spot it choose in the design space is true, but slightly misleadingly so, because every program analysis limits its utility, just in different ways. IMO not having used it, Coverity found a spot which is quite useful.
Similarly, "a site needs to use" is not the same as "a site currently needs."
Try searching, say, Best Buy's site for something. At least for me, it doesn't work if JS is off. It barely matters one iota that Best Buy could program their site so that you don't need it; only the fact that it does need it matters. There are a lot of websites like that.
Most JS on an average website does nothing good for the user. It tracks them or it annoys them.
My experience is that at least a very sizable minority of websites need JS to be usable. For instance, there are a LOT of websites out there where even the damn 'search' box won't work if you don't have JS on.
I'm not sure I would dispute your claim completely, but it's far from "oh, just a few sites need it".
While this is factually correct, it is not the whole story. Firstly in the context of this discussion; Folk who disable Javascript are probably not running ANY browser plugins (I'm certainly not).
This is true, but the converse is probably not. Maybe my assumption is something like the anthropic principle, but I had Flashblock for AGES before I even remotely seriously considered blocking JS.
It would be interesting to see the number of people who browse with JS off vs the number who browse with just plugins disabled or not installed (at least Flash + Java). The former might be bigger, but I suspect that's only because one of the nicest ways to block plugins in FF is with NoScript.
Nobody disables javascript because they want to, they disable it because javascript is the number one source of web browser vulnerabilities by at least an order of magnitude, probably two.
No it isn't, not even close. Flash and Acrobat Reader are by far the biggest infection vectors; raw, browser-based JS is positively benign by comparison.
Stuff like making it easier to do tracking cookies and be generally annoying are JS's biggest flaws.
The only "rights" BSD grants that GPL doesn't is the "right" to remove the rights of the end user.
With a program released under the BSD license, I have the right to combine that with other code issued under, say, the CDDL. With a program released under the GPL, I do not have that right.
How is "combine this with something under the CDDL" acting to remove the rights of the end user?
Grades 1 through 6 for me had 30 to 45 minute sessions throughout the day, and you almost always changed classrooms for each session (This room is the Math room, that room is the English room, that Room is the Music room) - so anytime you switched subjects you were basically switching rooms.
My own experience was that that degree of subject-specific room assignment only started in 7th grade. 1st through 6th the way it worked was as follows: you had a "homeroom", which is where you had most of your classes. There were special topics stuff like art, music, and gym, and for those you went somewhere else. Math classes were the only subject that was split up by aptitude; for that subject, everyone in the same grade was released at the same time to go to (probably) some other room for math. Finally, for a couple years only we would also change rooms for either social studies or science class depending on the particular semester. All told, room changes weren't exactly infrequent, but at the same time over half your day was still spent in your homeroom, and there were probably three or so subject changes each day that didn't involve a room switch.
The chairs attached to a small writing pad (like the one linked to) are just horrible for a lecture or class. You can fit no more than a small notebook on the surface: want to get out your other notebook, a handout, or your laptop, and take a look at both at the same time? Tough luck!
You think those are bad for most people? Try one if you're left-handed. I've been in rooms with desks like that bolted to the ground where it's about equally comfortable to use the "desk" attached to my chair as it is to use the desk attached to the chair to my left.
The ones with desks that actually stretch across you the whole way aren't too bad, but still noticeably worse if you're a lefty, and a lot worse for everyone than an actual desk.
Sometimes you'll even get a room with lefty desk-chairs. Of course, there may well not be enough of them, and you may well be stuck at the edge of an aisle instead of being able to sit where you please, but that's what you get for being a southpaw.
Yes; I'm just dumb and badly misread my original parent (i.e. interpreted it as "how could CGI be cheaper than stop motion" in response to the summary's "Some even say that stop motion is cheaper than computer generated animation").
As someone who has been using Opera for a while, I just tried out the beta of FF4. (I was considering writing my own extension; the "4 beta" doesn't matter, but I figured might as well giv it a short.) Yeah, whatever. More FF. But in the process I installed NoScript -- and it kicks the ass of Opera's feature. It tells you when it's blocking something (as opposed to Opera, where you have to sort of get a feel for when a site isn't working right because JS is off), is fewer clicks to whitelist a site, and lets you selectively whitelist only some of the JS on a particular page. It's wonderful. I've switched to FF here at work since that's where I installed it, and will probably switch at home when it hits a RC. All by virtue of NoScript.
If NoScript comes to Opera 11, I'll probably switch right back though.
For instance, why isn't your page dynamically generated server-side, if you're trying to promote safe browsing practices?
To be fair, the results they show include interactive graphs. Sure, they could present results that degrade gracefully instead of just an error message, which would have been nice, but it's not like they're just using it for the hell of it.
It's certainly better than many sites out there that just break, or sites that degrade somewhat gracefully but don't tell you thinks would be rather nicer with JS.
Oh, right, because you're not; you want me to buy your software...
It's far from clear that they have any plan to sell BLADE. It's a research prototype created by a university research group hosted at a.org URL. (This of course is far from meaning that they don't plan to sell it; plenty of university research gets turned into a company or product. At the same time, it's not like this is some a couple random guys trying to distribute scareware.)
Slashdot Mirror
CVS - Advantage: Supports multiple users, branching and merging (same server, DCVS variant provides some concept of distributed but should be avoided). Relatively easy to setup, and when restricted to ssh only access can be relatively secure. Disadvantage: no distributed support, very coarse security ( if you have access to the server and repository directory you have access, multiple projects on same server are clumsy to secure).
More disadvantages: can't rename files in a way that doesn't require coordination from everyone, must contact the repository for everything, no actual concept of changesets, and a bunch of other little things that add up to there being absolutely no reason that it should be used any more. Essentially everything that CVS does, SVN does as well or better. About the only exception to this is that you can't just peruse the actual SVN repository; whether this is a good or bad thing is left up to the reader.
SVN - better than CVS, but harder to setup ( less obvious ?). Distributed support (sort of), but no concept of locking checkouts, so not suitable for code that is not easily merged ( VHDL and Verilog can get ugly when you try to merge what appear to be trivial changes ).
What's wrong with 'svn lock'?
Perforce - ... The only tool listed so far that supports atomic checkins.
You might want to check that fact again; Subversion has atomic commits.
It's possible I'm missing some shortcut syntax or something, but just the Subversion syntax for creating a branch and merging is just terrible. Compare git checkout -b my-new-branch to either remembering the whole repository URL or running svn info and copying and pasting it, then running svn copy some://really.long/url/to/your/repository/trunk some://really.long/url/to/your/repository/branches/my-new-branch then svn switch some://really.long/url/to/your/repository/branches/my-new-branch. And merging is similar.
You can avoid this syntax by checking out the whole damn repository and using working-copy paths, but this has its own set of severe drawbacks (e.g. now your svn copy takes a long time).
These drawbacks are made smaller by Tortoise (which is awesome) since you can just edit the existing URL in the switch dialog, but it's still pretty darn ugly.
I like Subversion, probably just because I know it, and use it for my home projects, but if there was an actual benefit ... I'd love to switch to something better
I'd really encourage you to give Git a shot. Pick a project and use it for that project. It takes some getting used to, but it's not too bad, and once you are used to it it provides a number of really nice benefits even if you're just a single person working on your own projects. And there is a TortoiseGit that works well. (Just be aware that TortoiseGit attempts to hide what Git calls the index. This makes it act more like TortoiseSvn from your standpoint, but I did run into a problem once that was caused by mixing use of TortoiseGit and the command line git client in one repository.)
(From my own standpoint, I've heavily used all of CVS, Svn, and Git. I hate CVS with a passion, and for a long time thought that the improvements you get from moving from CVS to Svn were enormous in comparison to moving from Svn to Git. I still think this is true, but as I've used Git more and more, I think the Svn to Git change brought about rather more benefits than I initially considered even for single-person and centralized projects.)
Contrary to later comments in the article, I've used, and still use, CVS in several commercial products and it works just fine.
One of us is probably a basket case then. I whine about most programs I use, but a program is in rare company if I complain about it as much as CVS.
I hate it enough that if I was considering starting to contribute to an open source project and the project I was considering used CVS, that alone would be enough for me to drop that idea.
Indeed.. credit card companies _hate_ this. Not only are you not making them money, you are probably costing them money!
Eh, unlikely. Remember that they get a cut of the sale price too. My impression is that is around 3%, so even with a pretty generous 1% rewards thing leaves them with quite a bit of leeway. I can't imagine that administration costs of someone's card who isn't a problem would exceed that amount.
And yet there's the trademark dispute over the Apple brand...
Since apparently you weren't paying attention, there was the trademark dispute but it was permanently resolved years ago.
(BTW it's amusing that you use the sosumi example instead of when they later sued when Apple started iTunes -- which I felt they actually had a solid basis on which to stand.)
I'd argue that trackers and version control should not be taught in a CS curriculum.
Trackers... OK, I don't see those as essential. Version control? Disagree vehemently. There might be a couple programs in the country where you can specialize in theory enough to avoid all heavy programming, but most programs require you to do at least some practical courses (OS, compilers, etc.), and even in programs where you could avoid such classes probably most students don't. And IMO, if you're teaching a programming-heavy class and you don't at least strongly recommend using version control and give a quick overview of what that means and why you want it, you're doing your students a big disservice.
I'm not saying "spend a week going over CVS, SVN, Git, and Mecrcural" or anything like that, but a 15-minute quick intro to one of them of your choice is definitely not out of place in many CS classes.
...so if you're familiar with that, you can skip the next paragraph.
Um actually looking over my post, I should probably retract that statement; I'm thinking I probably didn't write the last paragraph in a way that makes much sense without at least getting the setting right. So you may want to skim over the second paragraph if you're familiar with Coverity instead of skipping it entirely. :-)
Buffer overrun happens when you are supposed to treat a block of bytes as void, hence you're not supposed to dereference the pointer, but you try to use it as char or int or float.
I know what you're saying, and lots of people call that sort of thing a type error. That said, to me it still feels very different than the 'x=y' case. One reason I think I feel that way is that you don't necessarily have to have a type error per se for something like that to cause a big bug. If you have in int array adjacent to an int, and you overflow the int array into the int, that's still a bug even though all the accesses are still consistent with the way the memory block is being used. Still, it's mostly a matter of perception.
How does linear constraint with no elementary recursion help verifying device driver code? How do I know if I'm programming hardware in an inconsistent state? How do I know if my program is having race condition with the hardware, say sending commands to the hardware when the hardware is not ready?
So the SDV works with a slightly different technique; assuming my memory is right, from the outside it actually looks pretty similar to my understanding of what Coverity does (and definitely Engler's Stanford Checker), so if you're familiar with that, you can skip the next paragraph.
In addition to the program you're testing, you give it a specification of a property that you want to check. This specification takes the form of a finite state machine, where the nodes are specific to the property you're interested in and the transitions are patterns in the source code the tool looks for. The sort of canonical example I use is checking for correct lock behavior. Suppose you want to check that a function (including those it transitively calls) behaves properly with respect to a lock: it always exits with the lock released and never tries to lock it twice. Your specification will have three states: unlocked, locked, and error. The pattern 'lock(x)' moves the machine from the unlocked state to the locked state, or the locked state to the error state (double lock). The pattern 'unlock(x)' moves the machine from the locked state to the unlocked state, or the unlocked state to the error state (double unlock). Finally, the return of the top-level function will move the machine from the locked state to the error state (return with the lock held). (Coverity, and I think SDV, will instantiate different copies of the machine for different lock variables, so if you have 'lock(x)' then 'lock(y)', this is OK.)
It's not too hard to adapt the techniques I discussed above to check a property specified in a similar manner. The techniques I described in my last post, in particular the verification work, can establish (well, given sufficient patience which may not happen) whether or not a particular program point is reachable. I'm not terribly familiar with the details of how the state-machine style checking, and there are probably a couple different ways to do it, but it basically consists of weaving the state machine code into the program code. Once that's done, you can check whether the code corresponding to the error state is reachable using the techniques above.
Huh? I don't understand how this is a reasonable argument in the larger context of disabling javascript being a bad thing. It just seems like a random retort.
It's only somewhat random. If your argument is that disabling JS means that your plugins are disabled so you won't get infected through them, then not running a browser also means that.
Just as you don't need to "not run a browser" to eliminate plugin-based security threats, you also don't need to "not run JS" to eliminate plugin-based security threats.
Disable javascript: Block all "raw" javascript exploits AND block almost all plugin exploits.
Disable plugins: Only block plugin exploits.
True, but:
"Disable javascript: Break a ton of websites
Disable plugins: Break few websites and get almost all of the security benefit of disabling JS"
Look, I get annoyed at websites that require JS for stupid crap that shouldn't need JS too, and I browse with JS disabled too. But at the same time, rightly or wrongly, I do it almost exclusively to make tracking a tiny bit more difficult and almost not at all because of any sort of local security benefit.
Actually, (1) characterizes tools like Coverity.
Coverity can make (1) and (2), even for the bugs it finds. E.g. it can both say "this is a possible null-pointer dereference" when there can be no null-pointer dereference as well as "I did not find any null-pointer dereferences" in a program with null-pointer dereferences.
(2) characterizes almost every language where the type system is not expressive enough.
Fair enough; you can certainly argue that type systems are also (1) and (2); there's definitely some (1) for the reason I give.
I tend to see buffer overruns as a separate class of bugs than the sort of things that type systems tend to prevent (treating this block of bytes as a floating point when it's an int), and thus don't really count that as a "missed bug" for the purposes of classification. (There's no analysis out there that even remotely claims to be able to find all bugs, so all tools have at least some (2) in them. So I rate tools in terms of the bugs that they claim to be able to find so that the category is actually meaningful.)
As for (3), I vaguely remember a passing fact that type inference for impredicative polymorphism is undecidable. Maybe that's something you're working on? I'd like to hear about it.
Nah; it doesn't really have to do with type theory at all. So one of the things I mentioned was concolic execution. This is a portmanteau of "concrete" and "symbolic" execution. It was originally conceived as a way of generating a set of tests for a function, aiming for high path coverage. Basically the way it works is you execute the function with some random input. You collect up a formula that describes the path that the trace took through the function (e.g. if the input is 'x' and it executed 'x=x+1' then 'if(x>0)' you'd get a formula like 'x_0+1 > 0'). You then negate the part of the formula corresponding to one of the conditions and give it to a theorem prover; if it's satisfiable, then what you get back is a new input for the function that will cause execution to take almost the same path, except take the opposite branch at the condition that you negated. That's your second test. Collect up constraints, feed it to a theorem prover, get the result, that's your third test. Repeat. (The "concrete execution" is running the function with the inputs you get from the theorem prover; the "symbolic execution" is building up the path constraint formula.)
If the formula you give to the theorem prover is not satisfiable, then you have to discard it and try another. At some point, it's possible that you have tried all possible modifications of the formulas you've collected; if this occurs, congratulations, you now have a set of tests that gives you complete path coverage of the function. But if the function has a loop in it, then theoretically this will run forever, because you'll get tests that traverse the loop once, then twice, then thrice, etc. and you'll just keep increasing the number of times you go around the loop.
Concolic execution gives you an underapproximation of the program's behavior: you get a bunch of concrete test inputs, but it's in general possible that they don't explore all of the function's behavior. You can't do program verification with an underapproxmation, because to say a program is free of bugs, you have to know something about all possible behaviors.
Given this background, the recent work on verification I mentioned can be said to combine concolic execution with an overapproximation of the program. In this scheme, the overapproximation helps you discover new tests (in other words, get a more precise underapproximation) and the underapproximation helps you refine the overapproximation so it is more precise. In a nutshell, in cases where the theorem prover says a path constraint is unsatisfiable, instead of just tossing it out and trying another, you use that opportunity to make your underapproximation more precise.
(The technique was originally developed at MS Research and at some point might replace the current engine in their Static Driver Verifier; the research group I'm in has adapted the idea and developed some new techniques that makes it amenable to verifying machine code instead of source.)
However, I've not seen any formal soundness proof of Coverity itself. As a result, Coverity may very well accept buggy programs as correct. This would certainly limit the tool's usefulness.
Oh, it definitely does. And in some sense it limits its utility, but it also is what lets it be as successful as it is.
Rice's theorem says that the ultimate goal -- determine whether a program is buggy -- is literally impossible to be guaranteed to do completely accurately. Because of this, there are three possibilities that you can take when making a tool that attempts to do that; you must pick at least one.
1. You can say a program is (or may be) buggy when it isn't.
2. You can say a program is free of bugs when it is actually buggy.
3. You can accept the possibility that your tool will run forever.
Each of these occurs in practice. A familiar example of #1 is the type system of a statically-typed language: if x has type int and y has type SomeClass, the type system will say that a program containing the expression x = y is not legal even if it is impossible for that statement to actually execute (and thus the actual failure type systems are designed to prevent can't actually happen). I'm actually having a hard time thinking of a tool that picks just #2, but I'm sure there are some out there. #3 is the hallmark of some techniques such as concolic execution and some recent work on program verification. (I'm involved in one of the last tools.)
But there are also a number of tools out there that admit the possibility of both false positives and false negatives: in other words both #1 and #2 can happen. The benefit you can get by doing that is that you can get an analysis that can find errors that are rather deeper than, say, your type system and yet it'll still scale to very large programs.
There's no one perfect analysis; there's a spectrum based on how much you value finding bugs, how much you value gaining assurance that a program is bug-free, how deep of bugs you want to find, and how large of a code base you have to run on. Saying that Coverity "limits its usefulness" based on the spot it choose in the design space is true, but slightly misleadingly so, because every program analysis limits its utility, just in different ways. IMO not having used it, Coverity found a spot which is quite useful.
Using JS is not the same as needing JS.
Similarly, "a site needs to use" is not the same as "a site currently needs."
Try searching, say, Best Buy's site for something. At least for me, it doesn't work if JS is off. It barely matters one iota that Best Buy could program their site so that you don't need it; only the fact that it does need it matters. There are a lot of websites like that.
True, but you could also say that practically none of those flash and acrobat vulnerabilities are exposed unless you start your web browser.
It's not hard to disable plugins without disabling browser JS, and doing so would be a pretty darn reasonable thing to do IMO.
Most JS on an average website does nothing good for the user. It tracks them or it annoys them.
My experience is that at least a very sizable minority of websites need JS to be usable. For instance, there are a LOT of websites out there where even the damn 'search' box won't work if you don't have JS on.
I'm not sure I would dispute your claim completely, but it's far from "oh, just a few sites need it".
While this is factually correct, it is not the whole story. Firstly in the context of this discussion; Folk who disable Javascript are probably not running ANY browser plugins (I'm certainly not).
This is true, but the converse is probably not. Maybe my assumption is something like the anthropic principle, but I had Flashblock for AGES before I even remotely seriously considered blocking JS.
It would be interesting to see the number of people who browse with JS off vs the number who browse with just plugins disabled or not installed (at least Flash + Java). The former might be bigger, but I suspect that's only because one of the nicest ways to block plugins in FF is with NoScript.
Nobody disables javascript because they want to, they disable it because javascript is the number one source of web browser vulnerabilities by at least an order of magnitude, probably two.
No it isn't, not even close. Flash and Acrobat Reader are by far the biggest infection vectors; raw, browser-based JS is positively benign by comparison.
Stuff like making it easier to do tracking cookies and be generally annoying are JS's biggest flaws.
The only "rights" BSD grants that GPL doesn't is the "right" to remove the rights of the end user.
With a program released under the BSD license, I have the right to combine that with other code issued under, say, the CDDL. With a program released under the GPL, I do not have that right.
How is "combine this with something under the CDDL" acting to remove the rights of the end user?
Grades 1 through 6 for me had 30 to 45 minute sessions throughout the day, and you almost always changed classrooms for each session (This room is the Math room, that room is the English room, that Room is the Music room) - so anytime you switched subjects you were basically switching rooms.
My own experience was that that degree of subject-specific room assignment only started in 7th grade. 1st through 6th the way it worked was as follows: you had a "homeroom", which is where you had most of your classes. There were special topics stuff like art, music, and gym, and for those you went somewhere else. Math classes were the only subject that was split up by aptitude; for that subject, everyone in the same grade was released at the same time to go to (probably) some other room for math. Finally, for a couple years only we would also change rooms for either social studies or science class depending on the particular semester. All told, room changes weren't exactly infrequent, but at the same time over half your day was still spent in your homeroom, and there were probably three or so subject changes each day that didn't involve a room switch.
The chairs attached to a small writing pad (like the one linked to) are just horrible for a lecture or class. You can fit no more than a small notebook on the surface: want to get out your other notebook, a handout, or your laptop, and take a look at both at the same time? Tough luck!
You think those are bad for most people? Try one if you're left-handed. I've been in rooms with desks like that bolted to the ground where it's about equally comfortable to use the "desk" attached to my chair as it is to use the desk attached to the chair to my left.
The ones with desks that actually stretch across you the whole way aren't too bad, but still noticeably worse if you're a lefty, and a lot worse for everyone than an actual desk.
Sometimes you'll even get a room with lefty desk-chairs. Of course, there may well not be enough of them, and you may well be stuck at the edge of an aisle instead of being able to sit where you please, but that's what you get for being a southpaw.
(I'm not bitter. Not at all.)
Re-render? Do you even know what stop motion is?
Yes; I'm just dumb and badly misread my original parent (i.e. interpreted it as "how could CGI be cheaper than stop motion" in response to the summary's "Some even say that stop motion is cheaper than computer generated animation").
Ignore/mod down my post; false alarm.
What is a computer going to do, move the model for you? Snap the frame for you?
Um, yes. That's the idea behind setting keyframes: you only specify where things are at certain points, and the computer interpolates for you.
It also means that if you messed up a shot in some way you don't have to go all the way back and reshoot: you can just fix it and rerender.
It also means that you don't have to build physical models or buy a camera.
Remove the "idle." from the URL.
As someone who has been using Opera for a while, I just tried out the beta of FF4. (I was considering writing my own extension; the "4 beta" doesn't matter, but I figured might as well giv it a short.) Yeah, whatever. More FF. But in the process I installed NoScript -- and it kicks the ass of Opera's feature. It tells you when it's blocking something (as opposed to Opera, where you have to sort of get a feel for when a site isn't working right because JS is off), is fewer clicks to whitelist a site, and lets you selectively whitelist only some of the JS on a particular page. It's wonderful. I've switched to FF here at work since that's where I installed it, and will probably switch at home when it hits a RC. All by virtue of NoScript.
If NoScript comes to Opera 11, I'll probably switch right back though.
And if you're installing OS X on a hackintosh, you're breaking the license agreement anyways.
Which is kinda the point of the original post: "it requires OSX which you cant legally acquire without buying a mac first."
For instance, why isn't your page dynamically generated server-side, if you're trying to promote safe browsing practices?
To be fair, the results they show include interactive graphs. Sure, they could present results that degrade gracefully instead of just an error message, which would have been nice, but it's not like they're just using it for the hell of it.
It's certainly better than many sites out there that just break, or sites that degrade somewhat gracefully but don't tell you thinks would be rather nicer with JS.
Oh, right, because you're not; you want me to buy your software...
It's far from clear that they have any plan to sell BLADE. It's a research prototype created by a university research group hosted at a .org URL. (This of course is far from meaning that they don't plan to sell it; plenty of university research gets turned into a company or product. At the same time, it's not like this is some a couple random guys trying to distribute scareware.)