True, but unless your project is very successful already, don't expect to get a job working on that project and don't expect the company that hires you to adopt it. Think of it as a portfolio: it's evidence of a category of work that you can do well. When a company interviews you, they're not trying to judge whether the project that you've worked on is useful to them, they're trying to judge whether working on that project (and other things) has given you skills that are useful to them.
It is hard. Producing a new creative work, be it a film, piece of software, book, or whatever, is hard and often expensive. Copying a creative work is cheap to the point that it's barely worth measuring the cost. Lots of influential companies have business models that revolve around doing the difficult thing for free and then charging for the easy thing to make up for it. They're eventually going to be displaced by companies that realise that it makes more sense to charge for the difficult thing - we're seeing this in software already, with open source companies giving away code that's already written for free and charging for writing new features or customisation (or, in some cases, entirely new programs).
In 100 years, people are going to look back on DRM and restrictive copyright in much the same way that we look back at the laws that required motor cars to have someone walk in front of them with a red flag. Regulations that can't possibly work in the long term, designed to prop up an industry that's suddenly found itself obsoleted by new technology.
Uh, yes? Because that's how you write code that handles errors correctly. Exceptions come from three sources:
Runtime exceptions. These don't need to be caught or declared by Java code, but you can generally avoid them by making sure you have null reference checks and using iterators for collections.
Exceptions that you throw yourself. You know you're throwing these and the odds are that you want the caller to handle them (if you're using exceptions for intraprocedural flow control, then you're an idiot). So advertise them on your method. Done.
Exceptions thrown by methods that you call. These are all advertised by those methods and checked by the compiler (or your IDE), so there's no excuse for not knowing that they're expected.
This stuff isn't hard. You know at every call site what the possible exceptions are, and you know this because the compiler won't let you explicitly throw or fail to handle any exceptions in your methods. The exceptions that a method can throw are in the JavaDoc and are checked at compile time, so you'll get a compile error if you don't either handle or advertise the exception.
Good error handling is one of the key things that differentiates good developers from bad. If it's something that you find hard, in a language that goes out of its way to make it easy, then you might want to consider other careers.
Most of the developing world just doesn't have this problem.
Actually that's not true. India and China did very well out of being a cheap place to manufacture things because of the low labour cost. Now, factories that are almost entirely automated are replacing those staffed by unskilled workers. This means that no one is building them in developing countries and creating jobs there. The only reason that companies like Foxconn have for picking places in Africa for manufacturing now is the the lack of environmental regulation: a few politicians get paid off, but the local economy doesn't benefit and the local environment gets polluted. The path Japan took, of cheaply copying things, being a cheap place to build factories, developing local skills, and then competing internationally with original products, doesn't exist anymore.
Exactly. Few workers would complain about automation if they owned a share in the company proportionate to their contribution to the profits. If a robot means that the company can produce more without their going to work then their income would go up and so would their leisure time. Instead, they become redundant in a shrinking job market and the owners get richer.
Java doesn't require you to catch every exception, it requires that, for every exception that cam be generated in a method, you must either catch it or advertise that your method can throw it. This makes static analysis and reasoning about exception much easier, because you know exactly what exceptions a particular method can throw. Handling exceptions at the wrong place is a problem with the programmers, not with the language or VM.
I recently moved from hand-written HTML for my personal site to Jekyll, which is the engine that powers GitHub pages. It does exactly what I want from a CMS:
Cleanly separate content and presentation.
Provide easy-to-edit templates.
Allows all of the content to be stored in a VCS.
Generates entirely static content, so none of its code is in the TCB for the site.
The one thing that it doesn't provide is a comment system, but I'd be quite happy for that to be provided by a separate package if I need one. In particular, it means that even if the comment system is hacked, it won't have access to the source for the site so it's easy to restore.
How is your LAN secured? If it's wired, then I assume that you know about ARP poisoning attacks. If it's wireless, then I assume that your post was intended as a joke.
That's the best way of securing a connection, but it doesn't scale. You need some out-of-band mechanism for distributing the certificate hash. It's trivial for your own site if you're the only user (but even then, the right thing for the browser to do is warn the first time it sees the cert), but it's much harder if you have even a dozen or so clients.
The 'brought to you by' box on that site lists Mozilla, Akamai, Cisco, EFF, and IdenTrust. I don't see Google pushing it. They're not listed as a sponsor.
That said, it is pushing Certificate Transparency, which is something that is largely led by Ben Laurie at Google and is a very good idea (it aims to use a distributed Merkel Tree to let you track what certificates other people are seeing for a site and what certs are offered for a site, so that servers can tell if someone is issuing bad certs and clients can see if they're the only one getting a different cert).
It depends on your adversary model. Encryption without authentication is good protection against passive adversaries, no protection against active adversaries. If someone can get traffic logs, or sits on the same network as you and gets your packets broadcast, then encryption protects you. If they're in control of one of your routers and are willing to modify traffic, then it doesn't.
The thing that's changed recently is that the global passive adversary has been shown to really exist. Various intelligence agencies really are scooping up all traffic and scanning it. Even a self-signed cert makes this hard, because the overhead of sitting in the middle of every SSL negotiation and doing a separate negotiation with the client and server is huge, especially as you can't tell which clients are using certificate pinning and so will spot it.
Every HTTP request I send to Slashdot contains my cookie, which contains my login credentials. When I do this over a public WiFi network, it's trivial for any passive member of the network to sniff it, as it is for any intermediary. Worse, because it uses AJAX stuff in the background, if I briefly connect to a malicious access point by accident, there's a good chance that it will immediately send that AP's proxy my credentials. I've been using this account for a decade or so. I don't want some random person to be able to hijack it so trivially.
Given hoe poorly most people secure their WiFi, having a warning if you're using a DVR on a LAN and it doesn't support end-to-end encryption sounds like a good plan to me. Of course, this raises an interesting question about built-in obsolescence, given that certificates have a valid-until date.
You're right, but it's not always the devices within the same product category. A lot of stuff that's in consumer devices begins life in very niche applications (e.g. military or medical devices) to get the first bit of R&D funding and then needs another big chunk to become cheap enough for consumer devices.
It's not clear that Apple could survive in isolation. A lot of their components are only as cheap as they are because of other lower-margin companies paying a big chunk of the R&D costs. When Apple was using PowerPC processors and were the only customer for IBM or Motorola for a particular chip, they found it very difficult to compete. They're designing their own ARM cores now, but they're benefitting enormously from the thriving ARM software ecosystem.
Several years ago I ordered the CD collection of Small C articles, and found it pretty useful for grasping the essentials of compiler design. Even if the information is decades old, it was still relevant for the fundamentals of how C compiling and linking works. (at least on Unix/Linux, which is based on decades old designs)
The overall compile-link step is roughly the same (although LTO changes it a bit), but the compilation process has changed hugely in the last 20 years. Dealing with code 'hand optimised' by people who still have a mental model of how PCC compiles code is a constant source of pain.
Why would they do that? If you're a cosmetics company and you can buy a startup that owns the patents on a technique that actually works, then you'd be stupid to keep competing on a level playing field when you could be the only company that's selling the real thing. Even if you multiply your normal profit margin by a factor of ten, you're still going to be selling huge quantities and raking in the money.
The problem with these conspiracy theories is that they assume that people with large entrenched interests and lots of money somehow have an aversion to turning their big pile of money into an enormous pile of money.
Then you're probably not going into an establishment where the only drinkable beverages are laced with sugar and milk to disguise how bad the coffee is.
Theres a few small upstarts arround too but they tend to have negligable coverage areas.
BT is required to allow third parties to install equipment in the exchanges ('local loop unbundling'), and while most of the companies that take advantage of this are small local affairs, TalkTalk has quite a lot of coverage on LLU exchanges. Since BT won't sell naked ADSL lines, they've priced themselves completely out of the market in areas with Virgin Media coverage.
Well, sort of. Clause 7 could be interpreted as a patent license, in that if you knowingly distribute code that violates your patents then you are violating the license if you don't also include a patent grant. In v3 it's more explicit precisely because it was ambiguous in v2. It's up to the court to decide whether this ambiguous license is a license.
Pris was made years ago for off-world use. Rachel is a recent creation to serve as a test subject / surrogate daughter
In the book, Pris and Rachel are the same model and identical. Rachel seduces Deckard so that he will have an emotional reaction to Pris, which will slow him down. In the film, she seduces him because the film wanted some implication of sex at that point.
In the book, there's a lot of ambiguity about whether Decard is human, but only in his mind. There's also another bounty hunter who fails the empathy test when asked about androids, but passes it when asked about humans. The 'electric sheep' line from the title is a reference to the fact that, after almost destroying themselves in a nuclear war, humans are expected to keep pets to demonstrate their empathy and it's been engrained in the survivors as the most important character trait, yet the manipulate their emotions with mood organs and via shared religious experiences. Most of the subtext was lost in the movie (fortunately, so was the weird subplot about the police precinct populated entirely by androids, who believed that they were humans hunting androids).
The problem is that they don't differentiate categories well. Having bought some kind of computer thing means that I might be interested in buying some kind of computer thing again, but having bought one hard drive probably doesn't mean that I want another very similar (but not identical) one soon. In books, it's very different - if I've bought one novel then I probably want to buy another very similar (but not identical) one next time I shop. The same is true for a lot of things on Amazon - DVDs, CDs, and even clothes - and so the algorithm works pretty well overall, it just fails laughably in some cases (ah, you've bought a USB flash drive, do you want to buy a different USB flash drive with the same capacity?).
Slashdot Mirror
True, but unless your project is very successful already, don't expect to get a job working on that project and don't expect the company that hires you to adopt it. Think of it as a portfolio: it's evidence of a category of work that you can do well. When a company interviews you, they're not trying to judge whether the project that you've worked on is useful to them, they're trying to judge whether working on that project (and other things) has given you skills that are useful to them.
It is hard. Producing a new creative work, be it a film, piece of software, book, or whatever, is hard and often expensive. Copying a creative work is cheap to the point that it's barely worth measuring the cost. Lots of influential companies have business models that revolve around doing the difficult thing for free and then charging for the easy thing to make up for it. They're eventually going to be displaced by companies that realise that it makes more sense to charge for the difficult thing - we're seeing this in software already, with open source companies giving away code that's already written for free and charging for writing new features or customisation (or, in some cases, entirely new programs).
In 100 years, people are going to look back on DRM and restrictive copyright in much the same way that we look back at the laws that required motor cars to have someone walk in front of them with a red flag. Regulations that can't possibly work in the long term, designed to prop up an industry that's suddenly found itself obsoleted by new technology.
This stuff isn't hard. You know at every call site what the possible exceptions are, and you know this because the compiler won't let you explicitly throw or fail to handle any exceptions in your methods. The exceptions that a method can throw are in the JavaDoc and are checked at compile time, so you'll get a compile error if you don't either handle or advertise the exception.
Good error handling is one of the key things that differentiates good developers from bad. If it's something that you find hard, in a language that goes out of its way to make it easy, then you might want to consider other careers.
Most of the developing world just doesn't have this problem.
Actually that's not true. India and China did very well out of being a cheap place to manufacture things because of the low labour cost. Now, factories that are almost entirely automated are replacing those staffed by unskilled workers. This means that no one is building them in developing countries and creating jobs there. The only reason that companies like Foxconn have for picking places in Africa for manufacturing now is the the lack of environmental regulation: a few politicians get paid off, but the local economy doesn't benefit and the local environment gets polluted. The path Japan took, of cheaply copying things, being a cheap place to build factories, developing local skills, and then competing internationally with original products, doesn't exist anymore.
Exactly. Few workers would complain about automation if they owned a share in the company proportionate to their contribution to the profits. If a robot means that the company can produce more without their going to work then their income would go up and so would their leisure time. Instead, they become redundant in a shrinking job market and the owners get richer.
Java doesn't require you to catch every exception, it requires that, for every exception that cam be generated in a method, you must either catch it or advertise that your method can throw it. This makes static analysis and reasoning about exception much easier, because you know exactly what exceptions a particular method can throw. Handling exceptions at the wrong place is a problem with the programmers, not with the language or VM.
The one thing that it doesn't provide is a comment system, but I'd be quite happy for that to be provided by a separate package if I need one. In particular, it means that even if the comment system is hacked, it won't have access to the source for the site so it's easy to restore.
How is your LAN secured? If it's wired, then I assume that you know about ARP poisoning attacks. If it's wireless, then I assume that your post was intended as a joke.
That's the best way of securing a connection, but it doesn't scale. You need some out-of-band mechanism for distributing the certificate hash. It's trivial for your own site if you're the only user (but even then, the right thing for the browser to do is warn the first time it sees the cert), but it's much harder if you have even a dozen or so clients.
The 'brought to you by' box on that site lists Mozilla, Akamai, Cisco, EFF, and IdenTrust. I don't see Google pushing it. They're not listed as a sponsor.
That said, it is pushing Certificate Transparency, which is something that is largely led by Ben Laurie at Google and is a very good idea (it aims to use a distributed Merkel Tree to let you track what certificates other people are seeing for a site and what certs are offered for a site, so that servers can tell if someone is issuing bad certs and clients can see if they're the only one getting a different cert).
It depends on your adversary model. Encryption without authentication is good protection against passive adversaries, no protection against active adversaries. If someone can get traffic logs, or sits on the same network as you and gets your packets broadcast, then encryption protects you. If they're in control of one of your routers and are willing to modify traffic, then it doesn't.
The thing that's changed recently is that the global passive adversary has been shown to really exist. Various intelligence agencies really are scooping up all traffic and scanning it. Even a self-signed cert makes this hard, because the overhead of sitting in the middle of every SSL negotiation and doing a separate negotiation with the client and server is huge, especially as you can't tell which clients are using certificate pinning and so will spot it.
Every HTTP request I send to Slashdot contains my cookie, which contains my login credentials. When I do this over a public WiFi network, it's trivial for any passive member of the network to sniff it, as it is for any intermediary. Worse, because it uses AJAX stuff in the background, if I briefly connect to a malicious access point by accident, there's a good chance that it will immediately send that AP's proxy my credentials. I've been using this account for a decade or so. I don't want some random person to be able to hijack it so trivially.
Given hoe poorly most people secure their WiFi, having a warning if you're using a DVR on a LAN and it doesn't support end-to-end encryption sounds like a good plan to me. Of course, this raises an interesting question about built-in obsolescence, given that certificates have a valid-until date.
You're right, but it's not always the devices within the same product category. A lot of stuff that's in consumer devices begins life in very niche applications (e.g. military or medical devices) to get the first bit of R&D funding and then needs another big chunk to become cheap enough for consumer devices.
You misunderstand. It might not be free for you, but it's free for the fish...
It's not clear that Apple could survive in isolation. A lot of their components are only as cheap as they are because of other lower-margin companies paying a big chunk of the R&D costs. When Apple was using PowerPC processors and were the only customer for IBM or Motorola for a particular chip, they found it very difficult to compete. They're designing their own ARM cores now, but they're benefitting enormously from the thriving ARM software ecosystem.
The problem is that the costs outweigh the revenue. Reducing costs in a way that also reduces revenue is probably not a good solution.
Several years ago I ordered the CD collection of Small C articles, and found it pretty useful for grasping the essentials of compiler design. Even if the information is decades old, it was still relevant for the fundamentals of how C compiling and linking works. (at least on Unix/Linux, which is based on decades old designs)
The overall compile-link step is roughly the same (although LTO changes it a bit), but the compilation process has changed hugely in the last 20 years. Dealing with code 'hand optimised' by people who still have a mental model of how PCC compiles code is a constant source of pain.
Why would they do that? If you're a cosmetics company and you can buy a startup that owns the patents on a technique that actually works, then you'd be stupid to keep competing on a level playing field when you could be the only company that's selling the real thing. Even if you multiply your normal profit margin by a factor of ten, you're still going to be selling huge quantities and raking in the money.
The problem with these conspiracy theories is that they assume that people with large entrenched interests and lots of money somehow have an aversion to turning their big pile of money into an enormous pile of money.
Then you're probably not going into an establishment where the only drinkable beverages are laced with sugar and milk to disguise how bad the coffee is.
Theres a few small upstarts arround too but they tend to have negligable coverage areas.
BT is required to allow third parties to install equipment in the exchanges ('local loop unbundling'), and while most of the companies that take advantage of this are small local affairs, TalkTalk has quite a lot of coverage on LLU exchanges. Since BT won't sell naked ADSL lines, they've priced themselves completely out of the market in areas with Virgin Media coverage.
Well, sort of. Clause 7 could be interpreted as a patent license, in that if you knowingly distribute code that violates your patents then you are violating the license if you don't also include a patent grant. In v3 it's more explicit precisely because it was ambiguous in v2. It's up to the court to decide whether this ambiguous license is a license.
Pris was made years ago for off-world use. Rachel is a recent creation to serve as a test subject / surrogate daughter
In the book, Pris and Rachel are the same model and identical. Rachel seduces Deckard so that he will have an emotional reaction to Pris, which will slow him down. In the film, she seduces him because the film wanted some implication of sex at that point.
In the book, there's a lot of ambiguity about whether Decard is human, but only in his mind. There's also another bounty hunter who fails the empathy test when asked about androids, but passes it when asked about humans. The 'electric sheep' line from the title is a reference to the fact that, after almost destroying themselves in a nuclear war, humans are expected to keep pets to demonstrate their empathy and it's been engrained in the survivors as the most important character trait, yet the manipulate their emotions with mood organs and via shared religious experiences. Most of the subtext was lost in the movie (fortunately, so was the weird subplot about the police precinct populated entirely by androids, who believed that they were humans hunting androids).
The problem is that they don't differentiate categories well. Having bought some kind of computer thing means that I might be interested in buying some kind of computer thing again, but having bought one hard drive probably doesn't mean that I want another very similar (but not identical) one soon. In books, it's very different - if I've bought one novel then I probably want to buy another very similar (but not identical) one next time I shop. The same is true for a lot of things on Amazon - DVDs, CDs, and even clothes - and so the algorithm works pretty well overall, it just fails laughably in some cases (ah, you've bought a USB flash drive, do you want to buy a different USB flash drive with the same capacity?).