Maybe no software is perfect, but some bits of software are a lot closer to perfect than others.
Much of this comes down to choice of tools. For example, if you're writing security-sensitive software in something like C or C++ in 2012 and the software in question isn't something very low-level like an OS kernel, you're probably making a mistake as far as security goes. The fact that much of the industry makes this mistake doesn't negate the preceding statement, it just means much of the industry is choosing to allow commercial pressures to override technical merit.
Much of it also comes down to choice of processes. We know very well how to write highly reliable software. Even for cases where ultra-high reliability isn't required, we know of relatively easy changes to processes that can reduce bug rates by almost an order of magnitude over the industry norm. If you're writing security-sensitive software in 2012 and not using these processes, you're also probably making a mistake as far as security goes. The fact that much of the industry makes this mistake doesn't negate the preceding statement, it just means that much of the industry is choosing to prioritise letting developers concentrate on the fun stuff over improving the quality of the work done by those developers.
The trouble is, a lot of systems now use web-based interfaces internally,whether that's accessing data over your corporate intranet or controlling a networked device via a UI running on an embedded web server. These systems aren't necessarily constantly maintained and developed in the way that large-scale web sites are. They should be more akin to traditional software development, where once something is finished and does the job, it doesn't necessarily need ongoing effort just to keep it working, and the people who worked on it are available to work on new projects.
Of course it is Mozilla's responsibility not to break the platform that this sort of system is built on, but sometimes they do it anyway. And when your multi-million-dollar customer calls your platinum support number at 4am because their mission critical system just died, you aren't going to win any prizes by telling them that it's their fault for using Firefox or arguing that their IT group should somehow be checking all their in-house web interfaces still work every six weeks before allowing each new version of the browser to roll out across their company network.
If your only answers to this sort of situation are "use another browser" or "educate your users", then you are ignoring the reality for many projects that these simply aren't acceptable responses in the eyes of management/customers. Often, the only choices you have might be reassigning people to hack some sort of workaround into the previously working system Right Now or losing a lot of money and/or good will to make up for a critical system failing.
Right, because things like Flash and Java applets aren't Real Web Technologies and anyone who uses them must just be some dumb amateur relying on "crufty, legacy proprietary features".
Technologies like these got badly broken when Firefox 10 -- the nominated extended support release -- was pushed out. They actually had the bug in their tracker several days before the release, but went ahead with it anyway, with the result that vast numbers of web sites were then broken for several more days before they pushed out a fix.
That was the clearest demonstration yet that Mozilla simply can't cope with the absurd release schedule but will prioritise hitting their arbitrary targets over product quality when something has to give. For a security-sensitive piece of software used by millions of people, that is downright irresponsible.
(Anyone who is about to smugly reply that Chrome does a better job so we should all switch to that will deserve anything they get, BTW.)
There was also a lot of high-profile political publicity around the time that things like the five year penalty for firearm possession came in.
If judges are allowed to override these minimum sentences, I have never seen any reference to it, nor can I find one searching now. I'm not a lawyer, so maybe I'm not aware of some technicality or procedural detail you are, but you're going to need to cite some clear authority to convince me.
I lost a boot drive for a workstation recently, and with it the activation for some very expensive professional software products.
More than one vendor subsequently refused to let me reactivate the software (the same legitimate copy of the same software on the same machine except with a fresh OS installation on a new drive) because they had records showing that my software key was registered to someone else, sometimes not even in the same country. Eventually, after multi-week hassle and in some cases literally sending photos of the boxed package with serial numbers etc. and the original sales invoice, everything was working again.
It's not as if they even apologised for messing me around entirely because of their own over-zealous copy protection and poor record keeping/registration checking, and certainly no form of compensation was offered for the downtime. And yet, the disruption and direct loss income from that downtime because I work from home was surely at least as bad as having someone break into the workstation and install some sort of malware, which I could at least have fixed within a day by nuking and reinstalling everything, but which would have been a criminal offence on their part.
I want the people who were directly responsible for authorising and operating those copy protection schemes to be personally and criminally liable, the same way they would be if they had cracked my network and remotely wiped the software. I understand why companies want to copy protect their code, but there's no way a mini-company like mine can afford to sue a global corporation to recover a week's lost income, so there needs to be some other form of deterrent. Locking up the guy who types my serial number into the remote-deactivation script would be a good start, I think, and a hell of a lot more justifiable than any nebulous law that covers obviously inadvertent access, "hacking" tools with legitimate uses for sysadmins/software developers, etc.
Silly categorical minimum sentences are pretty much an alien concept here.
That depends where "here" is. In the UK, we have seen all kinds of minimum sentences for possession of various prohibited items over the years, not to mention the policy of compulsory life sentences for murder.
Please don't get hung up on the specific example I gave. It was only an example of a more general point: because we now have much easier abilities to store, search and corrolate large numbers of small facts, and to make the results widely and instantly available with little cost, allowing the collection of any small fact about an individual may contribute to a much more severe loss of privacy than it ever could before those technologies existed.
Street View is just one case, in that for example if I know your address there is now a good chance I can quickly and anonymously find out your vehicle and registration details, because that outdoor photography has been systematically collected, is now searchable on-line, and is now available to the entire world.
The issue of recorded and searchable data is far broader, though. Consider that if one person is standing next to you while you pay in a shop, they probably aren't going to rob you later. Even if they happen to glance in your direction as you type the PIN to authorise a card payment, they probably can't see your card number or the security digits on the back. On the other hand, someone standing there with a video recording device requires only that in handling your card you momentarily expose both sides of it to reveal the numbers required to make an on-line payment. Someone who could follow you around with a recording device could probably collect many other relevant details for security checks based on address and the like as well.
That only sounds far-fetched because the effort for someone to do this when they have to be physically present for an extended period of time is prohibitive and the risk of being detected is quite high. There is a natural limit that contains the damage any one rogue individual can cause in both scale and number of victims.
On the other hand, today we have public safety CCTV cameras watching you as you go around the city. Here in the UK, we have a scary number of CCTV cameras watching you just about any other time these days, too, with very little regulation of how the footage is stored or used. We have increasingly accurate image processing software for things like facial recognition and OCR, so a momentary disclosure recorded in public can then be processed at length in private later. Payments are being made increasingly using cards that are inherently traceable and with no physical presence required to deter fraud, and as was widely reported a few days ago, shops data mining this sort of information can now predict very personal matters like pregnancy more accurately than family members and close friends. Obviously unless you're going around buying pregnancy testing kits, no-one observing a single purchase in a store could do that. To make life even easier for would-be fraudsters, millions of kids have even helpfully told Facebook the once-personal information that banks are going to use to identify them via security questions when they grow up: mother's maiden name, first pet, first school, and so on.
The sheer volume of information about you that is out there today and available to mine is staggering. Anyone able to obtain and corrolate even a tiny fraction of it could be a threat to you through obvious things like identity theft or even physical actions like robbery or kidnapping, and through more subtle things like red flagging your job application or bumping up your insurance premium because you hung around with people who are known to engage in "inappropriate activities". And in practice they would be almost unstoppable and unaccountable for doing these latter things, even if they resulted in discrimination that would otherwise be illegal or at least generally considered unethical, because how will you ever know you're being screwed that way to do anything about it? Of course there is also the whole creepy advertising thing, but that's hardly even on the scale as far as the consequences of lost privacy go IMHO.
None of this was possible before the era of the Internet and the mass surveillance da
The problem with your argument is that you are making the classic mistake of thinking that ANY of these things are new issues.
I would argue exactly the opposite: the changes enabled by modern technology mean we have not just a quantitative but a qualitative difference in the impact of small but no-longer-isolated observations. This does raise new fundamentally questions about what practical actions are consistent with any given moral position on privacy.
And how is this different from take a public picture of somebody, then putting it on the cover of a national magazine? See, we already had rules about that, and they cover situations like this just fine.
For one thing, not everywhere has the same rules about that. Please don't project your local legal system onto the rest of the world. Of all things, privacy is surely one of the most variable between jurisdictions in terms of legal protections.
For another thing, I think there is again a qualitative difference between appearing on a magazine cover, which is a relatively rare event and is by its nature a very public observation usually made by well-established professional media organisations, and the kind of back office data-mining operations that let anonymous observers look up all kinds of information about all kinds of subjects without the subjects even knowing.
There really isn't anything new here, and if you think there is, then you don't know your history very well.
Perhaps, but at least I understand that copyright and privacy have absolutely nothing to do with each other, aside from both being in conflict with absolute freedom of expression. It is strange that someone so keen to appeal to century-old court decisions apparently does not...
No, I haven't, at least not live. But that's not really the point, because the dubious thing here isn't the Street View car itself, it's the fact that the Street View system lets other people see things without ever physically being present at all.
The rules don't need to be re-written. The old ones work just fine as long as we don't throw out all reason as soon as "on a computer" is added.
The thing is, the old ones don't work just fine. If you pause to consider why privacy matters, the implications of actions that might have been seen as acceptable or a minor social faux pas twenty years ago could be profound today, and it is the implications that we really care about, not the actions themselves.
For example, consider Google's Street View project. When the privacy debate around their data collection flared up, some people defended them on the grounds that the cars were only driving down the street and photographing things any passer-by could see from a public place. Leaving aside the fact that this turned out not to be true, there are still many practical differences between the two scenarios.
For one thing, the individual in the street can themselves be seen. Being in a public place is a two-way deal, and if you're going around peering in through people's windows, you're going to attract unwelcome attention.
Even if you do, your presence is temporary. What you see isn't being recorded for all time, and certainly not in a searchable form or a way that can easily be corrolated with many other data sources.
Anything seen is seen by one private individual, not a vasty corporation with potentially a global audience.
Even if we accept as reasonable an individual taking a photograph in a public place that potentially diminishes someone else's privacy, perhaps because the latter person wasn't the subject of the photo and appeared in the background only coincidentally, such photos are still typically only for private, personal use, not being collected by a commercial entity that exists only to exploit anything it can for profit.
And finally, building on that idea of corrolating data from different sources, we get the kicker: one individual walking down the street can only see as much as, well, one individual walking down the street. This fundamentally and naturally limits the implications of anything they might see or do, even if their actions are unpleasant. Google, on the other hand, have vast resources and were conducting systematic surveillance on a national and even international scale.
Many of these distinctions also apply in other controversial privacy cases today, even those that aren't based on direct physical observation: mass surveillance by the state, for example, or the kind of insidious data mining operations going on at places like Facebook.
In short, privacy today needs to take into account not just the scale of any one "invasion", but the cumulative effect of all "invasions". In a world where the Internet provides quick and easy communication of any information from anyone to everyone, where some organisations have resources so vast that they didn't realise downloading that Internet was meant to be a joke, and where data storage and mining capabilities allow the co-ordination and interpretation of thousands of data points about any given individual in an instant, that means minor invasions are a much bigger deal than they used to be.
There is no reason we should tolerate this, and arguing the inevitability of technological progress is a weak straw man. Technology is neutral, and it's how we choose to use it that matters. After all, the technology has long existed for someone to kill you before you even heard the shot, yet we don't see an epidemic of sniper murders, because murder is wrong and (almost) everyone accepts that. For those whose values are incompatible with that societal norm, there are rules and penalties to act as a further deterrent. The same goes for any crime; absolute prevention is very rarely possible, but between the moral standards of the general population and imposing laws on disproportionately powerful entities like governments and megacorps we keep unwelcome behaviour in check.
For what it's worth, I completely agree with you about that part. (I'm also not saying I think the larger question has a clear answer, either way.)
However, at the time I posted, I hadn't yet seen a single comment in the thread that limited any objection to that obviously unreasonable element, nor that even admitted the possibility that the basic question might have any merit.
Would it be too obvious to point out that in many places there is a watershed time in the evening, and anything shown on TV before that time is typically not allowed to include "grown up" content at all?
It's fascinating that in the first dozen or so posts I've read here, I see plenty of mockery and obvious jokes, but not a single person who has allowed that there may be even an element of truth to be found here.
Is this the same new iPad where there was a photo story of some guys who make tools for geeks demonstrating their gear by systematically taking one apart, all on-line within about ten seconds of the product launch?
There even seem to be references to this in TFA...
Now, now, be fair. They introduced a congestion charge in order to alleviate overcrowding on London's roads, and it has been highly effective and surely worth every penny that motorists have been charged! Anyone who claims it just moved some peak traffic to different roads or slightly different times of day is clearly deluded, and anyone who says it barely made a difference and the roads have long since gone back to being at least as crowded as before clearly isn't taking into account that they can now reach speeds of up to 12mph in the 50m gap between traffic lights, a full 20% improvement on the figure you quoted. Frankly, I think you're just being absurd and more than a little harsh on the national treasure that is London transport infrastructure.
Modern engineering can do some quite remarkable things, but for what it's worth, I think you've misunderstood the scale of the tunnels involved here by about an order of magnitude.
97% of services run to schedule, which isn't too bad.
It's not great, though. With more than a billion passenger journeys taken on the Underground per year, that 97% still represents more than 30 million significantly disrupted journeys, or if you prefer, regular commuters being late to work (or late home) once or twice every month.
Of course, there is only so much even the most hard-working staff could do with the limited resources available, and there is only so much money that can be available without putting fares (or taxpayer subsidy) up to politically intolerable levels.
In fairness, there are genuine improvements coming down the line. (Sorry...) These are at least partly driven by a desire not to look like idiots when a few million extra people are around for the Olympics later this year.
New trains with air-conditioning and a walk-through design, as used in underground networks such as those in Paris and Rome, have been rolling out for a year or so. They are replacing one line at a time and due to cover 40% of the network by 2015.
Also, a deal was announced just last week for Virgin Media to provide WiFi access on the London Underground during the 2012 Olympics, though it only covers station areas and not the trains themselves while they are in the tunnels. Its stated goal is to allow travellers to respond more quickly to disruption and avoid the busiest areas (which are almost certainly going to be flooded far beyond capacity at peak times during the Olympics, whatever happens).
The system is still nowhere near the level of, for example, the other European capitals I mentioned, though, and won't get there any time soon.
That makes sense too. It's not that low-level optimisation isn't important any more -- on the contrary, as we increasingly rely on stacked architectures and intermediate steps like virtual machine bytecode, it's probably more important than ever -- I just think we need to change long-standing assumptions about who does it. I think we're both saying the same thing in the end: dealing with assembly-level optimisation is no longer a task that makes sense for most programmers, and is best left to specialists. My default "specialist" in this case is someone working on the compiler tool chain, but your idea of allowing pluggable optimisers creates a related role with similar requirements.
It turns out that developer productivity is actually more important than almost anything.
Developer productivity might be more noticeable than almost anything. However, I shudder to think how much safer and more productive the world would be, and what impressive things we might be doing with the computing power available to us today, if we hadn't trained the general population to believe that slow, bug-ridden, insecure, barely usable software is somehow acceptable or even unavoidable.
These things each contribute a staggering drain on the global economy and the quality of human life. They just aren't as visible as a product that ships late or is missing a feature, because it's accepted as the norm that we wait half a minute each time our software loads a document, or we go and make a coffee while today's security patches are installed and the system reboots, or no-one really understands how to use $FEATURE in our business software anyway so we'll just file a support ticket and get back to it later, or the network is down this morning while MIS contain a virus outbreak (caused because Bob the CEO was too important to to read the IT policy and didn't know how to secure his laptop wireless connection anyway, which let someone install a backdoor, which in turn was exploited when dear old Susan in Accounts brought in the baby photos of her grandkids plus a bonus virus on a USB stick).
It isn't even clear that doing better would cost much more in either developer time or money. It would, however, require a change in mindset, a demand for higher standards, and much better training, collaboration and support for developers, across the whole industry or at least enough of it to act as a catalyst. Unfortunately, a lot of people don't like change, particularly change that requires questioning ideas they've taken for granted for a long time and acknowledging that they might have been doing a bad job as a result of those ideas. Also, the people most qualified to inspire and set a good example are probably too busy doing real work in niches where their skills and experience are genuinely valued, leaving the mainstream to soak up consultant-driven "best practices" that have an engineering foundation roughly comparable to an inch of sand under a skyscraper.
So, I think it turns out that developer productivity is more visible than almost anything. The jury is very much still out on whether it's more important.
It does depend a lot on context. The examples you gave are very simple, and avoid any of the awkward areas.
Consider a different example: calling a C library function that takes an enumeration type for one of its parameters.
Typically, in C, you will have a file something.h that contains the interface for a library, including things like function prototypes and enumeration definitions.
Unfortunately, this is all symbolic metadata that Python ctypes can't just read out of a shared object file. There is no handy way to have Python import all the enumerators from the header file and define them as symbolic constants, for example, or for Python to scan the header for function prototypes. Thus in practice we end up with things like ctypes argtypes and restype hassles, and with some sort of duplication of all the enumerators in Python code that then has to be maintained perfectly in sync with the underlying C interface.
What's more, Python doesn't have a concept of enumerations as such; PEP 354 was rejected. That means the best you're going to do is define a whole bunch of named constants for the enumerators in Python, and have your argtypes indicate the corresponding underlying integer type. Oh, but then the underlying type of an enumeration varies depending on the enumerators themselves, so now the effective prototype of every function that uses your enum as a parameter or return value, and thus the corresponding Python ctypes argtypes and restype data, has to change just because someone added the wrong value to an enumeration.
In short, Python/ctypes and C/enumerations are not a very happy mix. There are other techniques, as you mentioned, and tools for helping with automatic parsing of header files, and each approach has its own pros and cons. But there are plenty of cases where the overhead of calling from Python down to C code is unpleasant at best. As you can see from the Cython example you linked to, it's delusional to pretend that you can really just compile almost-unchanged Python code down to C, too. It doesn't take much of this hassle before you've lost most of the productivity benefit from writing in a higher-level language like Python, and you start thinking about writing a much wider chunk of your project in C just so you can move the Python-C bridge to a place in your architecture where the interface can be much simpler.
This isn't to say that I disagree with writing high-level code in Python and calling down to C in specific cases. Sometimes it really does work almost transparently. Most of the time it's not too bad, and if each language is much better for the kind of code you want to write in it (as IME it often will be) then the overheads in both developer time and run-time performance are a modest price to pay. But it's not always as easy as the introductory examples might suggest.
I completely agree with you. However, I think the long-term solution to that problem is to use higher-level programming languages that can express more advanced concepts explicitly, so the compiler can make more of the kinds of assumptions you're talking about. Training every programmer who wants to produce fast output code in the intricacies of modern process/memory architectures is not a viable long-term proposition; most programmers have other things to worry about. However, all programmers ultimately write their code in some language, so designing better languages and letting a few specialist programmers worry about implementing them is much more realistic.
Sorry, but I think your information is at least 5-10 years out of date.
Code generators in compilers obviously aren't perfect, and there are plenty of optimizations they don't do as well as they theoretically could yet. Still, compilers have been using the kinds of technique you describe for years now, even on some specialist chips used for embedding. I doubt many programmers, even those who work in the embedded space, have the skill to consistently outperform a compiler these days.
Very rarely, though. On modern architectures, writing high performance assembly language requires a deep knowledge of how everything fits together. Compiler writers spend a lot of time becoming experts in this field, and a lot more time becoming experts in applying optimisations at different levels of abstraction within an entire codebase during the different stages of compilation/optimisation. Consequently most non-specialist programmers, even those who have done plenty of assembly work in their time, would produce slower final code today by hand-crafting their own assembly language than they would by writing in C and trusting a good compiler to take care of the code generation.
So another law telling them not to get distracted by a specific thing isn't going to do jack squat.
It's not telling them not to get distracted. It's telling them not to use a phone. It's a very clear, very unambiguous requirement, and those violating it can be objectively penalised.
If it is in fact more or less equally dangerous for everyone, why are police exempted? The only conclusion is that we don't care if police officers are getting distracted, or maybe, just maybe, not everyone really is prone to distraction by using a cellphone.
There have been tragic consequences to police officers being distracted while using their phones/radios and driving. Sadly, they are not immune at all to the negative effects. The better trained ones may be starting from a higher standard than the average driver, but they are still impaired to well below their usual standard while on the radio.
The difference, and the reason that most countries tolerate members of the emergency services using the radio while driving even if others are prohibited from doing so, is that in an emergency situation there is an upside to allowing them to use radios on the move that may save more lives than it costs.
Also, in case you didn't know, it's common practice in some countries for traffic police officers to work in pairs with the non-driving officer doing all the radio work/commentary for precisely this reason.
Slashdot Mirror
Maybe no software is perfect, but some bits of software are a lot closer to perfect than others.
Much of this comes down to choice of tools. For example, if you're writing security-sensitive software in something like C or C++ in 2012 and the software in question isn't something very low-level like an OS kernel, you're probably making a mistake as far as security goes. The fact that much of the industry makes this mistake doesn't negate the preceding statement, it just means much of the industry is choosing to allow commercial pressures to override technical merit.
Much of it also comes down to choice of processes. We know very well how to write highly reliable software. Even for cases where ultra-high reliability isn't required, we know of relatively easy changes to processes that can reduce bug rates by almost an order of magnitude over the industry norm. If you're writing security-sensitive software in 2012 and not using these processes, you're also probably making a mistake as far as security goes. The fact that much of the industry makes this mistake doesn't negate the preceding statement, it just means that much of the industry is choosing to prioritise letting developers concentrate on the fun stuff over improving the quality of the work done by those developers.
The trouble is, a lot of systems now use web-based interfaces internally,whether that's accessing data over your corporate intranet or controlling a networked device via a UI running on an embedded web server. These systems aren't necessarily constantly maintained and developed in the way that large-scale web sites are. They should be more akin to traditional software development, where once something is finished and does the job, it doesn't necessarily need ongoing effort just to keep it working, and the people who worked on it are available to work on new projects.
Of course it is Mozilla's responsibility not to break the platform that this sort of system is built on, but sometimes they do it anyway. And when your multi-million-dollar customer calls your platinum support number at 4am because their mission critical system just died, you aren't going to win any prizes by telling them that it's their fault for using Firefox or arguing that their IT group should somehow be checking all their in-house web interfaces still work every six weeks before allowing each new version of the browser to roll out across their company network.
If your only answers to this sort of situation are "use another browser" or "educate your users", then you are ignoring the reality for many projects that these simply aren't acceptable responses in the eyes of management/customers. Often, the only choices you have might be reassigning people to hack some sort of workaround into the previously working system Right Now or losing a lot of money and/or good will to make up for a critical system failing.
Right, because things like Flash and Java applets aren't Real Web Technologies and anyone who uses them must just be some dumb amateur relying on "crufty, legacy proprietary features".
Technologies like these got badly broken when Firefox 10 -- the nominated extended support release -- was pushed out. They actually had the bug in their tracker several days before the release, but went ahead with it anyway, with the result that vast numbers of web sites were then broken for several more days before they pushed out a fix.
That was the clearest demonstration yet that Mozilla simply can't cope with the absurd release schedule but will prioritise hitting their arbitrary targets over product quality when something has to give. For a security-sensitive piece of software used by millions of people, that is downright irresponsible.
(Anyone who is about to smugly reply that Chrome does a better job so we should all switch to that will deserve anything they get, BTW.)
CPS view on mandatory and minimum custodial sentences
There was also a lot of high-profile political publicity around the time that things like the five year penalty for firearm possession came in.
If judges are allowed to override these minimum sentences, I have never seen any reference to it, nor can I find one searching now. I'm not a lawyer, so maybe I'm not aware of some technicality or procedural detail you are, but you're going to need to cite some clear authority to convince me.
I lost a boot drive for a workstation recently, and with it the activation for some very expensive professional software products.
More than one vendor subsequently refused to let me reactivate the software (the same legitimate copy of the same software on the same machine except with a fresh OS installation on a new drive) because they had records showing that my software key was registered to someone else, sometimes not even in the same country. Eventually, after multi-week hassle and in some cases literally sending photos of the boxed package with serial numbers etc. and the original sales invoice, everything was working again.
It's not as if they even apologised for messing me around entirely because of their own over-zealous copy protection and poor record keeping/registration checking, and certainly no form of compensation was offered for the downtime. And yet, the disruption and direct loss income from that downtime because I work from home was surely at least as bad as having someone break into the workstation and install some sort of malware, which I could at least have fixed within a day by nuking and reinstalling everything, but which would have been a criminal offence on their part.
I want the people who were directly responsible for authorising and operating those copy protection schemes to be personally and criminally liable, the same way they would be if they had cracked my network and remotely wiped the software. I understand why companies want to copy protect their code, but there's no way a mini-company like mine can afford to sue a global corporation to recover a week's lost income, so there needs to be some other form of deterrent. Locking up the guy who types my serial number into the remote-deactivation script would be a good start, I think, and a hell of a lot more justifiable than any nebulous law that covers obviously inadvertent access, "hacking" tools with legitimate uses for sysadmins/software developers, etc.
Silly categorical minimum sentences are pretty much an alien concept here.
That depends where "here" is. In the UK, we have seen all kinds of minimum sentences for possession of various prohibited items over the years, not to mention the policy of compulsory life sentences for murder.
Please don't get hung up on the specific example I gave. It was only an example of a more general point: because we now have much easier abilities to store, search and corrolate large numbers of small facts, and to make the results widely and instantly available with little cost, allowing the collection of any small fact about an individual may contribute to a much more severe loss of privacy than it ever could before those technologies existed.
Street View is just one case, in that for example if I know your address there is now a good chance I can quickly and anonymously find out your vehicle and registration details, because that outdoor photography has been systematically collected, is now searchable on-line, and is now available to the entire world.
The issue of recorded and searchable data is far broader, though. Consider that if one person is standing next to you while you pay in a shop, they probably aren't going to rob you later. Even if they happen to glance in your direction as you type the PIN to authorise a card payment, they probably can't see your card number or the security digits on the back. On the other hand, someone standing there with a video recording device requires only that in handling your card you momentarily expose both sides of it to reveal the numbers required to make an on-line payment. Someone who could follow you around with a recording device could probably collect many other relevant details for security checks based on address and the like as well.
That only sounds far-fetched because the effort for someone to do this when they have to be physically present for an extended period of time is prohibitive and the risk of being detected is quite high. There is a natural limit that contains the damage any one rogue individual can cause in both scale and number of victims.
On the other hand, today we have public safety CCTV cameras watching you as you go around the city. Here in the UK, we have a scary number of CCTV cameras watching you just about any other time these days, too, with very little regulation of how the footage is stored or used. We have increasingly accurate image processing software for things like facial recognition and OCR, so a momentary disclosure recorded in public can then be processed at length in private later. Payments are being made increasingly using cards that are inherently traceable and with no physical presence required to deter fraud, and as was widely reported a few days ago, shops data mining this sort of information can now predict very personal matters like pregnancy more accurately than family members and close friends. Obviously unless you're going around buying pregnancy testing kits, no-one observing a single purchase in a store could do that. To make life even easier for would-be fraudsters, millions of kids have even helpfully told Facebook the once-personal information that banks are going to use to identify them via security questions when they grow up: mother's maiden name, first pet, first school, and so on.
The sheer volume of information about you that is out there today and available to mine is staggering. Anyone able to obtain and corrolate even a tiny fraction of it could be a threat to you through obvious things like identity theft or even physical actions like robbery or kidnapping, and through more subtle things like red flagging your job application or bumping up your insurance premium because you hung around with people who are known to engage in "inappropriate activities". And in practice they would be almost unstoppable and unaccountable for doing these latter things, even if they resulted in discrimination that would otherwise be illegal or at least generally considered unethical, because how will you ever know you're being screwed that way to do anything about it? Of course there is also the whole creepy advertising thing, but that's hardly even on the scale as far as the consequences of lost privacy go IMHO.
None of this was possible before the era of the Internet and the mass surveillance da
The problem with your argument is that you are making the classic mistake of thinking that ANY of these things are new issues.
I would argue exactly the opposite: the changes enabled by modern technology mean we have not just a quantitative but a qualitative difference in the impact of small but no-longer-isolated observations. This does raise new fundamentally questions about what practical actions are consistent with any given moral position on privacy.
And how is this different from take a public picture of somebody, then putting it on the cover of a national magazine? See, we already had rules about that, and they cover situations like this just fine.
For one thing, not everywhere has the same rules about that. Please don't project your local legal system onto the rest of the world. Of all things, privacy is surely one of the most variable between jurisdictions in terms of legal protections.
For another thing, I think there is again a qualitative difference between appearing on a magazine cover, which is a relatively rare event and is by its nature a very public observation usually made by well-established professional media organisations, and the kind of back office data-mining operations that let anonymous observers look up all kinds of information about all kinds of subjects without the subjects even knowing.
There really isn't anything new here, and if you think there is, then you don't know your history very well.
Perhaps, but at least I understand that copyright and privacy have absolutely nothing to do with each other, aside from both being in conflict with absolute freedom of expression. It is strange that someone so keen to appeal to century-old court decisions apparently does not...
No, I haven't, at least not live. But that's not really the point, because the dubious thing here isn't the Street View car itself, it's the fact that the Street View system lets other people see things without ever physically being present at all.
The rules don't need to be re-written. The old ones work just fine as long as we don't throw out all reason as soon as "on a computer" is added.
The thing is, the old ones don't work just fine. If you pause to consider why privacy matters, the implications of actions that might have been seen as acceptable or a minor social faux pas twenty years ago could be profound today, and it is the implications that we really care about, not the actions themselves.
For example, consider Google's Street View project. When the privacy debate around their data collection flared up, some people defended them on the grounds that the cars were only driving down the street and photographing things any passer-by could see from a public place. Leaving aside the fact that this turned out not to be true, there are still many practical differences between the two scenarios.
For one thing, the individual in the street can themselves be seen. Being in a public place is a two-way deal, and if you're going around peering in through people's windows, you're going to attract unwelcome attention.
Even if you do, your presence is temporary. What you see isn't being recorded for all time, and certainly not in a searchable form or a way that can easily be corrolated with many other data sources.
Anything seen is seen by one private individual, not a vasty corporation with potentially a global audience.
Even if we accept as reasonable an individual taking a photograph in a public place that potentially diminishes someone else's privacy, perhaps because the latter person wasn't the subject of the photo and appeared in the background only coincidentally, such photos are still typically only for private, personal use, not being collected by a commercial entity that exists only to exploit anything it can for profit.
And finally, building on that idea of corrolating data from different sources, we get the kicker: one individual walking down the street can only see as much as, well, one individual walking down the street. This fundamentally and naturally limits the implications of anything they might see or do, even if their actions are unpleasant. Google, on the other hand, have vast resources and were conducting systematic surveillance on a national and even international scale.
Many of these distinctions also apply in other controversial privacy cases today, even those that aren't based on direct physical observation: mass surveillance by the state, for example, or the kind of insidious data mining operations going on at places like Facebook.
In short, privacy today needs to take into account not just the scale of any one "invasion", but the cumulative effect of all "invasions". In a world where the Internet provides quick and easy communication of any information from anyone to everyone, where some organisations have resources so vast that they didn't realise downloading that Internet was meant to be a joke, and where data storage and mining capabilities allow the co-ordination and interpretation of thousands of data points about any given individual in an instant, that means minor invasions are a much bigger deal than they used to be.
There is no reason we should tolerate this, and arguing the inevitability of technological progress is a weak straw man. Technology is neutral, and it's how we choose to use it that matters. After all, the technology has long existed for someone to kill you before you even heard the shot, yet we don't see an epidemic of sniper murders, because murder is wrong and (almost) everyone accepts that. For those whose values are incompatible with that societal norm, there are rules and penalties to act as a further deterrent. The same goes for any crime; absolute prevention is very rarely possible, but between the moral standards of the general population and imposing laws on disproportionately powerful entities like governments and megacorps we keep unwelcome behaviour in check.
The problem with privacy is just that it's
For what it's worth, I completely agree with you about that part. (I'm also not saying I think the larger question has a clear answer, either way.)
However, at the time I posted, I hadn't yet seen a single comment in the thread that limited any objection to that obviously unreasonable element, nor that even admitted the possibility that the basic question might have any merit.
Would it be too obvious to point out that in many places there is a watershed time in the evening, and anything shown on TV before that time is typically not allowed to include "grown up" content at all?
It's fascinating that in the first dozen or so posts I've read here, I see plenty of mockery and obvious jokes, but not a single person who has allowed that there may be even an element of truth to be found here.
A design that stops you from getting inside of it
Is this the same new iPad where there was a photo story of some guys who make tools for geeks demonstrating their gear by systematically taking one apart, all on-line within about ten seconds of the product launch?
There even seem to be references to this in TFA...
Now, now, be fair. They introduced a congestion charge in order to alleviate overcrowding on London's roads, and it has been highly effective and surely worth every penny that motorists have been charged! Anyone who claims it just moved some peak traffic to different roads or slightly different times of day is clearly deluded, and anyone who says it barely made a difference and the roads have long since gone back to being at least as crowded as before clearly isn't taking into account that they can now reach speeds of up to 12mph in the 50m gap between traffic lights, a full 20% improvement on the figure you quoted. Frankly, I think you're just being absurd and more than a little harsh on the national treasure that is London transport infrastructure.
Modern engineering can do some quite remarkable things, but for what it's worth, I think you've misunderstood the scale of the tunnels involved here by about an order of magnitude.
97% of services run to schedule, which isn't too bad.
It's not great, though. With more than a billion passenger journeys taken on the Underground per year, that 97% still represents more than 30 million significantly disrupted journeys, or if you prefer, regular commuters being late to work (or late home) once or twice every month.
Of course, there is only so much even the most hard-working staff could do with the limited resources available, and there is only so much money that can be available without putting fares (or taxpayer subsidy) up to politically intolerable levels.
In fairness, there are genuine improvements coming down the line. (Sorry...) These are at least partly driven by a desire not to look like idiots when a few million extra people are around for the Olympics later this year.
New trains with air-conditioning and a walk-through design, as used in underground networks such as those in Paris and Rome, have been rolling out for a year or so. They are replacing one line at a time and due to cover 40% of the network by 2015.
Also, a deal was announced just last week for Virgin Media to provide WiFi access on the London Underground during the 2012 Olympics, though it only covers station areas and not the trains themselves while they are in the tunnels. Its stated goal is to allow travellers to respond more quickly to disruption and avoid the busiest areas (which are almost certainly going to be flooded far beyond capacity at peak times during the Olympics, whatever happens).
The system is still nowhere near the level of, for example, the other European capitals I mentioned, though, and won't get there any time soon.
That makes sense too. It's not that low-level optimisation isn't important any more -- on the contrary, as we increasingly rely on stacked architectures and intermediate steps like virtual machine bytecode, it's probably more important than ever -- I just think we need to change long-standing assumptions about who does it. I think we're both saying the same thing in the end: dealing with assembly-level optimisation is no longer a task that makes sense for most programmers, and is best left to specialists. My default "specialist" in this case is someone working on the compiler tool chain, but your idea of allowing pluggable optimisers creates a related role with similar requirements.
It turns out that developer productivity is actually more important than almost anything.
Developer productivity might be more noticeable than almost anything. However, I shudder to think how much safer and more productive the world would be, and what impressive things we might be doing with the computing power available to us today, if we hadn't trained the general population to believe that slow, bug-ridden, insecure, barely usable software is somehow acceptable or even unavoidable.
These things each contribute a staggering drain on the global economy and the quality of human life. They just aren't as visible as a product that ships late or is missing a feature, because it's accepted as the norm that we wait half a minute each time our software loads a document, or we go and make a coffee while today's security patches are installed and the system reboots, or no-one really understands how to use $FEATURE in our business software anyway so we'll just file a support ticket and get back to it later, or the network is down this morning while MIS contain a virus outbreak (caused because Bob the CEO was too important to to read the IT policy and didn't know how to secure his laptop wireless connection anyway, which let someone install a backdoor, which in turn was exploited when dear old Susan in Accounts brought in the baby photos of her grandkids plus a bonus virus on a USB stick).
It isn't even clear that doing better would cost much more in either developer time or money. It would, however, require a change in mindset, a demand for higher standards, and much better training, collaboration and support for developers, across the whole industry or at least enough of it to act as a catalyst. Unfortunately, a lot of people don't like change, particularly change that requires questioning ideas they've taken for granted for a long time and acknowledging that they might have been doing a bad job as a result of those ideas. Also, the people most qualified to inspire and set a good example are probably too busy doing real work in niches where their skills and experience are genuinely valued, leaving the mainstream to soak up consultant-driven "best practices" that have an engineering foundation roughly comparable to an inch of sand under a skyscraper.
So, I think it turns out that developer productivity is more visible than almost anything. The jury is very much still out on whether it's more important.
It does depend a lot on context. The examples you gave are very simple, and avoid any of the awkward areas.
Consider a different example: calling a C library function that takes an enumeration type for one of its parameters.
Typically, in C, you will have a file something.h that contains the interface for a library, including things like function prototypes and enumeration definitions.
Unfortunately, this is all symbolic metadata that Python ctypes can't just read out of a shared object file. There is no handy way to have Python import all the enumerators from the header file and define them as symbolic constants, for example, or for Python to scan the header for function prototypes. Thus in practice we end up with things like ctypes argtypes and restype hassles, and with some sort of duplication of all the enumerators in Python code that then has to be maintained perfectly in sync with the underlying C interface.
What's more, Python doesn't have a concept of enumerations as such; PEP 354 was rejected. That means the best you're going to do is define a whole bunch of named constants for the enumerators in Python, and have your argtypes indicate the corresponding underlying integer type. Oh, but then the underlying type of an enumeration varies depending on the enumerators themselves, so now the effective prototype of every function that uses your enum as a parameter or return value, and thus the corresponding Python ctypes argtypes and restype data, has to change just because someone added the wrong value to an enumeration.
In short, Python/ctypes and C/enumerations are not a very happy mix. There are other techniques, as you mentioned, and tools for helping with automatic parsing of header files, and each approach has its own pros and cons. But there are plenty of cases where the overhead of calling from Python down to C code is unpleasant at best. As you can see from the Cython example you linked to, it's delusional to pretend that you can really just compile almost-unchanged Python code down to C, too. It doesn't take much of this hassle before you've lost most of the productivity benefit from writing in a higher-level language like Python, and you start thinking about writing a much wider chunk of your project in C just so you can move the Python-C bridge to a place in your architecture where the interface can be much simpler.
This isn't to say that I disagree with writing high-level code in Python and calling down to C in specific cases. Sometimes it really does work almost transparently. Most of the time it's not too bad, and if each language is much better for the kind of code you want to write in it (as IME it often will be) then the overheads in both developer time and run-time performance are a modest price to pay. But it's not always as easy as the introductory examples might suggest.
I completely agree with you. However, I think the long-term solution to that problem is to use higher-level programming languages that can express more advanced concepts explicitly, so the compiler can make more of the kinds of assumptions you're talking about. Training every programmer who wants to produce fast output code in the intricacies of modern process/memory architectures is not a viable long-term proposition; most programmers have other things to worry about. However, all programmers ultimately write their code in some language, so designing better languages and letting a few specialist programmers worry about implementing them is much more realistic.
Sorry, but I think your information is at least 5-10 years out of date.
Code generators in compilers obviously aren't perfect, and there are plenty of optimizations they don't do as well as they theoretically could yet. Still, compilers have been using the kinds of technique you describe for years now, even on some specialist chips used for embedding. I doubt many programmers, even those who work in the embedded space, have the skill to consistently outperform a compiler these days.
People still optimize to assembler.
Very rarely, though. On modern architectures, writing high performance assembly language requires a deep knowledge of how everything fits together. Compiler writers spend a lot of time becoming experts in this field, and a lot more time becoming experts in applying optimisations at different levels of abstraction within an entire codebase during the different stages of compilation/optimisation. Consequently most non-specialist programmers, even those who have done plenty of assembly work in their time, would produce slower final code today by hand-crafting their own assembly language than they would by writing in C and trusting a good compiler to take care of the code generation.
So another law telling them not to get distracted by a specific thing isn't going to do jack squat.
It's not telling them not to get distracted. It's telling them not to use a phone. It's a very clear, very unambiguous requirement, and those violating it can be objectively penalised.
If it is in fact more or less equally dangerous for everyone, why are police exempted? The only conclusion is that we don't care if police officers are getting distracted, or maybe, just maybe, not everyone really is prone to distraction by using a cellphone.
There have been tragic consequences to police officers being distracted while using their phones/radios and driving. Sadly, they are not immune at all to the negative effects. The better trained ones may be starting from a higher standard than the average driver, but they are still impaired to well below their usual standard while on the radio.
The difference, and the reason that most countries tolerate members of the emergency services using the radio while driving even if others are prohibited from doing so, is that in an emergency situation there is an upside to allowing them to use radios on the move that may save more lives than it costs.
Also, in case you didn't know, it's common practice in some countries for traffic police officers to work in pairs with the non-driving officer doing all the radio work/commentary for precisely this reason.
FYI: The Digital Economy Bill (third reading) at The Public Whip