There were more than 600,000 people protesting in Britain at the start of the Iraq war. It went ahead anyway.
That's true, but ignoring a couple of million protesters has effectively brought down Tony Blair and neutered the New Labour government. I can't think of a single high-profile, high-impact change they've got through since then.
The nastiest thing in the works is probably the whole ID cards and National Identity Register policy, for which the introductory legislation has already passed (though only after being rammed through with all the power the government could muster). I nevertheless predict with confidence that this will policy will die before it becomes mainstream, and the framework will be quietly "forgotten" by the next election. Over-hyped arguments about fighting terrorism and pleas to trust the government just ain't what they used to be, and I rather suspect that once the current political fad of believing the world is about to end because of environmental catastrophes has passed, I think privacy and personal freedom will be the Next Big Political Hot Potato.
On which note, it's interesting that by far the most-signed petition on the site objects to the introduction of vehicle tracking and road pricing measures. Many in government, including quite a few of my local councillors as well as the big central government players, seem to think this is inevitable. I rather suspect that it will be shot down on a similar basis to ID cards: it's a not-so-stealth tax, and it's a gross invasion of privacy. It's also overcomplicated when a much simpler alternative already exists via petrol tax, which could achieve much of the same end result. And of course, it's the answer to a problem that has only been created through a combination of poor government strategy and naive business management. The correct answers don't even seem to occur to them: not planning such that much of the population doesn't work locally; providing effective public transport alternatives rather than unreliable, overpriced, and generally less pleasant "services"; getting heavy freight off the roads and onto the alternative networks as much as possible; setting higher basic driving standards to reduce the number of incompetent/inconsiderate drivers who cause a disproportionate amount of congestion; providing serious facilities for cyclists rather than half-assed cycle lanes that do more harm than good, and encouraging employers to provide basics like secure cycle storage and showers at the office; management realising that flexible working hours as a minimum and often telecommuting are now both possible and indeed desirable arrangements for many workplaces; and so on, and so on.
Of course, whether any e-petitions like this will make the slightest difference to government policy remains to be seen. But if opposing a flawed and abusive policy to address the wrong underlying problem can get 600,000 names behind it within a couple of months, put me down as number 600,001; it's got to be worth a try, and even if the current government don't care, it could raise the profile of the issue come election time and get a commitment from other parties to oppose it.
I don't think this has much to do with socialism. I have no problem with people who make and share lots of good music receiving benefits in return. I just don't see why the audiences and the musicians should be propping up the middlemen who don't add any value to the proceedings, yet always seem to wind up taking home most of the profits.
The BBC have been offering a "Listen Again" service for a while now, which is very well regarded. Various popular radio shows are available for download (in Real format) for seven days after a show airs, and then they disappear from the web site. Theoretically you could keep them indefinitely once you've got them, but for many BBC shows, people are more interested in catching up on what they missed the other day/night. For that, both something open-ended like the current Listen Again service or the proposed but DRM-encumbered service would be an improvement on not having the material at all.
For the record, Great Britain (informally, Britain) is the largest of the British Isles, containing the political entities England, Scotland and Wales. The United Kingdom of Great Britain and Northern Ireland is the sovereign state. However, the term "British" has adopted the meaning of "of the United Kingdom". See http://en.wikipedia.org/wiki/British_Isles_(termin ology) for details of the many related terms.
The thing I found most unfortunate about the whole affair was that the reason given by the BBC Trust for not releasing the classical music: "There is a potential negative market impact if the BBC allows listeners to build an extensive library of classical music that will serve as a close substitute for commercially available downloads or CDs." [Emphasis added]
There are a lot of misconceptions about the BBC (not least how much of its funding comes from licence fees rather than other sources), but I'm pretty sure it's still supposed to be run essentially in the public interest. I don't really understand how protecting the commercial interests of classical music distributors are the expense of the public is part of that remit.
If we're talking about music that's out of copyright itself (Beethoven was the example given), and the particular recording is already being made available for the BBC to broadcast, you'd think the Beeb could negotiate some fair additional compensation for the recording orchestras in exchange for the rights to make it downloadable as well. After all, we have the Proms every year and no doubt some people record and keep those (legally or otherwise), so it doesn't seem like orchestras mind the coverage. Why not legitimise keeping the material, throw in a bit of fair compensation for the recording artists to match, and make the world a little nicer for all concerned?
All of what you say is true, as far as I know, but please pause and consider what you're saying.
For example, I assume you've read the paper about the development of Frag. Most of the advantages of using Haskell come from things like using a DSL to define the game behaviour concisely, the elegant type system, the ability to use higher-order functions in connection with the above, and the fact that the HOpenGL binding is available. The abstraction of the event loop is quite neat, but there are plenty of references to things like I/O, state, do notation, and the like, and there is no serious attempt to compare performance with the equivalent game written in a more traditional language like C. In other words, the advantages of using Haskell did not stem primarily from adopting a purely functional style, and one of the major potential weaknesses of using functional programming languages for industrial applications -- performance -- was not addressed.
I commend you for broadening your programming horizons by learning Haskell. I also caution against drinking the kool-aid too much. A lot of the support for Haskell is in the academic community, and their priorities are very different to those of industrial software developers.
When you start to combine Haskell with real world problems, a lot of that natural elegance starts to look very artificial. Then you introduce concepts that mimic imperative programming with shared state (albeit based on more mathematically rigorous underlying models) to overcome that. At that point, you're in the same bind as many of the newer languages today that are basically imperative in nature but starting to borrow from functional programming: you can do lots of the neat tricks, but when you dig deeper the expressive power isn't as much as you hoped.
In other words, purely functional programming is very limited until you build in support for real world issues like I/O using monads or whatever. Once you do that, you're not really working with purely functional code (in the sense of having no side-effects) anymore, but rather with code that represents and reasons with side-effects explicitly. Whether the best way to write such code is in a declarative, functional style, or an imperative one, or something else, is a question yet to be answered, because right now only the functional programming language community is making a serious effort to do it.
CPU is usually not the bottleneck except when other crap makes it the bottleneck.
Not if all you write is database front-ends and GUIs, sure. If you do serious maths, whether for simulation or CAD or gaming or an optimising compiler or whatever, then CPU is sometimes all that matters.
Ok, so hardware is moving towards parellelism (new buzzword? It's mine, and I've trademarked it, use it and I'll sue you!!).
Sure, you can have that one. "Parallelism", however, has been in use for years.
Software will need to be engineered differently to take advantage. This is nothing new. Old games don't take advantage of 3d cards. Once the hardware became relatively available, they started to. It's the same thing here.
Except that it's not the same at all. 3D cards provided hardware implementations of what the software was already doing, but the programming interface was essentially the same. Writing good software using concurrent execution, however, is a very difficult problem, and one not at all well served by today's threads and locking techniques.
But what I find most ironic is that further down the/. main page is an article about how businesses should move to dumb terminals for most users, implying server software which implies software designed for parellelism.
Firing off multiple essentially independent threads to deal with incoming requests on a server is easy. Co-ordinating multiple threads to perform complex operations efficiently on the new hardware is not.
So I guess I don't see where there's some giant disconnect between software and hardware, there's just a shift coming up, and there'll be a "synching up" period. We've had these in the past and this won't be the last.
That is almost certainly true. But there is a lot more than just hype in this case, even if you don't yet appreciate that fact.
I'm anchoring on your post because you've hinted at what I think this whole discussion is missing: there are several reasons to run more than one sequence of instructions simultaneously, and some of the problems are much easier than others.
For one thing, there is a huge difference between dividing a task into independent parts that can run in parallel, possibly combining the results afterwards, and running multiple concurrent, interacting threads. There is also a huge difference between explicit parallelism (a request comes into the server, and it fires off another thread to handle it) and implicit parallelism (I've got this expensive mathematical algorithm represented sequentially, and the compiler is going to spot opportunities to run parts of it in parallel and then combine the results).
Of these, explicit parallelism is easy, but both implicit parallelism and explicit concurrency are hard. (Implicit concurrency doesn't really make sense with these definitions.)
You described pure functional languages as "ideally suited for parallel processing". In a sense, yes, because of their underlying model they lend themselves to parallel processing. However, explicit parallelism is easy anyway, and sadly current research suggests that the scope for implicit parallelisation of algorithms is relatively limited in many applications. I'm not sure the big advantages coming from the functional programming world are because of this, though of course if someone does find a way to cost-effectively run algorithms in parallel for relatively short computations that might all change.
What is really interesting to me in the functional programming world isn't the "pure" concept of having no side effects, but rather the type systems that represent side effects explicitly, of which perhaps the best-known example is the monadic I/O concept in Haskell. See Simon Peyton-Jones's excellent paper Tackling the Awkward Squad for background on this and related areas.
My personal take is that this is too cumbersome to use in everyday programming as it currently stands. Indeed, the same view was expressed by several senior Microsoft programming language architects in a recent interview. IIRC, they gave the example that if you wanted expr1+expr2 for non-trivial expressions, you shouldn't always have to compute expr1 and expr2 and then combine the results in an explicit order just to satisfy the language's composition rules.
However, the principle of tracking side-effects and ordering them explicitly when it matters seems very sound. Ultimately, anything your program does matters only to the extent that it influences observable side-effects, and any internal computations can be arbitrarily reordered and parallelised as long as the side effects still come out the same.
From here, we can make the big jump to concepts like transactional memory, where related side effects that affect shared memory areas are grouped into database-style transactions, and the run-time framework ensures that either all related side-effects take effect together, or none do at all, as observed from any other thread that shares the memory space. I'm not really doing the concept justice with this summary: it is a vastly better approach to shared state than the classical thread-locking mechanisms, in expressive power, in safety, and in composability. The name of Simon Peyton-Jones appears often in the literature here as well, and I thoroughly recommend the work he and his colleagues have been doing to anyone who's interested in how we might deal with today's concurrency problems when our programming tools have grown up.
Similarly, you can start thinking of concurrent threads as sequences of actions whose side-effects may be arbitrarily ordered by default, and inter-thread communication as a mechanism to impose ordering where it is required.
Apparently any bias in the BBC presentation isn't affecting the readers who comment on their "have your say" pages. As I write this, Vista is having a pretty rough time there...
I'm sorry, I must live in a different UK. What is a "discovery warrant", and how does one obtain one? What UK law allows any use of force by private organisations in civil cases?
Regardless of the questionable legal status of EULAs, there are some things that cannot be accepted in a contract because they are unreasonable. One might argue that an open-ended clause requiring audits on demand by one party but at the other's expense is unreasonable. It might also matter whether the audited party was at a demonstrable disadvantage when agreeing the contract, for example, because they were given no opportunity to negotiate on the contractual terms. In the case of private customers there are all sorts of consumer protection laws as well, though as far as I know none of the main ones applies to business-to-business transactions.
In any case, people need to stop believing that because some draconian and non-negotiable clause is written in a text file with the letters EULA at the top, it is automatically binding. The law just doesn't work that way.
You mean other than the fact that civil law around the world makes it legal to build private police forces like this to enforce copyright? That these private police forces can enter private property, seize assets that contain confidential information, and are accountable to no-one? The BSA and other copyright police forces have more power to search than the FBI.
I'm sorry, I must be new here. Exactly what UK law gives the BSA, or anyone else, any authority to enter private property and seize assets?
When the security guard on the door of my company tells them they may not enter, exactly what recourse do they have, other than going to court?
And if my company does have proper licences (as proven in court, which is not the same as producing whatever specific and awkward evidence the BSA would like to see) why should my company not then ask for costs from the BSA, as permitted under UK law?
Makes it very tempting to set up an information campaign/protest right outside the front door of every big name media store in the country one Saturday, though, doesn't it?
Unfortunately, general public does not really know/care about DRM...
They haven't done up to this point, because it hasn't generally interfered with everyday use for most consumers.
That could change almost overnight if people who spent a lot of money on funky new HD-DVD or Blu-Ray movies find they can't watch them at full quality, or if people's portable media players start dying and they can't transfer their extensive music libraries to another player.
Sony's rootkit only affected a relatively small proportion of the consumer base, and still, look at the sh*tstorm that caused. One big PR disaster on the sort of scale we could be looking at here, and the entire DRM concept is toast forever in that market, with the first big name player to make Freedom To Choose their marketing campaign scoring a fortune.
I'm not sure what any of this has to do with privacy, but since you bring the subject up, perhaps a little more research is in order?
Hint #1: Look up the agreements between Iraq and Kuwait prior to Gulf War I, regarding the collection of oil from fields spanning the border.
Hint #2: Look at what Kuwait was actually doing.
Hint #3: Check what was going on politically at the time, with particular reference to communications between the Iraqi government and the US about resolving the problems relating to #1.
Seriously, I'm sure the former Iraqi government was not a nice group of people, and you could make strong arguments for various groups acting against them in various ways. Nevertheless, there is a lot of controversy surrounding various aspects of the build-up to the war; some even argue that the US gave a diplomatically-worded green light to Iraq over the use of military force against Kuwait. One thing is certain: there was a lot more going on before GWI than made the popular media, and going to war with Iraq was not nearly as noble an endeavour as some commentators made out.
Logic failure at line 2: Assumption that because someone is willing to take a few seconds to be helpful by pointing out a mistake that is trivial to fix, they are also willing to take a few minutes/hours to identify and follow convoluted procedures for filing fault reports using obscure, over-complicated interfaces that would make professionals weep.
Would you like to:
(T)hank them for their help, fix the trivial bug and make life a little better
(S)implify the "approved" error-reporting process so trivia can be reported trivially
(I)gnore the problem and watch your product stick at <5% market share eternally?
OK, I can accept that, and you might reasonably argue that true friends wouldn't care about the sort of thing they might hear anyway. But as you say, a lot of people you like and spend time with won't know you as well as your best friends. Consider then what happens when someone who isn't as close to you "finds out" something about you that isn't true because someone (not necessarily that same person, of course) jumped to the wrong conclusion. Your boss, perhaps? A friend of a friend you were thinking of asking out? The sad reality is, rumours do damage people, sometimes in very serious ways. In the case of medical confidentiality, we can take steps to prevent that, simply by being very restrictive in who we allow to access the information.
It's quite obvious to distinguish from copyrighted material to web cam material.
Really? I would say it's one of the hardest -- perhaps the hardest -- of the unsolved problems of the web today. Google can't possibly automate this completely, for the simple reason that by default, anything I create would be subject to copyright, but as the creator I can give up that right simply by declaring that I do so.
I don't get the whole "this is big brother" attitude about this at all.
Fair enough, but I suspect your position would be different if all your friends had found out something rather personal about you because the system leaked.
Perhaps medical issues shouldn't be regarded as embarrassing, but the fact is, for many people in today's society, they prefer not to share their ailments publicly. After all, if I told you I was HIV+, would your first reaction be "he's gay", "he sleeps around and has unsafe sex", "he's a drug abuser"? Or would it be "maybe he caught his arm on a used needle while giving life-saving first aid to a drug user"? Consider what most people's reactions might be, and the effect of the more common explanations on someone's reputation, and that'll explain why people keep things a secret. (For the avoidance of doubt, this is a hypothetical example.)
It's already a big system, which relies on the integrity of doctors and other health workers not to leak information. Generally, perhaps by their nature, this group are amongst the most ethically aware people in our society. But the bigger you make the system, the more scope there is for leaks. In cases like this, where privacy is clearly important, we should always question the need to pass data around more widely.
Fortunately for us, this will never fly in the UK. The medical profession has made is abundantly clear to government that it will not support even a UK-wide database on the suggested terms, with a high proportion of GPs stating that they would openly refuse to participate.
I live in the UK. During WW2, many of my parents' generation and all of the elder generations lived through the blitz. I doubt there was anything passive about running for bomb shelters to avoid being blown to pieces every time those sirens went off. They lived through rationing, and the imposition of mandatory identity measures, and all kinds of other security precautions, and some remarkable departures from our usual political system. They saw, from across the Channel, what happens when governments get too powerful. And you know what? Within a few years of the end of the war, they decided that none of the special measures were necessary in peace time, and got rid of them all.
Soon Maine will be come a state of elderly crotchety people, just like Florida, but without the beaches and spring break crowds.
Don't knock the elderly, crotchety people. Many of them have seen loved ones fight and die to protect important rights and freedoms, and they appreciate how important that was. Meanwhile, the PlayStation generation seem willing to surrender those rights to save a few seconds or a few cents, and to hell with the consequences. I know whose values I prefer.
Slashdot Mirror
Blockquoth the AC:
That's true, but ignoring a couple of million protesters has effectively brought down Tony Blair and neutered the New Labour government. I can't think of a single high-profile, high-impact change they've got through since then.
The nastiest thing in the works is probably the whole ID cards and National Identity Register policy, for which the introductory legislation has already passed (though only after being rammed through with all the power the government could muster). I nevertheless predict with confidence that this will policy will die before it becomes mainstream, and the framework will be quietly "forgotten" by the next election. Over-hyped arguments about fighting terrorism and pleas to trust the government just ain't what they used to be, and I rather suspect that once the current political fad of believing the world is about to end because of environmental catastrophes has passed, I think privacy and personal freedom will be the Next Big Political Hot Potato.
On which note, it's interesting that by far the most-signed petition on the site objects to the introduction of vehicle tracking and road pricing measures. Many in government, including quite a few of my local councillors as well as the big central government players, seem to think this is inevitable. I rather suspect that it will be shot down on a similar basis to ID cards: it's a not-so-stealth tax, and it's a gross invasion of privacy. It's also overcomplicated when a much simpler alternative already exists via petrol tax, which could achieve much of the same end result. And of course, it's the answer to a problem that has only been created through a combination of poor government strategy and naive business management. The correct answers don't even seem to occur to them: not planning such that much of the population doesn't work locally; providing effective public transport alternatives rather than unreliable, overpriced, and generally less pleasant "services"; getting heavy freight off the roads and onto the alternative networks as much as possible; setting higher basic driving standards to reduce the number of incompetent/inconsiderate drivers who cause a disproportionate amount of congestion; providing serious facilities for cyclists rather than half-assed cycle lanes that do more harm than good, and encouraging employers to provide basics like secure cycle storage and showers at the office; management realising that flexible working hours as a minimum and often telecommuting are now both possible and indeed desirable arrangements for many workplaces; and so on, and so on.
Of course, whether any e-petitions like this will make the slightest difference to government policy remains to be seen. But if opposing a flawed and abusive policy to address the wrong underlying problem can get 600,000 names behind it within a couple of months, put me down as number 600,001; it's got to be worth a try, and even if the current government don't care, it could raise the profile of the issue come election time and get a commitment from other parties to oppose it.
I don't think this has much to do with socialism. I have no problem with people who make and share lots of good music receiving benefits in return. I just don't see why the audiences and the musicians should be propping up the middlemen who don't add any value to the proceedings, yet always seem to wind up taking home most of the profits.
The BBC have been offering a "Listen Again" service for a while now, which is very well regarded. Various popular radio shows are available for download (in Real format) for seven days after a show airs, and then they disappear from the web site. Theoretically you could keep them indefinitely once you've got them, but for many BBC shows, people are more interested in catching up on what they missed the other day/night. For that, both something open-ended like the current Listen Again service or the proposed but DRM-encumbered service would be an improvement on not having the material at all.
For the record, Great Britain (informally, Britain) is the largest of the British Isles, containing the political entities England, Scotland and Wales. The United Kingdom of Great Britain and Northern Ireland is the sovereign state. However, the term "British" has adopted the meaning of "of the United Kingdom". See http://en.wikipedia.org/wiki/British_Isles_(termin ology) for details of the many related terms.
The thing I found most unfortunate about the whole affair was that the reason given by the BBC Trust for not releasing the classical music: "There is a potential negative market impact if the BBC allows listeners to build an extensive library of classical music that will serve as a close substitute for commercially available downloads or CDs." [Emphasis added]
There are a lot of misconceptions about the BBC (not least how much of its funding comes from licence fees rather than other sources), but I'm pretty sure it's still supposed to be run essentially in the public interest. I don't really understand how protecting the commercial interests of classical music distributors are the expense of the public is part of that remit.
If we're talking about music that's out of copyright itself (Beethoven was the example given), and the particular recording is already being made available for the BBC to broadcast, you'd think the Beeb could negotiate some fair additional compensation for the recording orchestras in exchange for the rights to make it downloadable as well. After all, we have the Proms every year and no doubt some people record and keep those (legally or otherwise), so it doesn't seem like orchestras mind the coverage. Why not legitimise keeping the material, throw in a bit of fair compensation for the recording artists to match, and make the world a little nicer for all concerned?
All of what you say is true, as far as I know, but please pause and consider what you're saying.
For example, I assume you've read the paper about the development of Frag. Most of the advantages of using Haskell come from things like using a DSL to define the game behaviour concisely, the elegant type system, the ability to use higher-order functions in connection with the above, and the fact that the HOpenGL binding is available. The abstraction of the event loop is quite neat, but there are plenty of references to things like I/O, state, do notation, and the like, and there is no serious attempt to compare performance with the equivalent game written in a more traditional language like C. In other words, the advantages of using Haskell did not stem primarily from adopting a purely functional style, and one of the major potential weaknesses of using functional programming languages for industrial applications -- performance -- was not addressed.
I commend you for broadening your programming horizons by learning Haskell. I also caution against drinking the kool-aid too much. A lot of the support for Haskell is in the academic community, and their priorities are very different to those of industrial software developers.
When you start to combine Haskell with real world problems, a lot of that natural elegance starts to look very artificial. Then you introduce concepts that mimic imperative programming with shared state (albeit based on more mathematically rigorous underlying models) to overcome that. At that point, you're in the same bind as many of the newer languages today that are basically imperative in nature but starting to borrow from functional programming: you can do lots of the neat tricks, but when you dig deeper the expressive power isn't as much as you hoped.
In other words, purely functional programming is very limited until you build in support for real world issues like I/O using monads or whatever. Once you do that, you're not really working with purely functional code (in the sense of having no side-effects) anymore, but rather with code that represents and reasons with side-effects explicitly. Whether the best way to write such code is in a declarative, functional style, or an imperative one, or something else, is a question yet to be answered, because right now only the functional programming language community is making a serious effort to do it.
Not if all you write is database front-ends and GUIs, sure. If you do serious maths, whether for simulation or CAD or gaming or an optimising compiler or whatever, then CPU is sometimes all that matters.
Sure, you can have that one. "Parallelism", however, has been in use for years.
Except that it's not the same at all. 3D cards provided hardware implementations of what the software was already doing, but the programming interface was essentially the same. Writing good software using concurrent execution, however, is a very difficult problem, and one not at all well served by today's threads and locking techniques.
Firing off multiple essentially independent threads to deal with incoming requests on a server is easy. Co-ordinating multiple threads to perform complex operations efficiently on the new hardware is not.
That is almost certainly true. But there is a lot more than just hype in this case, even if you don't yet appreciate that fact.
I'm anchoring on your post because you've hinted at what I think this whole discussion is missing: there are several reasons to run more than one sequence of instructions simultaneously, and some of the problems are much easier than others.
For one thing, there is a huge difference between dividing a task into independent parts that can run in parallel, possibly combining the results afterwards, and running multiple concurrent, interacting threads. There is also a huge difference between explicit parallelism (a request comes into the server, and it fires off another thread to handle it) and implicit parallelism (I've got this expensive mathematical algorithm represented sequentially, and the compiler is going to spot opportunities to run parts of it in parallel and then combine the results).
Of these, explicit parallelism is easy, but both implicit parallelism and explicit concurrency are hard. (Implicit concurrency doesn't really make sense with these definitions.)
You described pure functional languages as "ideally suited for parallel processing". In a sense, yes, because of their underlying model they lend themselves to parallel processing. However, explicit parallelism is easy anyway, and sadly current research suggests that the scope for implicit parallelisation of algorithms is relatively limited in many applications. I'm not sure the big advantages coming from the functional programming world are because of this, though of course if someone does find a way to cost-effectively run algorithms in parallel for relatively short computations that might all change.
What is really interesting to me in the functional programming world isn't the "pure" concept of having no side effects, but rather the type systems that represent side effects explicitly, of which perhaps the best-known example is the monadic I/O concept in Haskell. See Simon Peyton-Jones's excellent paper Tackling the Awkward Squad for background on this and related areas.
My personal take is that this is too cumbersome to use in everyday programming as it currently stands. Indeed, the same view was expressed by several senior Microsoft programming language architects in a recent interview. IIRC, they gave the example that if you wanted expr1+expr2 for non-trivial expressions, you shouldn't always have to compute expr1 and expr2 and then combine the results in an explicit order just to satisfy the language's composition rules.
However, the principle of tracking side-effects and ordering them explicitly when it matters seems very sound. Ultimately, anything your program does matters only to the extent that it influences observable side-effects, and any internal computations can be arbitrarily reordered and parallelised as long as the side effects still come out the same.
From here, we can make the big jump to concepts like transactional memory, where related side effects that affect shared memory areas are grouped into database-style transactions, and the run-time framework ensures that either all related side-effects take effect together, or none do at all, as observed from any other thread that shares the memory space. I'm not really doing the concept justice with this summary: it is a vastly better approach to shared state than the classical thread-locking mechanisms, in expressive power, in safety, and in composability. The name of Simon Peyton-Jones appears often in the literature here as well, and I thoroughly recommend the work he and his colleagues have been doing to anyone who's interested in how we might deal with today's concurrency problems when our programming tools have grown up.
Similarly, you can start thinking of concurrent threads as sequences of actions whose side-effects may be arbitrarily ordered by default, and inter-thread communication as a mechanism to impose ordering where it is required.
The sorts of prototype implementations flying
Apparently any bias in the BBC presentation isn't affecting the readers who comment on their "have your say" pages. As I write this, Vista is having a pretty rough time there...
I'm sorry, I must live in a different UK. What is a "discovery warrant", and how does one obtain one? What UK law allows any use of force by private organisations in civil cases?
Regardless of the questionable legal status of EULAs, there are some things that cannot be accepted in a contract because they are unreasonable. One might argue that an open-ended clause requiring audits on demand by one party but at the other's expense is unreasonable. It might also matter whether the audited party was at a demonstrable disadvantage when agreeing the contract, for example, because they were given no opportunity to negotiate on the contractual terms. In the case of private customers there are all sorts of consumer protection laws as well, though as far as I know none of the main ones applies to business-to-business transactions.
In any case, people need to stop believing that because some draconian and non-negotiable clause is written in a text file with the letters EULA at the top, it is automatically binding. The law just doesn't work that way.
I'm sorry, I must be new here. Exactly what UK law gives the BSA, or anyone else, any authority to enter private property and seize assets?
When the security guard on the door of my company tells them they may not enter, exactly what recourse do they have, other than going to court?
And if my company does have proper licences (as proven in court, which is not the same as producing whatever specific and awkward evidence the BSA would like to see) why should my company not then ask for costs from the BSA, as permitted under UK law?
Makes it very tempting to set up an information campaign/protest right outside the front door of every big name media store in the country one Saturday, though, doesn't it?
They haven't done up to this point, because it hasn't generally interfered with everyday use for most consumers.
That could change almost overnight if people who spent a lot of money on funky new HD-DVD or Blu-Ray movies find they can't watch them at full quality, or if people's portable media players start dying and they can't transfer their extensive music libraries to another player.
Sony's rootkit only affected a relatively small proportion of the consumer base, and still, look at the sh*tstorm that caused. One big PR disaster on the sort of scale we could be looking at here, and the entire DRM concept is toast forever in that market, with the first big name player to make Freedom To Choose their marketing campaign scoring a fortune.
I'm not sure what any of this has to do with privacy, but since you bring the subject up, perhaps a little more research is in order?
Hint #1: Look up the agreements between Iraq and Kuwait prior to Gulf War I, regarding the collection of oil from fields spanning the border.
Hint #2: Look at what Kuwait was actually doing.
Hint #3: Check what was going on politically at the time, with particular reference to communications between the Iraqi government and the US about resolving the problems relating to #1.
Seriously, I'm sure the former Iraqi government was not a nice group of people, and you could make strong arguments for various groups acting against them in various ways. Nevertheless, there is a lot of controversy surrounding various aspects of the build-up to the war; some even argue that the US gave a diplomatically-worded green light to Iraq over the use of military force against Kuwait. One thing is certain: there was a lot more going on before GWI than made the popular media, and going to war with Iraq was not nearly as noble an endeavour as some commentators made out.
Logic failure at line 2: Assumption that because someone is willing to take a few seconds to be helpful by pointing out a mistake that is trivial to fix, they are also willing to take a few minutes/hours to identify and follow convoluted procedures for filing fault reports using obscure, over-complicated interfaces that would make professionals weep.
Would you like to:
(T)hank them for their help, fix the trivial bug and make life a little better
(S)implify the "approved" error-reporting process so trivia can be reported trivially
(I)gnore the problem and watch your product stick at <5% market share eternally?
OK, I can accept that, and you might reasonably argue that true friends wouldn't care about the sort of thing they might hear anyway. But as you say, a lot of people you like and spend time with won't know you as well as your best friends. Consider then what happens when someone who isn't as close to you "finds out" something about you that isn't true because someone (not necessarily that same person, of course) jumped to the wrong conclusion. Your boss, perhaps? A friend of a friend you were thinking of asking out? The sad reality is, rumours do damage people, sometimes in very serious ways. In the case of medical confidentiality, we can take steps to prevent that, simply by being very restrictive in who we allow to access the information.
Really? I would say it's one of the hardest -- perhaps the hardest -- of the unsolved problems of the web today. Google can't possibly automate this completely, for the simple reason that by default, anything I create would be subject to copyright, but as the creator I can give up that right simply by declaring that I do so.
Why on earth would you say that?
And they'll distinguish this reliably from copyright infringement how?
Fair enough, but I suspect your position would be different if all your friends had found out something rather personal about you because the system leaked.
Perhaps medical issues shouldn't be regarded as embarrassing, but the fact is, for many people in today's society, they prefer not to share their ailments publicly. After all, if I told you I was HIV+, would your first reaction be "he's gay", "he sleeps around and has unsafe sex", "he's a drug abuser"? Or would it be "maybe he caught his arm on a used needle while giving life-saving first aid to a drug user"? Consider what most people's reactions might be, and the effect of the more common explanations on someone's reputation, and that'll explain why people keep things a secret. (For the avoidance of doubt, this is a hypothetical example.)
It's already a big system, which relies on the integrity of doctors and other health workers not to leak information. Generally, perhaps by their nature, this group are amongst the most ethically aware people in our society. But the bigger you make the system, the more scope there is for leaks. In cases like this, where privacy is clearly important, we should always question the need to pass data around more widely.
Fortunately for us, this will never fly in the UK. The medical profession has made is abundantly clear to government that it will not support even a UK-wide database on the suggested terms, with a high proportion of GPs stating that they would openly refuse to participate.
I live in the UK. During WW2, many of my parents' generation and all of the elder generations lived through the blitz. I doubt there was anything passive about running for bomb shelters to avoid being blown to pieces every time those sirens went off. They lived through rationing, and the imposition of mandatory identity measures, and all kinds of other security precautions, and some remarkable departures from our usual political system. They saw, from across the Channel, what happens when governments get too powerful. And you know what? Within a few years of the end of the war, they decided that none of the special measures were necessary in peace time, and got rid of them all.
Don't knock the elderly, crotchety people. Many of them have seen loved ones fight and die to protect important rights and freedoms, and they appreciate how important that was. Meanwhile, the PlayStation generation seem willing to surrender those rights to save a few seconds or a few cents, and to hell with the consequences. I know whose values I prefer.