I quote myself, from the comment you just replied to:
There's another obstacle: most software's handling of files is not built around a distinction between "master" files (used to edit the document, and which may legitimately need to contain more information than what is displayed in any one view) and "distribution" files (used to hand out to people who only need to read the document). Master files potentially do need to include information that should not be revealed in the corresponding distribution files; distribution files do not need to support editing of their main content. So, design the UI to support users' reasoning about this problem.
Maybe not, but an OSS program would have allowed them to modify the source so "invisible" classified data CANNOT be included in a report that leaves the system.
Yes, because OSS programs are all infinitely malleable, so that with very little effort, you can revise design and architectural decisions that influence the whole codebase, and modify the program to do something its creators never envisioned, while keeping its pristinely clean code just as clean as it was when you received it. Yeah, right.
OSS does not remove the problems of software engineering.
...instead of burying a "Remove Hidden Data" option somewhere in a menu as a CYA move (so that when users inevitably fail to use them, you can comfortably refuse to admit your responsibility by citing an obscure feature of your program designed precisely to allow you to disclaim responsibility), what about engineering the product so that the file format only keeps the information actually displayed in the document? You know, as in, engineering the program so as to make it possible to use the way the document is visually represented in the screen as a source of inferences about what information will be revealed to document recipients or concealed from them.
This isn't rocket science, you know. It's just standard user interface design. With WYSIWYG, the UI is inviting people to use paper documents as a metaphors for understanding the screen display. If something isn't showing in a paper document, then the paper document simply doesn't contain that information; the paper is only surface. The idea that when you send somebody a document, it may contain more information than what you can see, is in contradiction with the WYSIWYG principle the software's UI was designed to make us use. Have you even sat down to think how to solve this problem?
There's another obstacle: most software's handling of files is not built around a distinction between "master" files (used to edit the document, and which may legitimately need to contain more information than what is displayed in any one view) and "distribution" files (used to hand out to people who only need to read the document). Master files potentially do need to include information that should not be revealed in the corresponding distribution files; distribution files do not need to support editing of their main content. So, design the UI to support users' reasoning about this problem. Use a metaphor of a "workspace" where you assemble "scraps" of information from many sources to produce a "finished" document, which is the thing you send to a recipient, and respects the assumption that its information content is transparent from how it looks.
That is, instead of building the whole UI around the metaphor of a finished document (WYSIWYG), build it around the metaphor of creating a document, which involves elements and tasks that are not visible in the finished outcome.
But most important of all, stop blaming the user for not knowing how to use badly designed software, and stop shirking off design flaws by putting in stopgap CYA features into software. Take responsibility for the fact that your software isn't as easy to use as it might be, and that it makes it easy to do many bad things.
I'm not suggesting that they start selling boxed OS/X to load on any X86 clone out there. I'm suggesting that they license a few OEM's to build systems guaranteed "to just work", just like the Apple equivalents.
Apple designs their systems in-house, and contract out manufacturing. What you're suggesting, instead, is that they allow outside companies to design and build OS X systems on their own, as long as they meet some QA standard set and enforced by Apple.
Your suggestion sounds like the wrong cut of the problem space. The way Apple have cut it, all the design people (for the OS, the hardware and the apps) are under the same roof as the people who QA their work.
Language can certainly be used to distort and deceive, but if your understanding of how this is done consists of claiming that the perpetrators do so by using words in something other than their "true meaning," you need a more sophisticated understanding of how language is used.
A republic is not a democracy. A democracy is when the people rule. A republic is when officials are elected.
My Oxford American Dictionary says that democracy is "a system of government by the whole population or all the eligible members of a state, typically through elected representatives" (or "a state governed in such a way"); and republic is "a state in which supreme power is held by the people and their elected representatives, and which has an elected or nominated president rather than a monarch."
Note, however, that dictionary definitions do not settle arguments. Meanings are determined by usage, and dictionaries are records of usage (and fallible ones). But, when all the media in your country routinely use the word democracy in a way that contradicts the rule you're stating there, well, it's your rule that's mistaken, not the people who use the word in violation of it. This is just Linguistics 101.
Who cares? Just believe what you say. You do want it to be true, don't you? Well, with a little bit of a perfectly ordinary technique known as "wishful thinking," your wishes can come true, as far as your belief in them is concerned!
You get to reap all of the benefits of sincerity, too.
you can only charge what the market will accept. and guess what. the market is accepting a far lower price.
You're assuming that the price that the market will accept is independent of whether piracy exists. If the market can obtain your service for free, then the price the market will accept is $0, and so you can't make any money from providing it. The arguments that the record industry should price their offerings down to a level the market will accept fall apart if the level is $0; you can't argue that there's a non-zero fair price for music if piracy exists.
Copyright is precisely about creating a market where one would not otherwise exist, because otherwise, the service in question would not be provided at all.
Simply put, if pirates could buy brand a new movie on a standard DL-DVD without a box (toss it in a paper slip) for $4-$5, pirates would probably buy it oppose to copying.
Why would the pirates pay $4-5 for something they can get for free? You're baldly stating something that just begs the question.
If the MAFIAA provides a valuable service to you, and expects money in exchange, it seems reasonable that you should give them money.
You're forgetting something that would strengthen your argument: the record labels aren't just providing a service to music buyers, they're also providing a service to the music makers. Artists are perfectly fine to work out their own deals for financing, distributing and promoting their records, for collecting money from retailers, etc.
And as a music buyer, you should expect to have to pay for those costs indirectly when you buy music, no matter what kind of deals the artist makes to obtain those services. This is a reason why the common "the money should go to the artist" excuses for piracy are bullshit--even if the money did go to the artist directly, the artist would still have to pay a lot to get the same services they're getting. Why? Because the demand for financing, distribution and promotion of music records far exceeds the supply, or in other words, for every guy who wants to release their record on a major label, there's gazillions of others who'd also like to, who'd sell just as well.
...that the label is actually providing a service to the artist, and not the buyer? Perhaps the artist does want to pay somebody to finance, promote and distribute their record. Why shouldn't the artist be allowed to pass those costs to the record buyers?
Frankly, all the "evil record industry" ranting is missing the point that a lot of this problem comes down not just to the labels, but also to artists who want to "make it big" or "go major" end up making bad deals with labels, where they come out behind what they would come out if they weren't as ambitious. That is, major labels exploit a supply of artists who, out of wishful thinking about their chances for success, fail to properly account for the risk they take on by signing.
They ignore the inconvienent truths such as.... If the product was available in a form and at a price people were willing to pay, they would buy it.
Nope. Suppose people have a choice between the following:
Downloading a piece of music for free.
Paying the price they'd be willing to pay for that piece of music if they couldn't download it for free.
It is a trivial and charitable extension of their argument that if people have these two choices, they'll overwhelmingly pick to download for free over paying. It also follows that to the extend that people have the free download as an option, record companies will have to price their products upwards to be compensated for their work.
You can argue that record companies are overpricing their product all you want, but as long as you don't recognize this basic economic matter, you're just being unrealistic. Even if you think they're being compensated too much, record companies still deserve to be compensated at some rate for the services they provide; so you must provide some mechanism that guarantees that they can be compensated for their services, by making it impossible for people to steal those services.
4. Illegal file-sharers don't care whether the copyright-infringing work they distribute is from a major or independent label.
10. P2P networks are not hotbeds for discovering new music. It is popular music that is illegally file-shared most frequently.
Aren't these counter to each other?
No. Those two hold simultaneously in a scenario where the music preferences of people who use P2P networks simply mirror those of the general population. Each person who downloads a track picks it because they want to hear that track; what label it came out on is irrelevant as a motive (point #4). Since the tracks that most people prefer are released on major labels, most of the music downloaded is from major labels; however, that's just a contigent fact, because knowledge or preference for kind of label affiliation played no role at any individual event where a person picked a track to download.
C-u is one of the most important prefix command keys. It's not just "repeat n times" (which is really damn important, BTW), but also, more generally, "run the next command in a slightly different way." For example, M-x shell gets you shell-mode with a buffer called *shell*; if the buffer already exists, it switches to it. C-u M-x shell, on other hand, prompts you for a buffer name. You need to use C-u M-X if you want to have multiple shell buffers.
I suspect it's easier and quicker to just download it from here (as I've been doing for a long while now with the prereleases): http://www.porkrind.org/emacs/
You want people to freely do whatever they wish with their windows open, without someone watching. Guess what? People can and will watch, and unless your blinds are closed, or they are on your property, what they are doing is simply an extension of their rights as citizens. The same rights you have.
There's a significant difference between a passerby seeing something inside somebody's window, and a huge internet search company sending out vans to take millions of photos to put in a publically accessible database that correlates each photo with the geographical location, street address, and the rest of the whole damn Internet, for that matter.
I don't think anybody disagrees on the passerby case. If you have your window open, you have no reasonable expectation that somebody passing by shouldn't be able to see in. That, however, doesn't necessarily extend to the latter case. Hell, it doesn't even extend to the old film-photography-and-paper publishing world; IIRC, it's ambiguously legal to take a picture that showed the inside of somebody's house through their window without their authorization, and definitely illegal to publish it in most venues.
I don't think this is true, at least in the U.S. I think the cases you are thinking of, are more related to improper/unpermitted use of someone's image. That's slightly different than privacy. It's more of an intellectual property dispute, really.
There's a reason I said "the taking or the publication" in my post. I'm well aware that there are many situations where you're allowed to take a picture but aren't allowed to use it in some ways.
Still, here's an example of forbidden public photography: many jurisdictions are adding laws banning the taking of upskirt photos.
If you don't want someone to take pictures of you, or see you doing the nasty, or anything else inside your house, close your blinds, otherwise you have no expectation of privacy, either from the government, or from your fellow citizens.
I don't think that is true. There are precedents where the taking or the publication of pictures of somebody in a public place have been judged to be an invasion of privacy.
In any case, the framework and laws that we have for privacy come from an age where we didn't have instant, in-a-whim access to massive amounts of information of different modalities (text records of many kinds, satellite imagery, street maps, street-level photos), carefully correlated to each other, through a simple web search. This changes the risk/benefit analysis involved in your privacy choices. Think how the case for whether to leave your blinds open (because you like natural light, and hate darkness) has been affected by technology over the years:
Before the widespread availability of photography, if you left your blinds open and somebody in the street saw you naked, well, they would be left with the memory of seeing you naked, but the guy can't show his memory to other people.
After photography became widely available, the guy in the street could take a picture of you, meaning that he can show your picture to other people, who will thereby have seen you naked. However, he faces some limitations as to how many copies of the photograph he can make (because it requires work), and as to how to distribute the photo to other people.
With the Internet and digitized photos, the guy can instantly send the picture effortlessly and nearly costlessly to millions of other people, who can also do the same. The pictures can spread by word of mouth far more quicker and wider than they ever could before.
With Google making the picture show up as a search result for a map search of your address, tying it together with millions of other such pictures, and to indexed information of many other kinds, anybody who has your street address can now get your naked picture. This is just the beginning, because, again, the information is tied to many other kinds of information in a way that makes going from one to another very easy. For example, your neighbors may casually navigate the visual database of your neighborhood, and see your naked picture.
I draw the line at the last of these cases. The fact that an observer at the right place and time might be able to look in your window while something you didn't want them to see happened, and even the fact that the observer may take a picture, post it in the internet, and have it spread to millions of people through word of mouth, doesn't give the right to a private, profit-driven entity like Google to systematically take and gather such pictures (that make it possible to see what's going on inside random, arbitrary people's windows) and make them available in a publically accessible, searchable, intermodal database that correlates them with other such pictures and information of many other kinds. Keeping your blinds open should indeed be a risky proposition, but people and companies should be forbidden from exploiting that risk, and most importantly, from magnifying that risk.
They conclude that altruism is "hardwired" based on the brain activity of adults, who've long been thoroughly socialized into their communities. I mean, do we really believe that learned behaviors of all sorts (like, e.g., eating, having sex, or being nice to others) cannot trigger whatever sort of activity in some brain area? Why can't adult, learned ways of coping with the environment piggyback on the mechanisms and pathways found on infants? Or, more generally, how is the activation of a brain area when X happens supposed to count as evidence that X is "hardwired"?
They conclude that altruism is "hardwired." Stop and think about that analogy. Notice how useless it is when trying to explain how an organism develops through its lifetime of interaction with a very rich and variable environment.
Why are you telling me all that? I don't disagree that concurrent programming shouldn't be any harder than other kinds of programming. All I said was that all the amateur psychology and neuroscience that people were spouting in this thread was irrelevant to the question.
Other than that, yes, data-flow synchronization makes concurrent programming way easier.
You're thinking of how to speed up programs by using parallel execution units. This is closely related, but not exactly the same thing, as the use of concurrent programming techniques to write better organized programs capable of responding flexibly to events from multiple sources while also performing their own "background" computations. Think of a UI program that must simultaneously react to user interaction events, while also performing some computation that's mostly independent of user input. A word processor that does grammar checking in the background while the user interacts with the UI in other ways is a prime example.
The thing is that with mainstream languages, writing programs like this is probably much harder than it needs to be, for several reasons:
Many threading mechanisms are built with parallelism in mind rather than concurrency, and make it too expensive to spawn a gazillion concurrent threads to handle each independent thing in your app.
Your typical mainstream language of today is an imperative language with threading and shared memory synchronization primitives bolted in. This means that perfectly innocent-looking code often has suprising and confusing behavior when executed concurrently, because the language's bolted-in concurrency exposes low-level details of the hardware like the interaction of cache and main memory. Shared mutable memory between parallel execution units is a hard thing to wrap your head around.
The same hard stuff that makes some of your innocent-looking behave in a crassly incorrect way is, in fact, the stuff that you need to exploit for thread synchronization.
Here's one way of solving this problem: (a) lightweight threading mechanisms for concurrency (in addition to the heavyweight ones for parallelism), (b) no shared mutable memory between threads (any shared memory must be immutable), and (c) simpler thread synchronization primitives that do not rely on shared mutable memory, like communication channels between threads.
Our cognitive system does many things at the same time, yes. That doesn't answer the question that's being posed here: whether explicit, conscious reasoning about parallel processing is hard for people.
Slashdot Mirror
Yes, because OSS programs are all infinitely malleable, so that with very little effort, you can revise design and architectural decisions that influence the whole codebase, and modify the program to do something its creators never envisioned, while keeping its pristinely clean code just as clean as it was when you received it. Yeah, right.
OSS does not remove the problems of software engineering.
...instead of burying a "Remove Hidden Data" option somewhere in a menu as a CYA move (so that when users inevitably fail to use them, you can comfortably refuse to admit your responsibility by citing an obscure feature of your program designed precisely to allow you to disclaim responsibility), what about engineering the product so that the file format only keeps the information actually displayed in the document? You know, as in, engineering the program so as to make it possible to use the way the document is visually represented in the screen as a source of inferences about what information will be revealed to document recipients or concealed from them.
This isn't rocket science, you know. It's just standard user interface design. With WYSIWYG, the UI is inviting people to use paper documents as a metaphors for understanding the screen display. If something isn't showing in a paper document, then the paper document simply doesn't contain that information; the paper is only surface. The idea that when you send somebody a document, it may contain more information than what you can see, is in contradiction with the WYSIWYG principle the software's UI was designed to make us use. Have you even sat down to think how to solve this problem?
There's another obstacle: most software's handling of files is not built around a distinction between "master" files (used to edit the document, and which may legitimately need to contain more information than what is displayed in any one view) and "distribution" files (used to hand out to people who only need to read the document). Master files potentially do need to include information that should not be revealed in the corresponding distribution files; distribution files do not need to support editing of their main content. So, design the UI to support users' reasoning about this problem. Use a metaphor of a "workspace" where you assemble "scraps" of information from many sources to produce a "finished" document, which is the thing you send to a recipient, and respects the assumption that its information content is transparent from how it looks.
That is, instead of building the whole UI around the metaphor of a finished document (WYSIWYG), build it around the metaphor of creating a document, which involves elements and tasks that are not visible in the finished outcome.
But most important of all, stop blaming the user for not knowing how to use badly designed software, and stop shirking off design flaws by putting in stopgap CYA features into software. Take responsibility for the fact that your software isn't as easy to use as it might be, and that it makes it easy to do many bad things.
Apple designs their systems in-house, and contract out manufacturing. What you're suggesting, instead, is that they allow outside companies to design and build OS X systems on their own, as long as they meet some QA standard set and enforced by Apple.
Your suggestion sounds like the wrong cut of the problem space. The way Apple have cut it, all the design people (for the OS, the hardware and the apps) are under the same roof as the people who QA their work.
Language can certainly be used to distort and deceive, but if your understanding of how this is done consists of claiming that the perpetrators do so by using words in something other than their "true meaning," you need a more sophisticated understanding of how language is used.
My Oxford American Dictionary says that democracy is "a system of government by the whole population or all the eligible members of a state, typically through elected representatives" (or "a state governed in such a way"); and republic is "a state in which supreme power is held by the people and their elected representatives, and which has an elected or nominated president rather than a monarch."
Note, however, that dictionary definitions do not settle arguments. Meanings are determined by usage, and dictionaries are records of usage (and fallible ones). But, when all the media in your country routinely use the word democracy in a way that contradicts the rule you're stating there, well, it's your rule that's mistaken, not the people who use the word in violation of it. This is just Linguistics 101.
Who cares? Just believe what you say. You do want it to be true, don't you? Well, with a little bit of a perfectly ordinary technique known as "wishful thinking," your wishes can come true, as far as your belief in them is concerned!
You get to reap all of the benefits of sincerity, too.
You're assuming that the price that the market will accept is independent of whether piracy exists. If the market can obtain your service for free, then the price the market will accept is $0, and so you can't make any money from providing it. The arguments that the record industry should price their offerings down to a level the market will accept fall apart if the level is $0; you can't argue that there's a non-zero fair price for music if piracy exists.
Copyright is precisely about creating a market where one would not otherwise exist, because otherwise, the service in question would not be provided at all.
Why would the pirates pay $4-5 for something they can get for free? You're baldly stating something that just begs the question.
You're forgetting something that would strengthen your argument: the record labels aren't just providing a service to music buyers, they're also providing a service to the music makers. Artists are perfectly fine to work out their own deals for financing, distributing and promoting their records, for collecting money from retailers, etc.
And as a music buyer, you should expect to have to pay for those costs indirectly when you buy music, no matter what kind of deals the artist makes to obtain those services. This is a reason why the common "the money should go to the artist" excuses for piracy are bullshit--even if the money did go to the artist directly, the artist would still have to pay a lot to get the same services they're getting. Why? Because the demand for financing, distribution and promotion of music records far exceeds the supply, or in other words, for every guy who wants to release their record on a major label, there's gazillions of others who'd also like to, who'd sell just as well.
Frankly, all the "evil record industry" ranting is missing the point that a lot of this problem comes down not just to the labels, but also to artists who want to "make it big" or "go major" end up making bad deals with labels, where they come out behind what they would come out if they weren't as ambitious. That is, major labels exploit a supply of artists who, out of wishful thinking about their chances for success, fail to properly account for the risk they take on by signing.
Nope. Suppose people have a choice between the following:
- Downloading a piece of music for free.
- Paying the price they'd be willing to pay for that piece of music if they couldn't download it for free.
It is a trivial and charitable extension of their argument that if people have these two choices, they'll overwhelmingly pick to download for free over paying. It also follows that to the extend that people have the free download as an option, record companies will have to price their products upwards to be compensated for their work.You can argue that record companies are overpricing their product all you want, but as long as you don't recognize this basic economic matter, you're just being unrealistic. Even if you think they're being compensated too much, record companies still deserve to be compensated at some rate for the services they provide; so you must provide some mechanism that guarantees that they can be compensated for their services, by making it impossible for people to steal those services.
No. Those two hold simultaneously in a scenario where the music preferences of people who use P2P networks simply mirror those of the general population. Each person who downloads a track picks it because they want to hear that track; what label it came out on is irrelevant as a motive (point #4). Since the tracks that most people prefer are released on major labels, most of the music downloaded is from major labels; however, that's just a contigent fact, because knowledge or preference for kind of label affiliation played no role at any individual event where a person picked a track to download.
C-u is one of the most important prefix command keys. It's not just "repeat n times" (which is really damn important, BTW), but also, more generally, "run the next command in a slightly different way." For example, M-x shell gets you shell-mode with a buffer called *shell*; if the buffer already exists, it switches to it. C-u M-x shell, on other hand, prompts you for a buffer name. You need to use C-u M-X if you want to have multiple shell buffers.
I suspect it's easier and quicker to just download it from here (as I've been doing for a long while now with the prereleases): http://www.porkrind.org/emacs/
I've been using prerelease builds from this page for over a year now: http://www.porkrind.org/emacs/. Issues have been minor and obscure recently.
And it's really just the sources that are out; there's precious few binaries out there.
Can we post binary torrents in this thread? I want OS X, preferably Universal, but Intel-only will do.
There's a significant difference between a passerby seeing something inside somebody's window, and a huge internet search company sending out vans to take millions of photos to put in a publically accessible database that correlates each photo with the geographical location, street address, and the rest of the whole damn Internet, for that matter.
I don't think anybody disagrees on the passerby case. If you have your window open, you have no reasonable expectation that somebody passing by shouldn't be able to see in. That, however, doesn't necessarily extend to the latter case. Hell, it doesn't even extend to the old film-photography-and-paper publishing world; IIRC, it's ambiguously legal to take a picture that showed the inside of somebody's house through their window without their authorization, and definitely illegal to publish it in most venues.
Still, here's an example of forbidden public photography: many jurisdictions are adding laws banning the taking of upskirt photos.
It isn't about the cat.
I don't think that is true. There are precedents where the taking or the publication of pictures of somebody in a public place have been judged to be an invasion of privacy.
In any case, the framework and laws that we have for privacy come from an age where we didn't have instant, in-a-whim access to massive amounts of information of different modalities (text records of many kinds, satellite imagery, street maps, street-level photos), carefully correlated to each other, through a simple web search. This changes the risk/benefit analysis involved in your privacy choices. Think how the case for whether to leave your blinds open (because you like natural light, and hate darkness) has been affected by technology over the years:
I draw the line at the last of these cases. The fact that an observer at the right place and time might be able to look in your window while something you didn't want them to see happened, and even the fact that the observer may take a picture, post it in the internet, and have it spread to millions of people through word of mouth, doesn't give the right to a private, profit-driven entity like Google to systematically take and gather such pictures (that make it possible to see what's going on inside random, arbitrary people's windows) and make them available in a publically accessible, searchable, intermodal database that correlates them with other such pictures and information of many other kinds. Keeping your blinds open should indeed be a risky proposition, but people and companies should be forbidden from exploiting that risk, and most importantly, from magnifying that risk.
Why are you telling me all that? I don't disagree that concurrent programming shouldn't be any harder than other kinds of programming. All I said was that all the amateur psychology and neuroscience that people were spouting in this thread was irrelevant to the question.
Other than that, yes, data-flow synchronization makes concurrent programming way easier.
You're thinking of how to speed up programs by using parallel execution units. This is closely related, but not exactly the same thing, as the use of concurrent programming techniques to write better organized programs capable of responding flexibly to events from multiple sources while also performing their own "background" computations. Think of a UI program that must simultaneously react to user interaction events, while also performing some computation that's mostly independent of user input. A word processor that does grammar checking in the background while the user interacts with the UI in other ways is a prime example.
The thing is that with mainstream languages, writing programs like this is probably much harder than it needs to be, for several reasons:
Here's one way of solving this problem: (a) lightweight threading mechanisms for concurrency (in addition to the heavyweight ones for parallelism), (b) no shared mutable memory between threads (any shared memory must be immutable), and (c) simpler thread synchronization primitives that do not rely on shared mutable memory, like communication channels between threads.
Our cognitive system does many things at the same time, yes. That doesn't answer the question that's being posed here: whether explicit, conscious reasoning about parallel processing is hard for people.