Next you'll tell me they invented RISC, FPU, L3 shared caching, and multi-cores? IBM paved the way to RISC and also FPU (through coprocessor). L3 caching was an Intel thing^ and multi-core design was AMD. What did Apple do? name one significant aspect to the modern processor Apple had anything to do with?
You're drawing an arbitrary line. It's possible to improve a chip design without creating a fundamental new building block that nobody else has ever built.... By your standards, the Centre Pompidou is not architecturally unique because other buildings have air ducts and water pipes.
I'd be very surprised to see Apple computers based around processors that are "Apple" in anything more than name and, possibly, specific arrangement of cookie-cutter functional units around a licensed ARM or x86 core.
Depends on what you mean by "licensed core". If you look at the history of Apple, you'll see a clear pattern: Apple licenses other people's cores or buys their chips at the end of the design process, but is quite frequently involved in designing those cores to begin with.
Let's review:
Late 1980s: Apple works with VLSI Technology and Acorn to design the ARM6.
1991-2006: Apple works with IBM and Motorola (later Freescale) to design the PowerPC processor family.
Late 2000s: Apple buys PA Semi, a fabless processor manufacturer.
Apple has a long history of working with chip vendors and adding significant functionality to their designs. Sure, those bits end up in other companies' products, but there's Apple IP in an awful lot of CPUs out there, including many of the CPUs that have appeared in Apple products over the years....
No, I don't. That would break compatibility with existing PHP-based tools, many of which already do perform adequate sanitization of queries on their own. Case in point, SQL queries into a database using exclusively numeric keys can be sanitized like this:
$id = (int)$id;
Forcing people that don't pass arbitrary user-generated data to use a different function is unnecessary and pointless; they'll just pass the exact same argument(s) they do now, but add an empty array.
Adding another optional parameter to this function would break nothing, and would provide precisely the same benefits.
If you really want people to look at their code, you could make PHP throw a warning when no array parameter is passed in, and make it possible to disable that warning site-wide so it doesn't break things. That would have the advantage of pushing developers to look at their code without breaking backwards compatibility unnecessarily. It would also have the advantage of providing a nice audit log of the offending functions in error logs so sysadmins can audit suspicious code themselves.
There are a lot of ways to make SQL injection attacks much, much harder. The simplest requires only a handful of changes:
Use a transaction around every group of commands.
Change your SQL database to disallow the comment string (--) in queries.
Don't use a published schema.
By using a transaction around command groups, you ensure that any error will cause the entire transaction to be rolled back. By disabling the comment character, you make it impossible to make the rest of the command go away and not cause an error. By using an unpublished schema (and specifically, nonstandard column names), you make it nearly impossible for someone to correctly construct a working query out of the last half of the original query. Even something as simple as prefixing every column name with a hard-to-guess string is enough to make it insanely hard to inject SQL unless you pissed off an ex-employee.
That said, I wish substitution (interpolation) were the only query form available. It's particularly annoying in PHP, where you have to roll your own (or copy and paste out of the user-provided comments in the documentation) to get the functionality at all. The array of tokens to substitute should be an optional argument to mysql_query()....
At least with an iPhone, attach the right cable and you can plug it into a high def TV and play 720p (and maybe 1080i) content at full resolution.
Even on the built-in screen, the quality is above the non-HD resolution used by YouTube, so you still get better picture quality by scaling down the high-def content than scaling up the low-res content.
Easy. YouTube high definition videos can be up to a gigabyte in size, and that's for 10 minutes of video. Are you telling me you don't think someone can possibly watch eleven hours of high definition YouTube content in a month?
65 gigabytes is rapidly becoming light use for young people with YouTube addictions. The telcos simply need to increase the size of their backhauls, period. Any attempts at capping are just going to result in lawsuits and massive numbers of very pissed off customers.
What they're not telling you is that the people pulling such huge traffic rates are doing so because they're using the phone instead of a computer, and they have no Wi-Fi access. 200 megabytes is *nothing* if you're using cellular data exclusively. That's about an hour and a half of YouTube-quality video. Want to watch a TV show or two while you're on vacation? You can rack up gigabytes of usage pretty quickly.
The thing is, if you use your phone as a media viewing platform, you're going to run up large amounts of bandwidth. For people who are used to doing that, it only takes a one week vacation somewhere without Wi-Fi to put you into that top 0.1%. Or when your Wi-Fi connection goes down and you don't notice that it's pulling data over 3G. And that's what makes this so insidious. You don't need to break the rules and tether, use BitTorrent, or violate the terms of service in any way to run afoul of a bandwidth limit. There's plenty of perfectly legitimate reasons to consume that much bandwidth, and it isn't very hard to do in a month if you aren't paying attention.
Nope, but if those proprietary forks compete against anyone doing work on the main branch
Stop right there. The vast majority of corporate contributions to open source involves companies using the open source project for a small portion of a much larger product. From the work of Apple and other companies on Clang/LLVM to the way TiVo and home router manufacturers use the Linux kernel, open source is almost always used as the basis for a significantly bigger product. The cases where an open source project and a commercial project are actually competing is almost nonexistent (with a few fairly visible exceptions like MySQL and CodeWeavers), and even then, most of the companies are good citizens and contribute fixes back to the open source project or fork and create a new open source project (e.g. WebKit).
For every case where a private fork competes with a free and open fork, I can list a hundred cases of an open source tool being used as a portion of a larger product. Thus, for every case where GPLv3 discouraged corporate privatization of the code, it discouraged a hundred companies from using the code in a way that would not compete with and potentially harm the open source project....
Chances are, it's a power failure. The area reportedly had a significant storm yesterday. It's possible that the power failed and that they didn't have enough fuel or battery capacity or whatever to keep it running during an extended outage. That would also neatly explain why it reportedly came back and has reportedly died again.
The court charges, but in general, when you're talking about two parties with dramatically differing levels of available resources, the only time the smaller party pays for the larger party's attorney fees is if the lawsuit is frivolous (summary judgment) or if the law specifically provides for that (e.g. the defense loses certain types of suits). This is clearly not frivolous.
Besides, it would never go to court. The company would almost certainly settle out of court for a few hundred thousand just to get them to shut up. Otherwise, the story hits a few major networks, and that casino's business dries up because people suddenly realize that if they win big, the casino is just going to screw them out of the money.
As much as I'd like to blame it on greedy network operators, that's just not the case. The increase of commercials is primarily because people weren't willing to pay for the content. I remember when Disney Channel had no commercials. At the time, it was a pay channel that cost ten or twelve dollars a month from my cable company, so I didn't actually receive it except during their free preview weekends. The channels that still cost several bucks a month (e.g. HBO) still air everything without commercial interruptions, and AFAIK, still do not accept outside advertising in general.
The channels that gained commercials did so because we went from having 15-20 non-pay stations to 300 stations and pay about the same amount for our cable bill when adjusted for inflation. As the cable companies have gotten larger and larger bundles of content for the same cost, the satellite-delivered networks have gotten less and less money per channel. They had to make up that revenue difference somehow. Content production isn't free....
I can't find the site I got those stats from right now (I'm not using my work machine, so it's not in my history), but I suspect the data I used was based on traffic to major web sites. In other words, my stats don't include the Bittorrent traffic that makes up the other 80%.:-D
Either way, the interesting bit was the sudden and rapid growth of mobile data traffic coincident with the policy change, not the specific number as a percentage of Internet traffic (which will vary widely depending on how it is calculated).
First, the earlier doctors can identify it, the more likely it is that scientists will be able to identify the very first expression of whatever gene causes it, and thus eventually prevent that change in others. They might even find that there's some underlying environmental cause that triggers said gene expression, in which case it could be eliminated entirely through early enough testing and treatment. Either way, identifying it early enough is key to being able to find the root cause.
Second, the earlier autism is identified in a kid, the more likely that behavioral therapy will produce a more functional adult.
Ah, but airlines charge more money the fewer seats are left to discourage people from causing them to have to move to a bigger plane, and they discount the heck out of fares when they don't have enough passengers. The result is that the airlines are now constantly raising fares and whining about how they can barely afford to keep the lights on, all the while begging for government bailouts. If you want telecom to be in the same boat in ten years, this is where it starts.
Also, trying to compare telecom to airlines is a terrible analogy anyway. There's minimal additional cost to a telecom system for additional packets up to the point at which they have to increase infrastructure. With aircraft, the cost to the airline depends on how many people are flying. If zero people are flying, it costs zero dollars because they cancel the flight. If at least one person is flying, they have to pay the base cost of fuel plus an incremental fuel cost proportional to the number of people on the plane, the number of bags, etc. By contrast, with a network, ignoring minor fluctuations in power consumption, the cost of the capacity is almost entirely there even if the capacity is unused.
Finally, as for whether charging for bandwidth would stifle growth, we need to learn from history. When iPhone came out, suddenly AT&T started offering unlimited mobile data at a reasonable price. Traffic from smartphones is now about 1/6th the total Internet traffic. Before that, smartphone traffic was basically inconsequential. Now part of the difference is that iPhone provides a better browsing experience than most or all of the craptastic browsers that came before it, but speaking as somebody who had a previous phone that was capable of doing mobile browsing, I can honestly say that I never even bothered to test the feature to see if it was usable. Why? Because they were metering by the kilobyte and I wasn't about to run up a thousand dollar phone bill. I took one look at the rates and said, "No way."
Now I'll grant that the two-gigabytes-and-then-you-lose-service plan is less of a screw job than AT&T's extortionate per-kilobyte rates from a few years ago, but there's really no question whether higher prices will stifle growth. It historically did stifle growth, and it stifled growth massively.
I'm a light iPhone user. I almost never use it to check mail, and only occasionally use it to browse the web. Even still, I rack up an average of 300 MB per month. 2 GB is not a lot of traffic. It's like loading Slashdot's home page about once every twenty seconds for a month. It's like watching about 36 minutes of high definition YouTube video (if you could actually do that over 3G). Let's put that in hard numbers. Somebody watching nothing but YouTube HD videos all day (assuming a 14 hour day with time out to sleep and eat) would spend a whopping $17,500 in bandwidth fees. Talk about a phone bill that can stifle growth.
Yes, this AT&T scheme is a bad thing. A VERY bad thing.
I think the GP means that developers who already have to struggle to keep flash *off* the.mobi site are now going to have to struggle to minimize the bandwidth consumption of their main site.
Of course, that flash content on the main site won't load on iPad anyway, so the point is a bit moot.
Well, in this case, they're treating the last path part as a unique identifier, which it obviously is not. I read the article half expecting it to be an integer overflow bug....
Huh? 01 in little or big endian encoding is the encoding for decimal 1, not 2. In either encoding, 2 is encoded as 10. We haven't had reverse-bit-order CPUs in decades. Endianness defines the order of bytes, not the order of bits within a byte.
In big endian notation, 1 can be encoded in a 16-bit value as 00000000 00000001, whereas in little endian notation, it would be encoded as 00000001 00000000. Big endian notation is the order that we naturally use for mathematics. Little endian only makes sense if you think that it is useful to be able to cast between pointers to integers of different length and get the right result if the value is small enough....
Maybe what's confusing you is that documentation uses different standards for numbering the bits; IIRC, IBM's documentation calls bit 0 the 2^0th bit, whereas Intel's documentation calls bit 0 (or maybe 1) the leftmost bit. (Or is it the other way around? I forget.) That's just a numbering convention for bitfield values, and has nothing to do with the way an actual multi-bit value is printed or stored.
We don't have a right to know instantly; that would put officers in danger.
I'm not sure I fully agree.
There are sometimes very good reasons to not allow live coverage of police activity. It's probably easier to explain it by example.
A bank robbery is in progress. The police have surrounded the building and are preparing to move in. The robbers inside are watching the situation unfold on live television. The police are within their rights to ask that live broadcasting cease temporarily so that the robbers are not aware of the imminent action. Continuing to broadcast live could turn what should be a surgical strike into an ambush.
I'm not saying that this is the norm for police actions, but sometimes temporary prior restraint of publication is acceptable. Prior restraint for a prolonged period of time, however (including confiscating the tape), is almost never acceptable.
You'd think so. I wasn't necessarily suggesting a federal law, though. A law passed by even a small town in the middle of nowhere taken to the SCOTUS would be sufficient to set precedent and should significantly discourage other parts of the country from trying to pass such stupid laws. Not that some blowhard politicians won't try over and over, but at some point, the attempts tend to die down.
In this case, that attitude is right. While on the job, you are responsible to your employer, and you have no inherent right to privacy. Sure, you can argue that you should be granted some privacy to make it a non-hostile work environment, but ultimately that is a privilege, not a legal right. It starts to get dicey when you're talking about ostensibly personal communication while physically at a work site, but that's not what we're talking about here. Nobody would ever be able to successfully sue for a privacy violation if he/she got fired for stripping nude in front of a security camera. That's essentially the level of privacy we're talking about here---overt activity in a public or semipublic place. To that end, they have no right to privacy, and more to the point, *should not* have any right to privacy while out on patrol or on a bust or whatever.
When it comes to police officers, the general public are their bosses, in effect. Their job is to protect the public, and thus only the public can reasonably determine whether or not they are doing their jobs. As such, we have a fundamental right to know what they are up to. We don't have a right to know instantly; that would put officers in danger. However, much as we have a responsibility as a society to oversee our military and their actions, we have the same societal responsibility to watch our police force. Period.
Moreover, what they do, they do in public. There is a fundamental legal right of the public to photograph and videotape *anything* that occurs in a public place. Period. There's no grey area here. And when they are in private places, the right to determine whether recording is allowed or not belongs to the owner of the property, which again, usually is the person doing the videotaping.
Finally, I would add that preventing police officers from being recorded is a technically infeasible request. We have security cameras all over the place, and individuals have a right to have security cameras on their property. It's just not feasible to have these systems somehow magically identify a police officer and shut off. Any mechanism that could provide such functionality could also be abused by the bad guys to nullify the utility of the security system. This is a fundamentally unsolvable problem.
So what they're asking is either:
To have special rules applying only to cameras/camcorders/cell phone cameras when held in the hand of an individual. This doesn't fully solve their perceived problem, and is provably discriminatory against people unable to afford security systems. This one won't pass muster, and is stupid, to boot.
To make it illegal to make available footage of the police doing their jobs. This runs afoul of the first amendment, and constitutes prior restraint of publication. Protection against prior restraint is basically the highest hurdle a speech law can have to jump. It is almost never possible to get a prior restraint law past the courts except in exceptionally narrow cases, and even then, usually only for a limited time (e.g. not allowing live coverage telling where police are).
In short, IMHO, there's basically a 0% chance that any law like this would make it through SCOTUS without being nullified, no matter how they write the law. That said, it would be nice for a law on this subject to be taken all the way to the SCOTUS just to cement that into binding precedent.
Having tried to use smartphone cameras for barcode reading, I'm not convinced this will work well at all unless the barcode is the size of an entire page. Most of them don't focus well up close at all, and are pretty unreliable even for low density barcodes in good light. Heaven help you if you try to do high density barcodes with actual URLs embedded in poor light.
Further, unless you're running custom software on the phone (which means dozens of different versions of the software) to decode the barcodes on the device, you'll be sending a large, high resolution image over cell networks, so there goes a couple of minutes per barcode.
When you're done, you either have to view the content on a little cell phone screen (undesirable) or have to move the URL from the phone to a computer somehow. So you have three choices:
Hand copy the URL from the device
Use custom software on the computer to fetch the URL from the device
Use a website for the communication, which means having to carry around a URL (that would probably be different for each textbook company) to type in by hand (so you might as well just memorize the textbook publisher's website).
Either way, my main point was that this is a lot of complexity for no benefit. Even if you can use hardware you already have, it's still a half dozen steps per link. By comparison, you can Google search the publisher's website in a couple seconds, click on a link from their front page to "textbook extras" or whatever, and bring up the extras for your book, then get to the next one by clicking back and clicking the next link down. That's at least a minute less work per link.
And even if that complexity somehow bought you some advantage (it doesn't), it would still bring with it major disadvantages. With a website for the book, you can *add* content after the book is published. With barcodes in the margins, you're stuck with the set of additional content that you were able to come up with before publication. And if you're navigating around a site manually, you can find errata interspersed with the examples, too. If you're navigating only with explicit links from the book, the best you can do is have a link to the errata for a chapter. Less useful than a well-designed site.
The reason the CueCat failed is not because of the dedicated hardware. They gave them out for free by the millions at Radio Shack. They still failed. The reason CueCat failed is that the entire premise is misguided. The whole reason the web is powerful is that hyperlinks can be added after the fact as you come up with new ideas. Printing links in a book will always be far less useful than creating a flexible web site that can be expanded at will, and no matter how easy you make it, it will never be as easy as going to the book's website, and it will never be as flexible.
Because pedos are totally going to Google "kiddy porn downloads".
You're close. I think it's more likely that these government types think that child molesters are going to Google, "How do I molest my daughter?" like some murderers have Googled, "How do I kill someone without leaving any evidence?" in previous years. And they're right; a few people actually are that dumb.
On the flip side, for every one person who is stupid enough to ask for advice on molesting a child, they'll also catch hundreds of other people who are looking for ways to evade various taxes, downloading music or movies, trying to get away with various other crimes, etc. And for every one they catch doing something illegal, they'll catch a dozen trying to sow the seeds of political dissent, speaking out against the government or corporations that it protects, digging up dirt on politicians, doing something embarrassing like cheating on a spouse, etc. It's not a question of whether such laws will be abused, but when and how.
You will, however, almost certainly not share a single line of UI code between a.Net application and an iPhone application anyway. Even if you could write Objective-C code for.Net, you wouldn't be able to make UIKit calls on the other device, making it a moot point. Likewise, even if you could write code in C# for iPhone, you would not have support for Windows UI calls.
The way you write code in situations like this is an abstraction layer. You write the core code in C or C++, then write an iPhone UI in Objective-C and a WinMo UI in... whatever, and similarly abstract out file reads/writes, etc. You write custom OS-specific code near the boundaries between the OS and your app, then write the core code in a language that's cross-platform.
For maximum convenience, you should also consider using Core Foundation where possible. You can build and include CFLite for the other devices, and as long as you restrict yourself to that subset of the API, you'll be fine. And on the iPhone side, you can then take advantage of toll-free bridging to use most of those CF objects as though they were the equivalent NS (Foundation) objects.
Agreed. Here's a novel idea. Provide hyperlinks as... gasp... URLs! You can print them in footnotes. Then, people can get the related content without having to carry around special hardware whose sole purpose is to read links from the one paper book in the universe that has these barcodes. It didn't make sense when Cuecat did it for catalogs, and that's orders of magnitude more frequently updated than books, college textbooks notwithstanding.
I could see this being of some limited utility for college textbooks, but only very limited utility. Most textbook companies already have websites associated with their textbooks for precisely this reason. Those sites are organized in the same way the book is, so it's pretty easy to find the content related to a given chapter, and all you have to do is bookmark a single URL. All that without the need to resort to some unnecessary piece of hardware that can break, get lost, or encounter driver compatibility problems, all without the need to carry the book with you when you go to the computer lab, all without the need for the computer lab to allow you to plug outside hardware into their computers and install drivers, etc.
It didn't make sense then, and it doesn't make sense now.
Slashdot Mirror
You're drawing an arbitrary line. It's possible to improve a chip design without creating a fundamental new building block that nobody else has ever built.... By your standards, the Centre Pompidou is not architecturally unique because other buildings have air ducts and water pipes.
Depends on what you mean by "licensed core". If you look at the history of Apple, you'll see a clear pattern: Apple licenses other people's cores or buys their chips at the end of the design process, but is quite frequently involved in designing those cores to begin with.
Let's review:
Apple has a long history of working with chip vendors and adding significant functionality to their designs. Sure, those bits end up in other companies' products, but there's Apple IP in an awful lot of CPUs out there, including many of the CPUs that have appeared in Apple products over the years....
No, I don't. That would break compatibility with existing PHP-based tools, many of which already do perform adequate sanitization of queries on their own. Case in point, SQL queries into a database using exclusively numeric keys can be sanitized like this:
$id = (int)$id;
Forcing people that don't pass arbitrary user-generated data to use a different function is unnecessary and pointless; they'll just pass the exact same argument(s) they do now, but add an empty array.
Adding another optional parameter to this function would break nothing, and would provide precisely the same benefits.
If you really want people to look at their code, you could make PHP throw a warning when no array parameter is passed in, and make it possible to disable that warning site-wide so it doesn't break things. That would have the advantage of pushing developers to look at their code without breaking backwards compatibility unnecessarily. It would also have the advantage of providing a nice audit log of the offending functions in error logs so sysadmins can audit suspicious code themselves.
There are a lot of ways to make SQL injection attacks much, much harder. The simplest requires only a handful of changes:
By using a transaction around command groups, you ensure that any error will cause the entire transaction to be rolled back. By disabling the comment character, you make it impossible to make the rest of the command go away and not cause an error. By using an unpublished schema (and specifically, nonstandard column names), you make it nearly impossible for someone to correctly construct a working query out of the last half of the original query. Even something as simple as prefixing every column name with a hard-to-guess string is enough to make it insanely hard to inject SQL unless you pissed off an ex-employee.
That said, I wish substitution (interpolation) were the only query form available. It's particularly annoying in PHP, where you have to roll your own (or copy and paste out of the user-provided comments in the documentation) to get the functionality at all. The array of tokens to substitute should be an optional argument to mysql_query()....
That's wrong for (at least) two reasons:
Easy. YouTube high definition videos can be up to a gigabyte in size, and that's for 10 minutes of video. Are you telling me you don't think someone can possibly watch eleven hours of high definition YouTube content in a month?
65 gigabytes is rapidly becoming light use for young people with YouTube addictions. The telcos simply need to increase the size of their backhauls, period. Any attempts at capping are just going to result in lawsuits and massive numbers of very pissed off customers.
What they're not telling you is that the people pulling such huge traffic rates are doing so because they're using the phone instead of a computer, and they have no Wi-Fi access. 200 megabytes is *nothing* if you're using cellular data exclusively. That's about an hour and a half of YouTube-quality video. Want to watch a TV show or two while you're on vacation? You can rack up gigabytes of usage pretty quickly.
The thing is, if you use your phone as a media viewing platform, you're going to run up large amounts of bandwidth. For people who are used to doing that, it only takes a one week vacation somewhere without Wi-Fi to put you into that top 0.1%. Or when your Wi-Fi connection goes down and you don't notice that it's pulling data over 3G. And that's what makes this so insidious. You don't need to break the rules and tether, use BitTorrent, or violate the terms of service in any way to run afoul of a bandwidth limit. There's plenty of perfectly legitimate reasons to consume that much bandwidth, and it isn't very hard to do in a month if you aren't paying attention.
Stop right there. The vast majority of corporate contributions to open source involves companies using the open source project for a small portion of a much larger product. From the work of Apple and other companies on Clang/LLVM to the way TiVo and home router manufacturers use the Linux kernel, open source is almost always used as the basis for a significantly bigger product. The cases where an open source project and a commercial project are actually competing is almost nonexistent (with a few fairly visible exceptions like MySQL and CodeWeavers), and even then, most of the companies are good citizens and contribute fixes back to the open source project or fork and create a new open source project (e.g. WebKit).
For every case where a private fork competes with a free and open fork, I can list a hundred cases of an open source tool being used as a portion of a larger product. Thus, for every case where GPLv3 discouraged corporate privatization of the code, it discouraged a hundred companies from using the code in a way that would not compete with and potentially harm the open source project....
Chances are, it's a power failure. The area reportedly had a significant storm yesterday. It's possible that the power failed and that they didn't have enough fuel or battery capacity or whatever to keep it running during an extended outage. That would also neatly explain why it reportedly came back and has reportedly died again.
The court charges, but in general, when you're talking about two parties with dramatically differing levels of available resources, the only time the smaller party pays for the larger party's attorney fees is if the lawsuit is frivolous (summary judgment) or if the law specifically provides for that (e.g. the defense loses certain types of suits). This is clearly not frivolous.
Besides, it would never go to court. The company would almost certainly settle out of court for a few hundred thousand just to get them to shut up. Otherwise, the story hits a few major networks, and that casino's business dries up because people suddenly realize that if they win big, the casino is just going to screw them out of the money.
As much as I'd like to blame it on greedy network operators, that's just not the case. The increase of commercials is primarily because people weren't willing to pay for the content. I remember when Disney Channel had no commercials. At the time, it was a pay channel that cost ten or twelve dollars a month from my cable company, so I didn't actually receive it except during their free preview weekends. The channels that still cost several bucks a month (e.g. HBO) still air everything without commercial interruptions, and AFAIK, still do not accept outside advertising in general.
The channels that gained commercials did so because we went from having 15-20 non-pay stations to 300 stations and pay about the same amount for our cable bill when adjusted for inflation. As the cable companies have gotten larger and larger bundles of content for the same cost, the satellite-delivered networks have gotten less and less money per channel. They had to make up that revenue difference somehow. Content production isn't free....
I can't find the site I got those stats from right now (I'm not using my work machine, so it's not in my history), but I suspect the data I used was based on traffic to major web sites. In other words, my stats don't include the Bittorrent traffic that makes up the other 80%. :-D
Either way, the interesting bit was the sudden and rapid growth of mobile data traffic coincident with the policy change, not the specific number as a percentage of Internet traffic (which will vary widely depending on how it is calculated).
First, the earlier doctors can identify it, the more likely it is that scientists will be able to identify the very first expression of whatever gene causes it, and thus eventually prevent that change in others. They might even find that there's some underlying environmental cause that triggers said gene expression, in which case it could be eliminated entirely through early enough testing and treatment. Either way, identifying it early enough is key to being able to find the root cause.
Second, the earlier autism is identified in a kid, the more likely that behavioral therapy will produce a more functional adult.
Ah, but airlines charge more money the fewer seats are left to discourage people from causing them to have to move to a bigger plane, and they discount the heck out of fares when they don't have enough passengers. The result is that the airlines are now constantly raising fares and whining about how they can barely afford to keep the lights on, all the while begging for government bailouts. If you want telecom to be in the same boat in ten years, this is where it starts.
Also, trying to compare telecom to airlines is a terrible analogy anyway. There's minimal additional cost to a telecom system for additional packets up to the point at which they have to increase infrastructure. With aircraft, the cost to the airline depends on how many people are flying. If zero people are flying, it costs zero dollars because they cancel the flight. If at least one person is flying, they have to pay the base cost of fuel plus an incremental fuel cost proportional to the number of people on the plane, the number of bags, etc. By contrast, with a network, ignoring minor fluctuations in power consumption, the cost of the capacity is almost entirely there even if the capacity is unused.
Finally, as for whether charging for bandwidth would stifle growth, we need to learn from history. When iPhone came out, suddenly AT&T started offering unlimited mobile data at a reasonable price. Traffic from smartphones is now about 1/6th the total Internet traffic. Before that, smartphone traffic was basically inconsequential. Now part of the difference is that iPhone provides a better browsing experience than most or all of the craptastic browsers that came before it, but speaking as somebody who had a previous phone that was capable of doing mobile browsing, I can honestly say that I never even bothered to test the feature to see if it was usable. Why? Because they were metering by the kilobyte and I wasn't about to run up a thousand dollar phone bill. I took one look at the rates and said, "No way."
Now I'll grant that the two-gigabytes-and-then-you-lose-service plan is less of a screw job than AT&T's extortionate per-kilobyte rates from a few years ago, but there's really no question whether higher prices will stifle growth. It historically did stifle growth, and it stifled growth massively.
I'm a light iPhone user. I almost never use it to check mail, and only occasionally use it to browse the web. Even still, I rack up an average of 300 MB per month. 2 GB is not a lot of traffic. It's like loading Slashdot's home page about once every twenty seconds for a month. It's like watching about 36 minutes of high definition YouTube video (if you could actually do that over 3G). Let's put that in hard numbers. Somebody watching nothing but YouTube HD videos all day (assuming a 14 hour day with time out to sleep and eat) would spend a whopping $17,500 in bandwidth fees. Talk about a phone bill that can stifle growth.
Yes, this AT&T scheme is a bad thing. A VERY bad thing.
I think the GP means that developers who already have to struggle to keep flash *off* the .mobi site are now going to have to struggle to minimize the bandwidth consumption of their main site.
Of course, that flash content on the main site won't load on iPad anyway, so the point is a bit moot.
Well, in this case, they're treating the last path part as a unique identifier, which it obviously is not. I read the article half expecting it to be an integer overflow bug....
Huh? 01 in little or big endian encoding is the encoding for decimal 1, not 2. In either encoding, 2 is encoded as 10. We haven't had reverse-bit-order CPUs in decades. Endianness defines the order of bytes, not the order of bits within a byte.
In big endian notation, 1 can be encoded in a 16-bit value as 00000000 00000001, whereas in little endian notation, it would be encoded as 00000001 00000000. Big endian notation is the order that we naturally use for mathematics. Little endian only makes sense if you think that it is useful to be able to cast between pointers to integers of different length and get the right result if the value is small enough....
Maybe what's confusing you is that documentation uses different standards for numbering the bits; IIRC, IBM's documentation calls bit 0 the 2^0th bit, whereas Intel's documentation calls bit 0 (or maybe 1) the leftmost bit. (Or is it the other way around? I forget.) That's just a numbering convention for bitfield values, and has nothing to do with the way an actual multi-bit value is printed or stored.
From orbit? It's the only way to be sure.
There are sometimes very good reasons to not allow live coverage of police activity. It's probably easier to explain it by example.
A bank robbery is in progress. The police have surrounded the building and are preparing to move in. The robbers inside are watching the situation unfold on live television. The police are within their rights to ask that live broadcasting cease temporarily so that the robbers are not aware of the imminent action. Continuing to broadcast live could turn what should be a surgical strike into an ambush.
I'm not saying that this is the norm for police actions, but sometimes temporary prior restraint of publication is acceptable. Prior restraint for a prolonged period of time, however (including confiscating the tape), is almost never acceptable.
You'd think so. I wasn't necessarily suggesting a federal law, though. A law passed by even a small town in the middle of nowhere taken to the SCOTUS would be sufficient to set precedent and should significantly discourage other parts of the country from trying to pass such stupid laws. Not that some blowhard politicians won't try over and over, but at some point, the attempts tend to die down.
In this case, that attitude is right. While on the job, you are responsible to your employer, and you have no inherent right to privacy. Sure, you can argue that you should be granted some privacy to make it a non-hostile work environment, but ultimately that is a privilege, not a legal right. It starts to get dicey when you're talking about ostensibly personal communication while physically at a work site, but that's not what we're talking about here. Nobody would ever be able to successfully sue for a privacy violation if he/she got fired for stripping nude in front of a security camera. That's essentially the level of privacy we're talking about here---overt activity in a public or semipublic place. To that end, they have no right to privacy, and more to the point, *should not* have any right to privacy while out on patrol or on a bust or whatever.
When it comes to police officers, the general public are their bosses, in effect. Their job is to protect the public, and thus only the public can reasonably determine whether or not they are doing their jobs. As such, we have a fundamental right to know what they are up to. We don't have a right to know instantly; that would put officers in danger. However, much as we have a responsibility as a society to oversee our military and their actions, we have the same societal responsibility to watch our police force. Period.
Moreover, what they do, they do in public. There is a fundamental legal right of the public to photograph and videotape *anything* that occurs in a public place. Period. There's no grey area here. And when they are in private places, the right to determine whether recording is allowed or not belongs to the owner of the property, which again, usually is the person doing the videotaping.
Finally, I would add that preventing police officers from being recorded is a technically infeasible request. We have security cameras all over the place, and individuals have a right to have security cameras on their property. It's just not feasible to have these systems somehow magically identify a police officer and shut off. Any mechanism that could provide such functionality could also be abused by the bad guys to nullify the utility of the security system. This is a fundamentally unsolvable problem.
So what they're asking is either:
In short, IMHO, there's basically a 0% chance that any law like this would make it through SCOTUS without being nullified, no matter how they write the law. That said, it would be nice for a law on this subject to be taken all the way to the SCOTUS just to cement that into binding precedent.
Having tried to use smartphone cameras for barcode reading, I'm not convinced this will work well at all unless the barcode is the size of an entire page. Most of them don't focus well up close at all, and are pretty unreliable even for low density barcodes in good light. Heaven help you if you try to do high density barcodes with actual URLs embedded in poor light.
Further, unless you're running custom software on the phone (which means dozens of different versions of the software) to decode the barcodes on the device, you'll be sending a large, high resolution image over cell networks, so there goes a couple of minutes per barcode.
When you're done, you either have to view the content on a little cell phone screen (undesirable) or have to move the URL from the phone to a computer somehow. So you have three choices:
Either way, my main point was that this is a lot of complexity for no benefit. Even if you can use hardware you already have, it's still a half dozen steps per link. By comparison, you can Google search the publisher's website in a couple seconds, click on a link from their front page to "textbook extras" or whatever, and bring up the extras for your book, then get to the next one by clicking back and clicking the next link down. That's at least a minute less work per link.
And even if that complexity somehow bought you some advantage (it doesn't), it would still bring with it major disadvantages. With a website for the book, you can *add* content after the book is published. With barcodes in the margins, you're stuck with the set of additional content that you were able to come up with before publication. And if you're navigating around a site manually, you can find errata interspersed with the examples, too. If you're navigating only with explicit links from the book, the best you can do is have a link to the errata for a chapter. Less useful than a well-designed site.
The reason the CueCat failed is not because of the dedicated hardware. They gave them out for free by the millions at Radio Shack. They still failed. The reason CueCat failed is that the entire premise is misguided. The whole reason the web is powerful is that hyperlinks can be added after the fact as you come up with new ideas. Printing links in a book will always be far less useful than creating a flexible web site that can be expanded at will, and no matter how easy you make it, it will never be as easy as going to the book's website, and it will never be as flexible.
You're close. I think it's more likely that these government types think that child molesters are going to Google, "How do I molest my daughter?" like some murderers have Googled, "How do I kill someone without leaving any evidence?" in previous years. And they're right; a few people actually are that dumb.
On the flip side, for every one person who is stupid enough to ask for advice on molesting a child, they'll also catch hundreds of other people who are looking for ways to evade various taxes, downloading music or movies, trying to get away with various other crimes, etc. And for every one they catch doing something illegal, they'll catch a dozen trying to sow the seeds of political dissent, speaking out against the government or corporations that it protects, digging up dirt on politicians, doing something embarrassing like cheating on a spouse, etc. It's not a question of whether such laws will be abused, but when and how.
You will, however, almost certainly not share a single line of UI code between a .Net application and an iPhone application anyway. Even if you could write Objective-C code for .Net, you wouldn't be able to make UIKit calls on the other device, making it a moot point. Likewise, even if you could write code in C# for iPhone, you would not have support for Windows UI calls.
The way you write code in situations like this is an abstraction layer. You write the core code in C or C++, then write an iPhone UI in Objective-C and a WinMo UI in... whatever, and similarly abstract out file reads/writes, etc. You write custom OS-specific code near the boundaries between the OS and your app, then write the core code in a language that's cross-platform.
For maximum convenience, you should also consider using Core Foundation where possible. You can build and include CFLite for the other devices, and as long as you restrict yourself to that subset of the API, you'll be fine. And on the iPhone side, you can then take advantage of toll-free bridging to use most of those CF objects as though they were the equivalent NS (Foundation) objects.
Agreed. Here's a novel idea. Provide hyperlinks as... gasp... URLs! You can print them in footnotes. Then, people can get the related content without having to carry around special hardware whose sole purpose is to read links from the one paper book in the universe that has these barcodes. It didn't make sense when Cuecat did it for catalogs, and that's orders of magnitude more frequently updated than books, college textbooks notwithstanding.
I could see this being of some limited utility for college textbooks, but only very limited utility. Most textbook companies already have websites associated with their textbooks for precisely this reason. Those sites are organized in the same way the book is, so it's pretty easy to find the content related to a given chapter, and all you have to do is bookmark a single URL. All that without the need to resort to some unnecessary piece of hardware that can break, get lost, or encounter driver compatibility problems, all without the need to carry the book with you when you go to the computer lab, all without the need for the computer lab to allow you to plug outside hardware into their computers and install drivers, etc.
It didn't make sense then, and it doesn't make sense now.