Rust's type system provides protections against some problems that can be quite hard to debug in C.
Between having a programmer that is inexperienced in C writing C code and having a programmer inexperienced in Rust writing Rust code, arguably you might be better off with the latter.
This sounds like a reasonably small component, so what is the worst that could happen? That you would have to rewrite it some day? I'd say go for it.
Really? I remember reading Magister has a respectable-but-far-from-monopolistic market share of 10%, and there seem to be various options available, including the web-based SOM (formerly Vocus, http://product.simaconderwijs.nl/Onze_producten/SOM ). Of course they'll differ in scope, but there certainly seems to be competition.
(full disclosure: i work for a sister-company of the company that develops SOM)
I concur exactly with your null/NPE observations. The next addition I want to the Java spec is the ability to mark a method as never returning null.
JSR 305 defines a set of annotations that allow you to do this (including '@NonNull' for method return values).
The weakness of this is that you can formally specify a method should never return 'null' with this, but the compiler does not check whether you live up to this promise. There are tools that can do some basic checks against blatant mistakes (Eclipse does this nowadays), and tools that are a bit more advanced and find even more subtle mistakes (FindBugs comes to mind).
Really proving correctness without a doubt is an unsolved problem - even when adding additional annotations it's a tough nut to crack - check out research projects like ESC/Java if you're interested in the gory details
Stallman wrote the Java trap, and we all laughed. Sun is nice we thought, it'll be ok. We were all wrong. Stallman saw further, he saw that even if Sun was ok, if someone bought Sun, then things could get messy. Welcome to messy.
Actually, most of the platform has been open-sourced by Sun before the takeover under the 'OpenJDK' name.
The situation is still messy - but not for the original reasons laid out in that article. If worst came to worst, the JVM can be forked - but forking a widely-used platform is a whole other can of worms, of course.
>> You know, if that SSL certificate traces back to a valid human, then you can arrest him/her for phishing and they've provided all your evidence for you.
> Actually, some webserver used their private key to host a phishing site. Who actually set up the private key, which web servers it was used on, and who used it on the phishing site are all orthogonol questions.
> That's like saying because a car with a certain license plate hit someone, the owner was the driver.
The car owner / website administrator(s) are the ones who can bring you one step closer to the culprit, though, if you're lucky.
>>it simply guarantees that no one will view the information en route
>For that, a self-signed certificate would be all you would need. The whole justification >for CAs was to address the problem of verifying who you're talking to.
Err, no. If you see a self-signed certificate, you don't know whether it was signed by the website you're talking to, or by someone performing a man-in-the-middle attack.
The cert contains the fqdn of the website, and the CA should check that the owner of that website indeed holds the private key corresponding to the public key it signs.
Also, this is probably a message to the world (and possibly judges at some point...) that BitTorrent is mainly targeted to users with legitimate goals. That it is not purely a tool for pirates.
Holding features hostage: implement something, but don't release it until enough people have paid for it.
Early access (probably combined with dual licensing): give paying 'premium members' (or something flashy-sounding like that) access to new features before they show up in the public open-source releases.
Many of the games are win/Mac/Linux, but they sell something like 5% to linux users The rest being Win/Mac with lots of MAC sales - they buy. Apparently we (linux users) are a cheap bunch of mofos...
We already knew Macs are for spendy people. As for that 5%, given that much less than 5% of gamers use Linux, I'd say that's a pretty good score. Then you might argue that there are many more games available for Windows, so you'd expect the few commercial linux games to sell better. Then I could state the number is that low due to lack of interest rather than being cheap mofo's. After all linux users tend to be serious guys that like to get work done, and play nethack or install-the-operating-system for leisure...
About computerising parts of the existing body of proofs: there's a *lot* of lemma's formalized in the Mizar Math Library, all automatically checked. Browse it at:
http://www.mizar.org/JFM/
Systems that have problem (a) are indeed pretty useless from a math point of view.
However, most prooftools, like CoQ, HOL and Mizar (correct me if i'm wrong here) actually do produce an easily-checkable version of the proof. That makes (b) irrelevant: if a specific resulting proof is checked by the checker, it's OK, regardless of how it was generated.
Aim Here and jrumney are correct (and explain it nicely, thanks guys).
Retric and MO appear to be wrong or at least confusing/misleading here;).
Basically, if you want to distribute a product propriatarily, you should keep your hands off code that's released under the GPL, unless you own the copyright to that code yourself, in which case you can dual-license it under a different license.
> So it's useful. As far as I'm aware nobody's ever > done it before, which makes it both non-obvious > and novel. Those are the three tests of a patent.
Whoa, wait a minute. I agree it's useful (though the reason for choosing base 30 is indeed funny).
It is *not* novel or non-obvious. Anyone who has ever seen various forms of primitive compression, as well as most people with common sense, could easily have come up with this.
Patents are meant for the kind of really intelligent stuff that requires hard research work. This is not such an idea.
Even though it'd probably not hold up in court, the patent is enough to bully around small companies/individuals that can't affort the enormous financial risk of actually taking it to court....
If you'd had read the page, you'd know that one of the goals of the described approach is not to require administration at the server side.
And that's exactly what tinyurl and friends do: it's not compression, it's just a short-to-long-url-mapping that they keep on the server.
Whoa, wait a minute there. They indeed describe a nice way to encode lat/lon-numbers.
But it's totally trivial. Such a patent should not be granted imho. Anyone can come up with that. Patents were meant for `innovative ideas', `inventions'. For the complicated stuff that takes research.
In principle, in my opinion, patents are a good thing (though time has told we can live without them). They allow inventors (big companies, small companies and open-source groups alike) to publish their Really Innovative Inventions while having time to gain marketshare over copycats. Trivial ideas should not be patentable (and one of the problems is that we lack a sufficient way to determine what is `trivial').
Still, I'm against the Software Patents Directive as it's proposed now. That's because even though I think software patents are essentially good, in the current form they can be abused. I'll give some examples:
They run too long. IT is a fast market, the temporary monopoly should run out faster.
They can be used to intimidate those who are smaller. Patents would be too expensive if they were all tested beforehand, so the idea is to basically grant all patents, and in case of dispute decide whether it should have been granted in court. Basically, if you're small, going to court against one of the big boys might not be a chance you'd be willing or able to take, even when the patent was really invalid.
They can be used to `torpedo' big companies. Companies might turn up that patent ideas (or buy patents) that they carefully keep quiet until one of the big players also invents them and starts to depend on the techniques patented. Then they `emerge' and threathen to enforce the patent, at what stage the big company will be eager to pay large sums of money to be able to stay in business with the technique on which they have grown to depend.
Until problems like that are solved, I think no software patents are better than exploitable software patents.
Slashdot Mirror
Rust's type system provides protections against some problems that can be quite hard to debug in C.
Between having a programmer that is inexperienced in C writing C code and having a programmer inexperienced in Rust writing Rust code, arguably you might be better off with the latter.
This sounds like a reasonably small component, so what is the worst that could happen? That you would have to rewrite it some day? I'd say go for it.
Yep, the experiments described in http://www.ted.com/talks/marcus_byrne_the_dance_of_the_dung_beetle.html suggest dung beetles also use polarized light.
Really? I remember reading Magister has a respectable-but-far-from-monopolistic market share of 10%, and there seem to be various options available, including the web-based SOM (formerly Vocus, http://product.simaconderwijs.nl/Onze_producten/SOM ). Of course they'll differ in scope, but there certainly seems to be competition.
(full disclosure: i work for a sister-company of the company that develops SOM)
I concur exactly with your null/NPE observations. The next addition I want to the Java spec is the ability to mark a method as never returning null.
JSR 305 defines a set of annotations that allow you to do this (including '@NonNull' for method return values).
The weakness of this is that you can formally specify a method should never return 'null' with this, but the compiler does not check whether you live up to this promise. There are tools that can do some basic checks against blatant mistakes (Eclipse does this nowadays), and tools that are a bit more advanced and find even more subtle mistakes (FindBugs comes to mind).
Really proving correctness without a doubt is an unsolved problem - even when adding additional annotations it's a tough nut to crack - check out research projects like ESC/Java if you're interested in the gory details
.
Stallman wrote the Java trap, and we all laughed. Sun is nice we thought, it'll be ok. We were all wrong. Stallman saw further, he saw that even if Sun was ok, if someone bought Sun, then things could get messy. Welcome to messy.
Actually, most of the platform has been open-sourced by Sun before the takeover under the 'OpenJDK' name.
Indeed, GNU now carries a 'headnote' to the article explaining the new situation: http://www.gnu.org/philosophy/java-trap.html
The situation is still messy - but not for the original reasons laid out in that article. If worst came to worst, the JVM can be forked - but forking a widely-used platform is a whole other can of worms, of course.
Take a browse though http://ocw.mit.edu/OcwWeb/Electrical-Engineering-and-Computer-Science/index.htm There doesn't seem to be an 'overview' class like the one you're describing, but perhaps you could combine some of the introductions of the various courses.
The fact these devices are not simple mechanical aides, but complex, impossible-to-verify black-box computer systems is stressed.
> Actually, some webserver used their private key to host a phishing site. Who actually set up the private key, which web servers it was used on, and who used it on the phishing site are all orthogonol questions.
> That's like saying because a car with a certain license plate hit someone, the owner was the driver.
The car owner / website administrator(s) are the ones who can bring you one step closer to the culprit, though, if you're lucky.
>>it simply guarantees that no one will view the information en route
>For that, a self-signed certificate would be all you would need. The whole justification
>for CAs was to address the problem of verifying who you're talking to.
Err, no. If you see a self-signed certificate, you don't know whether it was signed by the website you're talking to, or by someone performing a man-in-the-middle attack.
The cert contains the fqdn of the website, and the CA should check that the owner of that website indeed holds the private key corresponding to the public key it signs.
Actually, something similar has been available at least since 2002: http://desk3d.sourceforge.net/
It's still cool of course, and it probably works much better with Xgl.
Indeed.
Also, this is probably a message to the world (and possibly judges at some point...) that BitTorrent is mainly targeted to users with legitimate goals. That it is not purely a tool for pirates.
As you wrote the software, you are THE person to turn for potential customers that like the software, but miss feature X.
Hopefully paying you to implement feature X will be cheaper for them compared to buying a commercial solution that already has X.
It might even be possible to provide some infrastructure so various companies together can raise funding for a feature X they mutually want.
Many of the games are win/Mac/Linux, but they sell something like 5% to linux users The rest being Win/Mac with lots of MAC sales - they buy. Apparently we (linux users) are a cheap bunch of mofos... We already knew Macs are for spendy people. As for that 5%, given that much less than 5% of gamers use Linux, I'd say that's a pretty good score. Then you might argue that there are many more games available for Windows, so you'd expect the few commercial linux games to sell better. Then I could state the number is that low due to lack of interest rather than being cheap mofo's. After all linux users tend to be serious guys that like to get work done, and play nethack or install-the-operating-system for leisure...
ok, but that's strictly optional, achieving much the same effect that is currently achieved by dual-licensing.
The 4-colour theorem really does hold for all possible maps, as parent correctly states.
About computerising parts of the existing body of proofs: there's a *lot* of lemma's formalized in the Mizar Math Library, all automatically checked. Browse it at: http://www.mizar.org/JFM/
Systems that have problem (a) are indeed pretty useless from a math point of view.
However, most prooftools, like CoQ, HOL and Mizar (correct me if i'm wrong here) actually do produce an easily-checkable version of the proof. That makes (b) irrelevant: if a specific resulting proof is checked by the checker, it's OK, regardless of how it was generated.
Aim Here and jrumney are correct (and explain it nicely, thanks guys). Retric and MO appear to be wrong or at least confusing/misleading here ;).
Basically, if you want to distribute a product propriatarily, you should keep your hands off code that's released under the GPL, unless you own the copyright to that code yourself, in which case you can dual-license it under a different license.
I'm no expert on the license used, but I can well imagine that the following is true:
Google can charge a fee for accessing their servers, no problem.
Google can *not* prevent users from (legally) saving and distributing the content they got access to by paying, even after their subscription ended.
> So it's useful. As far as I'm aware nobody's ever
> done it before, which makes it both non-obvious
> and novel. Those are the three tests of a patent.
Whoa, wait a minute. I agree it's useful (though the reason for choosing base 30 is indeed funny).
It is *not* novel or non-obvious. Anyone who has ever seen various forms of primitive compression, as well as most people with common sense, could easily have come up with this.
Patents are meant for the kind of really intelligent stuff that requires hard research work. This is not such an idea.
Even though it'd probably not hold up in court, the patent is enough to bully around small companies/individuals that can't affort the enormous financial risk of actually taking it to court....
If you'd had read the page, you'd know that one of the goals of the described approach is not to require administration at the server side. And that's exactly what tinyurl and friends do: it's not compression, it's just a short-to-long-url-mapping that they keep on the server.
Whoa, wait a minute there. They indeed describe a nice way to encode lat/lon-numbers.
But it's totally trivial. Such a patent should not be granted imho. Anyone can come up with that. Patents were meant for `innovative ideas', `inventions'. For the complicated stuff that takes research.
This is just a simple technique.
Still, I'm against the Software Patents Directive as it's proposed now. That's because even though I think software patents are essentially good, in the current form they can be abused. I'll give some examples:
- They run too long. IT is a fast market, the temporary monopoly should run out faster.
- They can be used to intimidate those who are smaller. Patents would be too expensive if they were all tested beforehand, so the idea is to basically grant all patents, and in case of dispute decide whether it should have been granted in court. Basically, if you're small, going to court against one of the big boys might not be a chance you'd be willing or able to take, even when the patent was really invalid.
- They can be used to `torpedo' big companies. Companies might turn up that patent ideas (or buy patents) that they carefully keep quiet until one of the big players also invents them and starts to depend on the techniques patented. Then they `emerge' and threathen to enforce the patent, at what stage the big company will be eager to pay large sums of money to be able to stay in business with the technique on which they have grown to depend.
Until problems like that are solved, I think no software patents are better than exploitable software patents.