CompuServe charged per-minute rates. Competing purely on "better" is a lot harder than competing on "cheaper". Prodigy still provides email services to this day, AFAIK, and is wholly owned and operated by AT&T.
Assuming a couple of bucks CPM, the average Facebook user probably sees at least ten to fifteen ads per day, or about $7 to $11 per account per year. And that may be a low estimate. It's not really that much of a stretch to assume that Facebook will still be popular in twenty years.
And that's ignoring income from all other sources besides pure advertising.
For example, if its true that their takedown is by URL, but they duplicate based on hash (so one can have multiple URLs for the same file), thats clearly attempting to game the system, as any legitimate takedown system would take down all separate URLs which point to the same file. (Paragraph 23 on the indictment). Especially if this is related to the creation of a "dummy lifetime premium user" to "to prevent the loss of source files due to expiration or abuse reports" (from a Megaupload email).
Wrong. The DMCA puts the onus on the copyright holder to provide enough information to identify the offending material, not the service provider. A legitimate takedown system would take down the URL they request be taken down, and no more.
The reason this is crucial is that deduplication is an established technique for preventing data redundancy, and does its job without regard to who uploaded the content or how it is being used. It is not at all a given that every copy of a file uploaded by multiple people is equally infringing.
For example, you and I both buy a copy of a movie. We each have the right to make a backup. I make my backup and upload it to a sharing site, but mark it "for my eyes only". This is still a backup. You do the same, but mark it "public" and post the URL to a bunch of pirated movie bulletin boards or whatever. This is no longer a backup. Your data and mine are, or at least should be, identical because they were ripped from the same DVD. They are deduplicated to the same underlying hash. When the copyright owner complains about that URL, your copy must come down. However, if my copy comes down as well, that would be illegal destruction of my personal property, and would subject both companies to civil (and possibly criminal) liability.
Taken one step further, I might have a relationship with the copyright holder that allows me to redistribute a copy of that movie to my clients. I might make that URL "public" (accessible without my password), but I might not publish the URL except in the form of sending it to my clients. That is still not a copyright violation. However, it is still technically a publicly shared URL. When yours gets taken down, mine must not, or else it is tortious interference. Yet there is absolutely no difference, as far as the sharing service is concerned, between those two URLs. Both are public. Both are backed by the same tag.
The DMCA requires that the requested URL be taken down, not every possible copy of the content in question. Any representation to the contrary is a misrepresentation of the law, and would render infeasible the standard operating procedures for large, shared server farms.
Don't get me wrong; I'm not saying that these sites aren't sleazy operators that knowingly distributed copyright-infringing material. However, their following of the DMCA to the letter to the law (and no further) should not be considered evidentiary support for such an argument.
* Give people easy ways to navigate through information provided by their device apps via a separate control window with tabs;
Nook doesn't have any real notion of windows. It's a tablet-based OS.
* Enable display of a webpageâ(TM)s content before the background image is received, allowing users to interact with the page faster;
Nook doesn't support background images except in the browser. And in that case, I'm pretty sure Netscape has prior art. Unfortunately, none of the sites talking about these patents seem to post the full patent numbers, so all we can really do is speculate.
* Allow apps to superimpose download status on top of the downloading content;
So they have a patent on showing the status bar in a different place on the screen? Because there is no functional difference in the way such a bar is drawn, any such patent, if it is not a design patent, should be ruled invalid. If it is a design patent... well, then they'll just have to change their design so that it doesn't do that.
* Permit users to easily select text in a document and adjust that selection; and
No idea if there is prior art without seeing the patent number.
* Provide users the ability to annotate text without changing the underlying document.
I have a hard time believing Adobe doesn't have patents that are prior art....
You act as if capital gains taxes are INSTEAD of the 30% or whatever. But they are ON TOP OF. Government's already taken income tax out of my money when I then go and consider taking some of it and investing it instead of spending or hoarding it. Then capital gains taxes takes even more of my money. It's a SECOND tax. And it's a tax that discourages investment.
It's only a second tax if you pay the tax on the money you invested. You do not. You pay taxes on the gains, just as you would pay taxes on the interest if you put that money in a savings account, just as you would pay taxes on the gains if you used it to buy a house, then sold it for a profit, etc. Just be glad you're not also paying sales tax on every transaction. That would be a second tax on the money you already made....
Hmph. Now that you mention it, charging sales tax on stock sales would effectively eliminate the day trading that has turned the stock market into a festering cesspool.... Maybe that's not such a bad idea.
Just to clarify, the cloud is a great tool for some things. iCloud is an example of the right use of the cloud. It's a temporary repository for sharing information between multiple devices. If the cloud goes away, you still have a local copy of the app and a bunch of local copies of your data. You just lost syncing.
Sharing sites like Megaupload are also examples of the right use for the cloud, so long as you understand that they are temporary locations to store stuff that you want to share with others. The moment you start putting up links to them on permanent websites, you've gone off the cliff into "bad use of the cloud" territory. Unfortunately, far too often, people use these temporary repositories when they should be setting up their own permanent repositories. This invariably leads to damages all around.
For example, I was recently looking for some modified firmware for rooting an embedded device, and the first two links were to sites like Megaupload that had been recently taken down by the U.S. government. Three things made this interesting:
It's perfectly legal content for me to download (since I own the hardware and already have the stock firmware without the extra pieces added, and the authors of the extra pieces have the legal right to distribute those pieces). The courts have ruled fairly conclusively on this point on multiple occasions, though I don't have time to dig up the relevant case law.
It is slightly dubious whether the people who uploaded them have the right to redistribute them (since A. it could theoretically be downloaded by someone who doesn't own the hardware in question, not that it would be particularly useful to do so, and B. it is technically an unauthorized derivative work). Presumably to protect themselves somewhat from liability, they therefore chose a bunch of legally dubious sharing sites to host the content.
Either way, the content was taken down not because the company that made the device objected, but because it was caught up in the fringes of an FBI sting on movie uploaders and other stupid bulls**t that had nothing to do with the content in question.
On the one hand, technically the FBI's sting operation took down an unauthorized reposting of copyrighted material. On the other hand, the FBI's sting operation did so without the consent or action of the copyright owner, in a manner that was detrimental to the ability of people who legally own a licensed copy of the content in question to use that content in a manner consistent with U.S. copyright law.
Copyright law is a freaking mess, and it's high time the government stopped misusing our law enforcement to take care of what should be properly handled by complex civil suits between the copyright holders and the sites in question, and, more to the point, to attack valuable shared resources in a way that harms the Internet, deliberately ignoring the legally compliant take-down procedures that were already in place. In effect, when they failed to pass SOPA and PIPA, the government decided to sidestep DMCA protection in a different way, and a lot of people—myself included—got caught in the crossfire.
Of course, the reason so many abusive companies and organizations push the government to do their dirty work is that they know they have a good chance of losing the court case, because the company they're suing was, in fact, compliant with the law as written. If they get a bunch of jack-booted thugs to knock the door down, they don't have to care about what's legal or just. They get to shut down the site without regard to whether or not they had the legal right to do so. Hence, the government absolutely should not ever do this.
To any lawyers who decide to file a class action against the FBI for this action, please add me to the list of innocent parties harmed by their action. The FBI should absolutely be held liable for all of the cumulative collateral damage that their actions have caused, however small each individual instance of that damage might be.
You can lose your stuff. It's not as easy as we fear, but the Megaupload situation shows that it is not as hard as we had hoped.
And this is why I will never trust a server that I do not physically control (and back up) to have the primary copy of any of my data. This is also why I will never trust cloud computing. It was a bad idea when Larry Ellison proposed it fifteen years ago, and it's still a bad idea today, and for exactly the same reasons.
I don't know about anybody else, but if and when I use an online site to price check stuff like movies, I'm already in the store intending to buy two or three movies, so it doesn't cause me to not buy movies. It just helps me decide which two or three movies to buy that day, and which ones to defer or buy elsewhere.
For expensive stuff, though, you either price match or you've lost the sale, period, because most people don't buy products that cost a hundred bucks and up without having a general idea of how much they should cost online. If you think you can fool people with altered model numbers or special Target-specific versions, you're kidding yourself. Most customers don't even notice model year changes, much less minor variations in model. What the average consumer notices is that your 27" Samsung TV costs a hundred bucks more than Amazon's 27" Samsung TV. And as long as that is true, you've lost the sale.
The problem is not that this particular game limits those extra features to the original owner. The problem is that it's a slippery slope. First you allow the game companies to limit the downloadable content to the original owner. Then the game companies start putting less and less content on the discs, claiming that the rest wasn't quite ready in time. Before long, you've got games coming out that don't do anything unless you're the original buyer.
Thus, the only way to prevent the continued erosion and eventual destruction of the right of first sale is to nip it in the bud now and refuse to buy games that start the industry heading down that slippery slope.
You're on the right track. The "should of" abuse is largely a side effect of the way we learn English as a primary language. Native English speakers learn English first by speech (from their parents, from TV, whatever) before they learn to read.
The problem comes because so many speakers use the contracted form of "should have". The words "should've" and "should of" sound nearly identical unless you are deliberately exaggerating the latter. Therefore, by the time kids learn the correct spelling, "should have", they have been hearing "should've" and interpreting it as "should of" for many years. It is already ingrained in their vocabulary, and is thus hard to unlearn.
Because it's not pointless. I don't know if you're familiar with the concept of cognitive load, but it applies here. Put into terms that geeks can understand, we each have a finite amount of CPU power, and if we waste it on doing meaningless reinterpretation, then it isn't available to use for other things.
In general, the less energy and mental effort we expend on communication, the more we can spend on actually thinking about what is being communicated. In theory, from the perspective of the person speaking/writing, ideal communication occurs when the speaker/author spends little to no effort on the communication. However, this results in excessive effort on the part of the person listening/reading, which results in decreased understanding. By contrast, from the perspective of the listener/reader, ideal communication occurs when the speaker/author has done all the work to ensure easy understandability, resulting in low cognitive load for the reader.
However, the two parties in communication are not always equally impacted by cognitive load, particularly in verbal communication. As a speaker, you already have a pretty good idea what you are going to say. The extra cognitive load from communicating it clearly is therefore largely unimportant unless it becomes so heavy that you forget what you were saying halfway through.
By contrast, if the listener has to spend more effort parsing the sentence, the listener has a harder time putting the words into their proper context. Worse, the listener can only spend so much time understanding part of a sentence before he/she misses the next thing being said. It's not nearly as easy to go back and re-parse a spoken sentence as it is to re-parse a written sentence.
This is why, for example, when you listen to a heavily accented speaker, even though you can understand the individual words that he/she is saying, you will inevitably have a harder time actually doing anything with that information because you're spending all your mental capacity just trying to identify the words themselves. This is why, when listening to a conversation in a foreign language, it helps to pause at the end of each sentence to let your brain digest what was actually said. And so on.
The right balancing point depends on the nature of the communication. In technical communication, and in most forms of professional communication, the onus is on the author to communicate precisely. Similarly, when sending something up the chain of command to your boss's boss's boss's boss, precision and concision are absolutely critical because your CEO or CO or whatever is likely to just skim it. When sending email messages to friends or posting on message boards, you generally want to be precise enough to get the message across without getting bogged down in the details. Finally, If you want to look like an idiot, you send a message laced with awful grammar, poor spelling, etc. Because of its effect on the reader, there is really no situation in which that is acceptable unless you truly cannot take the time to do a better job, e.g. a war correspondent hiding in a ditch during a bombing attack or squeezing off a quick IM while sitting at a traffic light.
Other than patent lawsuits, there's no way to prevent duplication and counterfeiting of physical goods, either. Don't believe me? Check out the Chinese microphone manufacturers that slavishly copied the patented Royer offset ribbon design just a few years back. Check out all the fake iPod look-alikes. All the fake Prada bags. And so on.
Sure, most of the fakes aren't remotely exact, but that's not because they can't be made exact. Many cases of counterfeit products actually involve manufacturing plants making extra units past the end of the manufacturing run, and selling them as legitimate products. In those cases, they are in every way actual instances of that physical product, but not legally produced instances of that physical product. There is no feasible way for such fakes to be detected once they get out on the market. Or individuals buy up refurbished repair parts and assemble a counterfeit unit from parts that is indistinguishable or nearly indistinguishable from the real thing.
So again, I reiterate, it is not possible to absolutely verify that a physical good is a legally manufactured copy, either.
It may be statistically small, but folks like me are also statistically unlucky (five dead hard drives in one year, zero laptops that made it out of warranty before their first failure, a Roomba whose motor gears broke the third time I used it—out of warranty, but only because I didn't use it enough—and a car at 110k that has a rebuilt transmission, a new starter gear on the front of the transmission, a rebuilt power steering pump, a rebuilt steering rack, new seals throughout the top half of the engine, a new metal coolant line, a new front valve cover, and now needs a new rear body control module because the door locks, the driver's side window, and the right rear blinker no longer work... oh, and it has a vacuum leak now, I think), so it cancels out.
You can't resell something that cannot be adequately protected through DRM, period.
Sure you can. It's actually quite easy. You're missing a fairly fundamental concept, which is this: what is necessary to prevent playback of copies is not required to merely prevent sale of those copies. To do the former, it must be impossible to get a decryption key without proving that you are the current owner. This is fundamentally impossible to do in an unbreakable way, and the harder you try, the worse the customer experience is. By contrast, to do the latter, you need only the ability to uniquely identify each sold copy of a file. This requires nothing more than a guarantee from the companies that sell the original tracks that there will never be two identical copies of the track, plus a verifiable, ideally signed marker of some sort to determine authenticity.
In other words, to support resale of commercially-sold tracks, you need only take advantage of the watermarks that most or all of those services put in the tracks to begin with. Tracks are usually sold with additional info in the track's metadata that ties it to a particular user's account so that if it gets pirated, it can be traced back to the person who illegally distributed it.
This means that every digital download is unique and trivially verifiable as authentic or inauthentic without the need for actual DRM that would limit your ability to play the file. Thus, all that is necessary is a central database that every reseller talks to, in which the current ownership of every track that gets sold is tracked based on which account purchased it originally.
At least I'm assuming this is how they're doing it. It's certainly the most straightforward and obvious way to do it.
What this does not do, of course, is prevent you from making a copy before you sell the track. However, resale of physical CDs and DVDs has exactly the same problem, making this argument largely irrelevant as far as drawing a legal distinction between the two types of resale.
There's no way to enforce it for a physical good, either, which is why there are so many pirated DVDs out there for sale on used DVD sites.
Further, even if you have someone examining the DVD looking for special seals of authenticity and other such silliness, there is absolutely nothing stopping someone from making a copy, then selling the original.
In other words, digital sales are digital sales, and in terms of the potential for abuse, there is no significant difference between reselling a purchased MP3 or AAC file and reselling a purchased DVD or CD other than possibly the need for additional centralized policing to ensure that you can't sell the same track more than once unless you can prove that you paid for it more than once.
They were banned from Amtrak property for a while, too, after one of their little stunts. To the extent that they are allowed at all, it is at the sole pleasure and discretion of the Amtrak Police, who have final authority over the operation of the entire system, including all aspects of security. If they cross the line, they have been, and will continue to be, escorted off the premises.:-)
No, it won't. Not as long as you have the option of private insurance to supplement what the government will cover, or paying for things the government won't cover out-of-pocket.
What makes the TSA so insidious is that you don't have the option of flying through a no-bulls**t airport... unless you can afford to own your own private jet. It took over security, and did so in a draconian way, without allowing any other voices to participate in the discussion—any other players to participate in the day-to-day operations—any other alternatives short of choosing a radically different form of transit (which, incidentally, is probably the main reason Amtrak ridership has increased by almost 30% since September 11th after being nearly flat for the twenty years previous).
Besides, when the government health care does it, they are checking for disease....:-D Turn your head and cough, please.
The big difference is that I don't have to build the commercial software in order to use it. They can distribute binaries because they build binary backwards compatibility into their library/framework/OS design so that as long as you keep calling the same function with the same name, you'll keep getting the same behavior.
By contrast, with open source, binary distributions are often few and far between, and even if they exist, a binary linked against an old version of a library won't run against a newer version or vice-versa because the designers don't treat headers as a long-term API contract. Suddenly, the function call used to perform a critical operation takes nine parameters instead of seven, and even though the two new parameters can be NULL, you still get to patch the code by hand before the code will build.
The result is that the 32-bit commercial app still works, albeit slowly and clumsily, on a 64-bit system (because most OSes can support both 64-bit and 32-bit binaries on the same system). The 32-bit open source app requires to you monkey around with makefiles for an hour just to convince it to build using the 32-bit compiler, after which you get to back-port all the calls to libraries whose interfaces changed.
No, the commercial software world generally does not have problems on that order of magnitude. Maybe the worst of the worst, but 99% of my commercial software form 5 years ago still runs correctly. Much of the open source software I've downloaded from five years ago won't even compile, much less run, because of the sheer number of incompatible API changes.
Packets take different routes, and arrive at different times. Frequently out of order. You're not pouring marbles into pipes.
None of which is relevant to the discussion of what happens when a crucial link between the two sources and the two destinations is saturated. Most ISPs have a limited number of outbound pipes, and cable modem bandwidth is shared among all the households on the local loop. These are all finite resources shared among a number of houses, and the fact that the packets can be routed in different directions only matters if there's another route that they can take.
And even if there are multiple routes, the capacities of the multiple outgoing pipes sum up to some fixed value, and the total throughput through all of those pipes cannot exceed that total capacity. Up until you hit that wall, you have no need to artificially add latency to packets. Once you hit that wall, adding latency becomes functionally identical to throttling the connection. And that was my point. Using a single pipe is a serious oversimplification for analogy purposes, but the exact same problems still come up even if you have a thousand pipes.
As for your complaint about the pipe analogy, I'd argue that it is actually a rather good analogy, so long as you use something discrete like marbles instead of continuous like water. Admittedly, most of the queueing is occurring in a router rather than in the wire itself, but the same basic principle holds—that the data rate going out can't exceed the maximum throughput of the wire it's going into. And, of course, when you're talking about a satellite hop (speaking of latency hell), because of the distances involved, even the distinction about where data is queued goes away; there are almost invariably multiple marbles... err... packets... in a satellite-based pipe at any given time. It's the only way you can usefully use a high latency connection. Otherwise, the latency results in one request backing up behind another response, and your available bandwidth just plain falls apart....
Which brings us to the bigger problem, which is that TCP does not work particularly well over high latency connections, and HTTP doubly so (hence the need for alternatives like SPDY). Therefore, adding latency can hurt the effective bandwidth far more than the packet delays by themselves otherwise would... but that's another discussion for a different thread....
Good thing some of us like to actually do things for fun every now and then. The Open Source philosophy isn't about making money, it's about sharing knowledge.
No disagreement. That's certainly why I write open source. That and because I need to get things done anyway, so I might as well make it available in case it can help somebody else.
That said (and I'm probably going to get modded down for this), this is also one of the reasons why there is so much open source software out there that is of lesser quality than similar commercial software. Make no mistake, there are plenty of great open source apps and drivers and kernels and daemons out there, but for every one that's a gem, there are a hundred more that are so-so, and a thousand more that are complete crap. The reason for this is, to a large extent, because most of the folks working on it are creating things for fun, for themselves, whatever, and when they get things working well enough to do the job, they do no further work on the project. The result is a whole truckload of abandonware.
More importantly, because the developers often just need to get something working well enough to get something done, maintainability is often the last thing on their minds, resulting in some incredibly bad code. I've seen copious amounts of code in fairly significant open source projects over the years that was so bad, it made me want to cry.
I actually had such an experience just a couple of days ago (on a project that will remain nameless), with code that pre-defined macros for things like SIZEOF_LONG instead of just doing sizeof(long), resulting in the absolute inability to do single-pass compilation of multi-architecture (fat) binaries until I ripped all that crap out. I would have understood that sort of thing ten years ago, but this was top-of-tree in their git repo. Apparently nobody told these developers that there is exactly zero runtime penalty to using sizeof(), and thus absolutely no good reason to predefine macros with hard-coded sizes.... *sigh*
Of course, these sorts of problems occur in the commercial world as well, but the abandonware is more common in the open source world, largely because the barriers to entry are so much lower. You don't have to hire a team of ten people to develop an open source tool—you just write it in your spare time—so there's no real financial incentive not to abandon it when you no longer need to use it yourself, and there's no real financial incentive to ensure that the software is portable, maintainable, or extensible.
Admittedly, the abandonware is less catastrophic in the open source world because you can ostensibly fix it yourself, at least up to the point where code rot makes this impractical, but combined with the open source community's apparent disdain for API contracts and backwards compatibility guarantees, code rot hits open source a lot faster than closed source, which counteracts much of that benefit after only a few years. Just last week, I encountered some fairly fundamental API breakage while updating software written only about a year or two ago, to the point that it required some serious backporting to make things even compile—the function name was the same, but with a very different list of parameters, data types, etc. That's just unacceptable, and leads to serious long-term maintainability problems for anyone who isn't willing to constantly live on the bleeding edge of everything.
And then, there's the general sloppiness of data types. Good code doesn't use types like int or long most of the time, because you can't rely on their sizes. That's why we have inttypes.h. No code that has been touched in the past five years should be using those data types, period, because the results are simply not portable. Yet as recently as a few days ago, I ran into "assert(sizeof(long) == sizeof(uint32_t));". Not even a compile-time failure. A runtime failure. Like I said, some of th
Maintaining a constant altitude, and thus preventing the balloon bursting, would be very cool.
AFAIK, that should be pretty easy. Just add ballast. Remember those helium-filled toy balloons that you can fly up and down with fans? They work because at the current altitude, the ballast approximately counterbalances the amount of lift that the balloon provides.
The amount of lift caused by lighter-than-air balloons is proportional to what's around it. Unweighted (and assuming a theoretical zero-mass balloon, zero-mass helium, and a spherical horse), it would rise until the point where the density of the air outside is equal to the density of the gas inside. Weighted, it rises up until the force applied by that density difference over its surface area becomes equal to the mass of the balloon and whatever is hanging under it.
Thus, the only reason the balloons burst is that they don't weigh enough to stop rising at a lower altitude. If they did, they'd just stay there at that altitude until the helium leaks out.
Alternatively, you can use a material that does not stretch as much. One of the reasons that balloons continue to rise beyond a certain point is that they expand at high altitude, thus lowering the density inside. If you limit the stretch, you limit the degree to which they can expand, making the density inside balance the density outside much sooner. Thus, they stop rising sooner (and they also don't explode because they don't ever get that thin).
Either way, there's just one problem: if they don't burst, they could potentially drift for thousands of miles over the course of several days (or even weeks) before they came down, and they could come down anywhere, at any time, into the engine of any passing aircraft, which is probably not what you want, hence the reason this is not typically done.
Hello, Senator. I'm glad you could meet with me. I wanted to talk to you about an... anomaly we noticed with your gmail account. It seems that all of those racy emails you've been sending to your intern—you know, the 15-year-old son of your biggest donor—somehow made their way into a mail queue that is scheduled for delivery to your wife and her divorce attorney some time tomorrow.
Now I know what you're thinking. How could this happen? We're not really sure. The point is that it has happened. We can make sure those messages never get delivered by deleting the queue, which we'll do, but we need something from you, too. Good. I'm glad we could come to an understanding.
Otherwise, it will be the ISP that will shit all over your SIP connection because they want to sell their own VOIP solution.
Doing so would violate net neutrality by prioritizing one service over another service of the same basic type. You don't have to mandate basic round-robin scheduling to avoid the problem you're describing here. All RR scheduling does is ensure that during periods of high demand, neither VoIP solution works instead of both of them working.
Slashdot Mirror
CompuServe charged per-minute rates. Competing purely on "better" is a lot harder than competing on "cheaper". Prodigy still provides email services to this day, AFAIK, and is wholly owned and operated by AT&T.
Assuming a couple of bucks CPM, the average Facebook user probably sees at least ten to fifteen ads per day, or about $7 to $11 per account per year. And that may be a low estimate. It's not really that much of a stretch to assume that Facebook will still be popular in twenty years.
And that's ignoring income from all other sources besides pure advertising.
Wrong. The DMCA puts the onus on the copyright holder to provide enough information to identify the offending material, not the service provider. A legitimate takedown system would take down the URL they request be taken down, and no more.
The reason this is crucial is that deduplication is an established technique for preventing data redundancy, and does its job without regard to who uploaded the content or how it is being used. It is not at all a given that every copy of a file uploaded by multiple people is equally infringing.
For example, you and I both buy a copy of a movie. We each have the right to make a backup. I make my backup and upload it to a sharing site, but mark it "for my eyes only". This is still a backup. You do the same, but mark it "public" and post the URL to a bunch of pirated movie bulletin boards or whatever. This is no longer a backup. Your data and mine are, or at least should be, identical because they were ripped from the same DVD. They are deduplicated to the same underlying hash. When the copyright owner complains about that URL, your copy must come down. However, if my copy comes down as well, that would be illegal destruction of my personal property, and would subject both companies to civil (and possibly criminal) liability.
Taken one step further, I might have a relationship with the copyright holder that allows me to redistribute a copy of that movie to my clients. I might make that URL "public" (accessible without my password), but I might not publish the URL except in the form of sending it to my clients. That is still not a copyright violation. However, it is still technically a publicly shared URL. When yours gets taken down, mine must not, or else it is tortious interference. Yet there is absolutely no difference, as far as the sharing service is concerned, between those two URLs. Both are public. Both are backed by the same tag.
The DMCA requires that the requested URL be taken down, not every possible copy of the content in question. Any representation to the contrary is a misrepresentation of the law, and would render infeasible the standard operating procedures for large, shared server farms.
Don't get me wrong; I'm not saying that these sites aren't sleazy operators that knowingly distributed copyright-infringing material. However, their following of the DMCA to the letter to the law (and no further) should not be considered evidentiary support for such an argument.
In order:
Nook doesn't have any real notion of windows. It's a tablet-based OS.
Nook doesn't support background images except in the browser. And in that case, I'm pretty sure Netscape has prior art. Unfortunately, none of the sites talking about these patents seem to post the full patent numbers, so all we can really do is speculate.
So they have a patent on showing the status bar in a different place on the screen? Because there is no functional difference in the way such a bar is drawn, any such patent, if it is not a design patent, should be ruled invalid. If it is a design patent... well, then they'll just have to change their design so that it doesn't do that.
No idea if there is prior art without seeing the patent number.
I have a hard time believing Adobe doesn't have patents that are prior art....
It's only a second tax if you pay the tax on the money you invested. You do not. You pay taxes on the gains, just as you would pay taxes on the interest if you put that money in a savings account, just as you would pay taxes on the gains if you used it to buy a house, then sold it for a profit, etc. Just be glad you're not also paying sales tax on every transaction. That would be a second tax on the money you already made....
Hmph. Now that you mention it, charging sales tax on stock sales would effectively eliminate the day trading that has turned the stock market into a festering cesspool.... Maybe that's not such a bad idea.
Why shouldn't you prepare your food for the difficult process of being digested?
Just to clarify, the cloud is a great tool for some things. iCloud is an example of the right use of the cloud. It's a temporary repository for sharing information between multiple devices. If the cloud goes away, you still have a local copy of the app and a bunch of local copies of your data. You just lost syncing.
Sharing sites like Megaupload are also examples of the right use for the cloud, so long as you understand that they are temporary locations to store stuff that you want to share with others. The moment you start putting up links to them on permanent websites, you've gone off the cliff into "bad use of the cloud" territory. Unfortunately, far too often, people use these temporary repositories when they should be setting up their own permanent repositories. This invariably leads to damages all around.
For example, I was recently looking for some modified firmware for rooting an embedded device, and the first two links were to sites like Megaupload that had been recently taken down by the U.S. government. Three things made this interesting:
On the one hand, technically the FBI's sting operation took down an unauthorized reposting of copyrighted material. On the other hand, the FBI's sting operation did so without the consent or action of the copyright owner, in a manner that was detrimental to the ability of people who legally own a licensed copy of the content in question to use that content in a manner consistent with U.S. copyright law.
Copyright law is a freaking mess, and it's high time the government stopped misusing our law enforcement to take care of what should be properly handled by complex civil suits between the copyright holders and the sites in question, and, more to the point, to attack valuable shared resources in a way that harms the Internet, deliberately ignoring the legally compliant take-down procedures that were already in place. In effect, when they failed to pass SOPA and PIPA, the government decided to sidestep DMCA protection in a different way, and a lot of people—myself included—got caught in the crossfire.
Of course, the reason so many abusive companies and organizations push the government to do their dirty work is that they know they have a good chance of losing the court case, because the company they're suing was, in fact, compliant with the law as written. If they get a bunch of jack-booted thugs to knock the door down, they don't have to care about what's legal or just. They get to shut down the site without regard to whether or not they had the legal right to do so. Hence, the government absolutely should not ever do this.
To any lawyers who decide to file a class action against the FBI for this action, please add me to the list of innocent parties harmed by their action. The FBI should absolutely be held liable for all of the cumulative collateral damage that their actions have caused, however small each individual instance of that damage might be.
And this is why I will never trust a server that I do not physically control (and back up) to have the primary copy of any of my data. This is also why I will never trust cloud computing. It was a bad idea when Larry Ellison proposed it fifteen years ago, and it's still a bad idea today, and for exactly the same reasons.
I don't know about anybody else, but if and when I use an online site to price check stuff like movies, I'm already in the store intending to buy two or three movies, so it doesn't cause me to not buy movies. It just helps me decide which two or three movies to buy that day, and which ones to defer or buy elsewhere.
For expensive stuff, though, you either price match or you've lost the sale, period, because most people don't buy products that cost a hundred bucks and up without having a general idea of how much they should cost online. If you think you can fool people with altered model numbers or special Target-specific versions, you're kidding yourself. Most customers don't even notice model year changes, much less minor variations in model. What the average consumer notices is that your 27" Samsung TV costs a hundred bucks more than Amazon's 27" Samsung TV. And as long as that is true, you've lost the sale.
The problem is not that this particular game limits those extra features to the original owner. The problem is that it's a slippery slope. First you allow the game companies to limit the downloadable content to the original owner. Then the game companies start putting less and less content on the discs, claiming that the rest wasn't quite ready in time. Before long, you've got games coming out that don't do anything unless you're the original buyer.
Thus, the only way to prevent the continued erosion and eventual destruction of the right of first sale is to nip it in the bud now and refuse to buy games that start the industry heading down that slippery slope.
You're on the right track. The "should of" abuse is largely a side effect of the way we learn English as a primary language. Native English speakers learn English first by speech (from their parents, from TV, whatever) before they learn to read.
The problem comes because so many speakers use the contracted form of "should have". The words "should've" and "should of" sound nearly identical unless you are deliberately exaggerating the latter. Therefore, by the time kids learn the correct spelling, "should have", they have been hearing "should've" and interpreting it as "should of" for many years. It is already ingrained in their vocabulary, and is thus hard to unlearn.
Because it's not pointless. I don't know if you're familiar with the concept of cognitive load, but it applies here. Put into terms that geeks can understand, we each have a finite amount of CPU power, and if we waste it on doing meaningless reinterpretation, then it isn't available to use for other things.
For example: awareness test 1 and awareness test 2.
In general, the less energy and mental effort we expend on communication, the more we can spend on actually thinking about what is being communicated. In theory, from the perspective of the person speaking/writing, ideal communication occurs when the speaker/author spends little to no effort on the communication. However, this results in excessive effort on the part of the person listening/reading, which results in decreased understanding. By contrast, from the perspective of the listener/reader, ideal communication occurs when the speaker/author has done all the work to ensure easy understandability, resulting in low cognitive load for the reader.
However, the two parties in communication are not always equally impacted by cognitive load, particularly in verbal communication. As a speaker, you already have a pretty good idea what you are going to say. The extra cognitive load from communicating it clearly is therefore largely unimportant unless it becomes so heavy that you forget what you were saying halfway through.
By contrast, if the listener has to spend more effort parsing the sentence, the listener has a harder time putting the words into their proper context. Worse, the listener can only spend so much time understanding part of a sentence before he/she misses the next thing being said. It's not nearly as easy to go back and re-parse a spoken sentence as it is to re-parse a written sentence.
This is why, for example, when you listen to a heavily accented speaker, even though you can understand the individual words that he/she is saying, you will inevitably have a harder time actually doing anything with that information because you're spending all your mental capacity just trying to identify the words themselves. This is why, when listening to a conversation in a foreign language, it helps to pause at the end of each sentence to let your brain digest what was actually said. And so on.
The right balancing point depends on the nature of the communication. In technical communication, and in most forms of professional communication, the onus is on the author to communicate precisely. Similarly, when sending something up the chain of command to your boss's boss's boss's boss, precision and concision are absolutely critical because your CEO or CO or whatever is likely to just skim it. When sending email messages to friends or posting on message boards, you generally want to be precise enough to get the message across without getting bogged down in the details. Finally, If you want to look like an idiot, you send a message laced with awful grammar, poor spelling, etc. Because of its effect on the reader, there is really no situation in which that is acceptable unless you truly cannot take the time to do a better job, e.g. a war correspondent hiding in a ditch during a bombing attack or squeezing off a quick IM while sitting at a traffic light.
Other than patent lawsuits, there's no way to prevent duplication and counterfeiting of physical goods, either. Don't believe me? Check out the Chinese microphone manufacturers that slavishly copied the patented Royer offset ribbon design just a few years back. Check out all the fake iPod look-alikes. All the fake Prada bags. And so on.
Sure, most of the fakes aren't remotely exact, but that's not because they can't be made exact. Many cases of counterfeit products actually involve manufacturing plants making extra units past the end of the manufacturing run, and selling them as legitimate products. In those cases, they are in every way actual instances of that physical product, but not legally produced instances of that physical product. There is no feasible way for such fakes to be detected once they get out on the market. Or individuals buy up refurbished repair parts and assemble a counterfeit unit from parts that is indistinguishable or nearly indistinguishable from the real thing.
So again, I reiterate, it is not possible to absolutely verify that a physical good is a legally manufactured copy, either.
It may be statistically small, but folks like me are also statistically unlucky (five dead hard drives in one year, zero laptops that made it out of warranty before their first failure, a Roomba whose motor gears broke the third time I used it—out of warranty, but only because I didn't use it enough—and a car at 110k that has a rebuilt transmission, a new starter gear on the front of the transmission, a rebuilt power steering pump, a rebuilt steering rack, new seals throughout the top half of the engine, a new metal coolant line, a new front valve cover, and now needs a new rear body control module because the door locks, the driver's side window, and the right rear blinker no longer work... oh, and it has a vacuum leak now, I think), so it cancels out.
Sure you can. It's actually quite easy. You're missing a fairly fundamental concept, which is this: what is necessary to prevent playback of copies is not required to merely prevent sale of those copies. To do the former, it must be impossible to get a decryption key without proving that you are the current owner. This is fundamentally impossible to do in an unbreakable way, and the harder you try, the worse the customer experience is. By contrast, to do the latter, you need only the ability to uniquely identify each sold copy of a file. This requires nothing more than a guarantee from the companies that sell the original tracks that there will never be two identical copies of the track, plus a verifiable, ideally signed marker of some sort to determine authenticity.
In other words, to support resale of commercially-sold tracks, you need only take advantage of the watermarks that most or all of those services put in the tracks to begin with. Tracks are usually sold with additional info in the track's metadata that ties it to a particular user's account so that if it gets pirated, it can be traced back to the person who illegally distributed it.
This means that every digital download is unique and trivially verifiable as authentic or inauthentic without the need for actual DRM that would limit your ability to play the file. Thus, all that is necessary is a central database that every reseller talks to, in which the current ownership of every track that gets sold is tracked based on which account purchased it originally.
At least I'm assuming this is how they're doing it. It's certainly the most straightforward and obvious way to do it.
What this does not do, of course, is prevent you from making a copy before you sell the track. However, resale of physical CDs and DVDs has exactly the same problem, making this argument largely irrelevant as far as drawing a legal distinction between the two types of resale.
There's no way to enforce it for a physical good, either, which is why there are so many pirated DVDs out there for sale on used DVD sites.
Further, even if you have someone examining the DVD looking for special seals of authenticity and other such silliness, there is absolutely nothing stopping someone from making a copy, then selling the original.
In other words, digital sales are digital sales, and in terms of the potential for abuse, there is no significant difference between reselling a purchased MP3 or AAC file and reselling a purchased DVD or CD other than possibly the need for additional centralized policing to ensure that you can't sell the same track more than once unless you can prove that you paid for it more than once.
They were banned from Amtrak property for a while, too, after one of their little stunts. To the extent that they are allowed at all, it is at the sole pleasure and discretion of the Amtrak Police, who have final authority over the operation of the entire system, including all aspects of security. If they cross the line, they have been, and will continue to be, escorted off the premises. :-)
No, it won't. Not as long as you have the option of private insurance to supplement what the government will cover, or paying for things the government won't cover out-of-pocket.
What makes the TSA so insidious is that you don't have the option of flying through a no-bulls**t airport... unless you can afford to own your own private jet. It took over security, and did so in a draconian way, without allowing any other voices to participate in the discussion—any other players to participate in the day-to-day operations—any other alternatives short of choosing a radically different form of transit (which, incidentally, is probably the main reason Amtrak ridership has increased by almost 30% since September 11th after being nearly flat for the twenty years previous).
Besides, when the government health care does it, they are checking for disease.... :-D Turn your head and cough, please.
Bummer. And I was all set to take a cheap shot at public school math education in the U.S....
The big difference is that I don't have to build the commercial software in order to use it. They can distribute binaries because they build binary backwards compatibility into their library/framework/OS design so that as long as you keep calling the same function with the same name, you'll keep getting the same behavior.
By contrast, with open source, binary distributions are often few and far between, and even if they exist, a binary linked against an old version of a library won't run against a newer version or vice-versa because the designers don't treat headers as a long-term API contract. Suddenly, the function call used to perform a critical operation takes nine parameters instead of seven, and even though the two new parameters can be NULL, you still get to patch the code by hand before the code will build.
The result is that the 32-bit commercial app still works, albeit slowly and clumsily, on a 64-bit system (because most OSes can support both 64-bit and 32-bit binaries on the same system). The 32-bit open source app requires to you monkey around with makefiles for an hour just to convince it to build using the 32-bit compiler, after which you get to back-port all the calls to libraries whose interfaces changed.
No, the commercial software world generally does not have problems on that order of magnitude. Maybe the worst of the worst, but 99% of my commercial software form 5 years ago still runs correctly. Much of the open source software I've downloaded from five years ago won't even compile, much less run, because of the sheer number of incompatible API changes.
None of which is relevant to the discussion of what happens when a crucial link between the two sources and the two destinations is saturated. Most ISPs have a limited number of outbound pipes, and cable modem bandwidth is shared among all the households on the local loop. These are all finite resources shared among a number of houses, and the fact that the packets can be routed in different directions only matters if there's another route that they can take.
And even if there are multiple routes, the capacities of the multiple outgoing pipes sum up to some fixed value, and the total throughput through all of those pipes cannot exceed that total capacity. Up until you hit that wall, you have no need to artificially add latency to packets. Once you hit that wall, adding latency becomes functionally identical to throttling the connection. And that was my point. Using a single pipe is a serious oversimplification for analogy purposes, but the exact same problems still come up even if you have a thousand pipes.
As for your complaint about the pipe analogy, I'd argue that it is actually a rather good analogy, so long as you use something discrete like marbles instead of continuous like water. Admittedly, most of the queueing is occurring in a router rather than in the wire itself, but the same basic principle holds—that the data rate going out can't exceed the maximum throughput of the wire it's going into. And, of course, when you're talking about a satellite hop (speaking of latency hell), because of the distances involved, even the distinction about where data is queued goes away; there are almost invariably multiple marbles... err... packets... in a satellite-based pipe at any given time. It's the only way you can usefully use a high latency connection. Otherwise, the latency results in one request backing up behind another response, and your available bandwidth just plain falls apart....
Which brings us to the bigger problem, which is that TCP does not work particularly well over high latency connections, and HTTP doubly so (hence the need for alternatives like SPDY). Therefore, adding latency can hurt the effective bandwidth far more than the packet delays by themselves otherwise would... but that's another discussion for a different thread....
No disagreement. That's certainly why I write open source. That and because I need to get things done anyway, so I might as well make it available in case it can help somebody else.
That said (and I'm probably going to get modded down for this), this is also one of the reasons why there is so much open source software out there that is of lesser quality than similar commercial software. Make no mistake, there are plenty of great open source apps and drivers and kernels and daemons out there, but for every one that's a gem, there are a hundred more that are so-so, and a thousand more that are complete crap. The reason for this is, to a large extent, because most of the folks working on it are creating things for fun, for themselves, whatever, and when they get things working well enough to do the job, they do no further work on the project. The result is a whole truckload of abandonware.
More importantly, because the developers often just need to get something working well enough to get something done, maintainability is often the last thing on their minds, resulting in some incredibly bad code. I've seen copious amounts of code in fairly significant open source projects over the years that was so bad, it made me want to cry.
I actually had such an experience just a couple of days ago (on a project that will remain nameless), with code that pre-defined macros for things like SIZEOF_LONG instead of just doing sizeof(long), resulting in the absolute inability to do single-pass compilation of multi-architecture (fat) binaries until I ripped all that crap out. I would have understood that sort of thing ten years ago, but this was top-of-tree in their git repo. Apparently nobody told these developers that there is exactly zero runtime penalty to using sizeof(), and thus absolutely no good reason to predefine macros with hard-coded sizes.... *sigh*
Of course, these sorts of problems occur in the commercial world as well, but the abandonware is more common in the open source world, largely because the barriers to entry are so much lower. You don't have to hire a team of ten people to develop an open source tool—you just write it in your spare time—so there's no real financial incentive not to abandon it when you no longer need to use it yourself, and there's no real financial incentive to ensure that the software is portable, maintainable, or extensible.
Admittedly, the abandonware is less catastrophic in the open source world because you can ostensibly fix it yourself, at least up to the point where code rot makes this impractical, but combined with the open source community's apparent disdain for API contracts and backwards compatibility guarantees, code rot hits open source a lot faster than closed source, which counteracts much of that benefit after only a few years. Just last week, I encountered some fairly fundamental API breakage while updating software written only about a year or two ago, to the point that it required some serious backporting to make things even compile—the function name was the same, but with a very different list of parameters, data types, etc. That's just unacceptable, and leads to serious long-term maintainability problems for anyone who isn't willing to constantly live on the bleeding edge of everything.
And then, there's the general sloppiness of data types. Good code doesn't use types like int or long most of the time, because you can't rely on their sizes. That's why we have inttypes.h. No code that has been touched in the past five years should be using those data types, period, because the results are simply not portable. Yet as recently as a few days ago, I ran into "assert(sizeof(long) == sizeof(uint32_t));". Not even a compile-time failure. A runtime failure. Like I said, some of th
AFAIK, that should be pretty easy. Just add ballast. Remember those helium-filled toy balloons that you can fly up and down with fans? They work because at the current altitude, the ballast approximately counterbalances the amount of lift that the balloon provides.
The amount of lift caused by lighter-than-air balloons is proportional to what's around it. Unweighted (and assuming a theoretical zero-mass balloon, zero-mass helium, and a spherical horse), it would rise until the point where the density of the air outside is equal to the density of the gas inside. Weighted, it rises up until the force applied by that density difference over its surface area becomes equal to the mass of the balloon and whatever is hanging under it.
Thus, the only reason the balloons burst is that they don't weigh enough to stop rising at a lower altitude. If they did, they'd just stay there at that altitude until the helium leaks out.
Alternatively, you can use a material that does not stretch as much. One of the reasons that balloons continue to rise beyond a certain point is that they expand at high altitude, thus lowering the density inside. If you limit the stretch, you limit the degree to which they can expand, making the density inside balance the density outside much sooner. Thus, they stop rising sooner (and they also don't explode because they don't ever get that thin).
Either way, there's just one problem: if they don't burst, they could potentially drift for thousands of miles over the course of several days (or even weeks) before they came down, and they could come down anywhere, at any time, into the engine of any passing aircraft, which is probably not what you want, hence the reason this is not typically done.
I can see it now.
Hello, Senator. I'm glad you could meet with me. I wanted to talk to you about an... anomaly we noticed with your gmail account. It seems that all of those racy emails you've been sending to your intern—you know, the 15-year-old son of your biggest donor—somehow made their way into a mail queue that is scheduled for delivery to your wife and her divorce attorney some time tomorrow.
Now I know what you're thinking. How could this happen? We're not really sure. The point is that it has happened. We can make sure those messages never get delivered by deleting the queue, which we'll do, but we need something from you, too. Good. I'm glad we could come to an understanding.
Doing so would violate net neutrality by prioritizing one service over another service of the same basic type. You don't have to mandate basic round-robin scheduling to avoid the problem you're describing here. All RR scheduling does is ensure that during periods of high demand, neither VoIP solution works instead of both of them working.