Slashdot Mirror

It reminds me of the arrests for using open wifi networks. See http://arstechnica.com/tech-policy/2007/05/michigan-man-arrested-for-using-cafes-free-wifi-from-his-car/

The one in Alaska, arresting someone for using a library's wifi after hours, is particularly ridiculous. I've done that many times, librarians have even mentioned people doing it with no hint that it is any kind of problem.

A crime is a crime: http://arstechnica.com/information-technology/2013/12/charged-with-theft-man-arrested-for-plugging-car-into-schools-outlet/

This is the chip that unites the CPU and GPU into one programing model with unified memory addressing. Heterogeneous System Architecture(HSA) and Heterogeneous Uniform Memory Access(HUMA) are the nice buzzword acronyms that AMD came up with but it basically removes the latency from accessing GPU resources and makes memory sharing between the CPU cores and GPU cores copy free. You can now dispatch instructions to the GPU cores almost as easily and as quickly as you do to the basic ALU/FPU/SSE units of the CPU.

Will software be written to take advantage of this though?

Will Intel eventually support it on their stuff?

Ars article on the new architecture.

Anandtech article on the Kaveri release.

Perhaps everyone quoting that xkcd should be aware that such passwords are no longer safe.

If you think to yourself after reading the first page, "But all of those long passwords were phrases, not nonsense strings!" then you should keep reading to page 2's sidebar for the list of passwords that were cracked using the methods in the article. Crackers have dictionaries of billions of words now and can try combinations and variations at GPU-fueled speeds. Length only protects you if and only if you can exhaust dictionary attacks.

The only safe password is long and either randomly generated or indistinguishable from it. Using some other device to store and auto-fill your passwords like a password manager or a device like a YubiKey is the only long-term solution. Humans are the weakest link.

Using software to store and auto-fill your passwords is the worst possible solution (a post-it on the monitor is more secure in practice). The result of that thinking will be trojan key-stores that simply inform their creator what your password is.

The point of the XKCD is that if you select n random words instead of n random characters you can get a password that can be memorized easily, and exploits the larger search space of words (compared to the smaller search space of characters that exist on your keyboard) meaning your password will be more secure and easier to remember.

Better yet, randomly capitalize and use aural memory to remember where they are. "Correct horse, BATtery staPLE!" If say it aloud a few times (in private, of course), pronouncing it with stress on the capitals, you'll remember it easily, even if it's silly :) Of course you might have to leave out the punctuation, depending on the password field tolerances...which sucks.

Perhaps everyone quoting that xkcd should be aware that such passwords are no longer safe.

Nope, that article details methods for cracking known phrases, not non-phrase combinations of several random words. Indeed an poster on that article specifically addresses the crackability of the aforementions xkcd pass "phrase" in this context.

Of course "correct horse battery staple" is now a known phrase rather than a non-phrase combination of 4 random words. However, at least before I posted this, the password "honey $anctify Entropy umlaut m1ll10n" was still safer than "to be or not to be that is the question".

All of the examples they gave in the article break one of the fundamental rules in that XKCD strip. The words shouldn't be words that are easily associated with each other. Of course picking a quote straight out of fiction is stupid. Four random 4-6 letter words that don't appear together in common language usage would be harder to crack for people using the strategy in the article http://arstechnica.com/security/2013/10/how-the-bible-and-youtube-are-fueling-the-next-frontier-of-password-cracking/

Perhaps everyone quoting that xkcd should be aware that such passwords are no longer safe.

If you think to yourself after reading the first page, "But all of those long passwords were phrases, not nonsense strings!" then you should keep reading to page 2's sidebar for the list of passwords that were cracked using the methods in the article. Crackers have dictionaries of billions of words now and can try combinations and variations at GPU-fueled speeds. Length only protects you if and only if you can exhaust dictionary attacks.

The only safe password is long and either randomly generated or indistinguishable from it. Using some other device to store and auto-fill your passwords like a password manager or a device like a YubiKey is the only long-term solution. Humans are the weakest link.

Using software to store and auto-fill your passwords is the worst possible solution (a post-it on the monitor is more secure in practice). The result of that thinking will be trojan key-stores that simply inform their creator what your password is.

The point of the XKCD is that if you select n random words instead of n random characters you can get a password that can be memorized easily, and exploits the larger search space of words (compared to the smaller search space of characters that exist on your keyboard) meaning your password will be more secure and easier to remember.

Perhaps everyone quoting that xkcd should be aware that such passwords are no longer safe.

If you think to yourself after reading the first page, "But all of those long passwords were phrases, not nonsense strings!" then you should keep reading to page 2's sidebar for the list of passwords that were cracked using the methods in the article. Crackers have dictionaries of billions of words now and can try combinations and variations at GPU-fueled speeds. Length only protects you if and only if you can exhaust dictionary attacks.

The only safe password is long and either randomly generated or indistinguishable from it. Using some other device to store and auto-fill your passwords like a password manager or a device like a YubiKey is the only long-term solution. Humans are the weakest link.

After watching several animated gif's of the event (like this one: http://arstechnica.com/science/2013/12/comet-ison-fizzles-but-theres-a-sting-in-the-tail/), I'm left a little perplexed. I was under the impression that as a comet approaches the Sun, the heat causes outgassing and evaporation, and the tail forms as the solar wind blows that away from the comet. Accordingly, I thought a comet's tail roughly always pointed away from the sun with maybe a slight curve due to momentum. But the gif's I'm seeing don't show that. I know the comet is speeding up as it approaches the Sun, and certain gains a slingshot effect as it whips around, but I didn't think that speed would overcome the solar wind.

Can anyone explain why the tail is still pointing in opposition to the direction of movement like jet exhaust?

The icy core of the comet was pulled in towards the sun by the sun's gravity, any icy outgassing is not the core's propellant. Since the core is moving faster than the outgassing the tail will not catch up to it.

After watching several animated gif's of the event (like this one: http://arstechnica.com/science/2013/12/comet-ison-fizzles-but-theres-a-sting-in-the-tail/), I'm left a little perplexed. I was under the impression that as a comet approaches the Sun, the heat causes outgassing and evaporation, and the tail forms as the solar wind blows that away from the comet. Accordingly, I thought a comet's tail roughly always pointed away from the sun with maybe a slight curve due to momentum. But the gif's I'm seeing don't show that. I know the comet is speeding up as it approaches the Sun, and certain gains a slingshot effect as it whips around, but I didn't think that speed would overcome the solar wind.

Can anyone explain why the tail is still pointing in opposition to the direction of movement like jet exhaust?

Nonsense. The source is there, anything can be disabled, changed, added. The only thing keeping Android from being completely open is the amount of blob code needed to access device-specific hardware. Google has as much control over your phone as you want, from 'none at all' to 'they know who I'm about to meet'. The choice is yours.

Actually, a modern Android phone (non-Chinese version) is actually full of closed source at the top - and I'm not talking about drivers, but Google-installed closed source.

AOSP gets you a basic phone, yes, but you'll notice most of the apps are actually missing and anyone using AOSP will probably ask why they're so crippled - Google has closed source versions of many apps that leave the AOSP versions in the dust.

http://arstechnica.com/gadgets/2013/10/googles-iron-grip-on-android-controlling-open-source-by-any-means-necessary/

These days, Android is dominant. Google no longer needs Android to be open-source in order to prevent an "iPhone takeover" or to build marketshare. And we see that happening - Google is restricting what they put in AOSP to prevent Amazon and others from taking AOSP and running with it - doing stuff like tying apps to Google Services Framework so devs can't port to Kindle easily, etc.

Perhaps the biggest threat to Google is that Samsung is the only player with a complete set of fully functional (closed source) replacement apps. But anyone starting from AOSP has a lot of extra development work to do.

The KK launcher ('home screen app') in Google apps is built around Google search. Don't want it? Just use another launcher, there is one for every need, some of them free software, others closed. The choice, again, is yours.

Yes you can. However, that's sure a HUGE PITA that for everyone concerned, no one would bother. Sure you'll have a few, but the vast majority won't, so much so that the few that do are insignificant and ignorable and if you're an app developer, you don't care.

I know there are probably a few people who change launchers daily, but others may try it once and forget it - the big problem with Android is the lack of a sane backup solution - you can spend hours/days customizing it, but then move to a new phone and then lose it all. Repeat a couple of times and it's just a huge PITA.

As I understand it, that is not going to happen if you want Google's bless (i.e. their applications and Google Play Services, which are critical for some applications to work). Read Google’s iron grip on Android, especially page 3.

Since the Kindle OS counts as an incompatible version of Android, no major OEM is allowed to produce the Kindle Fire for Amazon. So when Amazon goes shopping for a manufacturer for its next tablet, it has to immediately cross Acer, Asus, Dell, Foxconn, Fujitsu, HTC, Huawei, Kyocera, Lenovo, LG, Motorola, NEC, Samsung, Sharp, Sony, Toshiba, and ZTE off the list. Currently, Amazon contracts Kindle manufacturing out to Quanta Computer, a company primarily known for making laptops. Amazon probably doesn't have many other choices.

Seems like a terrible move against market freedom. Even worse for consumer freedom.

You utterly fucking fail at understanding security. [...] The only known threats on iOS devices have come to jailbroken phones and the jailbreaks themselves.

It ain't just a river in Egypt.

And that's not even considering threats that come from Apple itself, without any need to install apps or change settings. Something magical happens and things just work.

So what you've got is malware requiring physical access to the device, a dodgy app that slipped through the accreditation process but was subsequently pulled and a theoretical vulnerability that Apple have patched.

If you thing that compares to the privacy sham or security shambles that is Android then you really must be a Google or Samsung shill. (It was obvious from the links you included in your post.)

You utterly fucking fail at understanding security. [...] The only known threats on iOS devices have come to jailbroken phones and the jailbreaks themselves.

It ain't just a river in Egypt.

And that's not even considering threats that come from Apple itself, without any need to install apps or change settings. Something magical happens and things just work.

So what you've got is malware requiring physical access to the device, a dodgy app that slipped through the accreditation process but was subsequently pulled and a theoretical vulnerability that Apple have patched.

If you thing that compares to the privacy sham or security shambles that is Android then you really must be a Google or Samsung shill. (It was obvious from the links you included in your post.)

You utterly fucking fail at understanding security. [...] The only known threats on iOS devices have come to jailbroken phones and the jailbreaks themselves.

It ain't just a river in Egypt.

And that's not even considering threats that come from Apple itself, without any need to install apps or change settings. Something magical happens and things just work.

So what you've got is malware requiring physical access to the device, a dodgy app that slipped through the accreditation process but was subsequently pulled and a theoretical vulnerability that Apple have patched.

If you thing that compares to the privacy sham or security shambles that is Android then you really must be a Google or Samsung shill. (It was obvious from the links you included in your post.)

You utterly fucking fail at understanding security. [...] The only known threats on iOS devices have come to jailbroken phones and the jailbreaks themselves.

It ain't just a river in Egypt.

And that's not even considering threats that come from Apple itself, without any need to install apps or change settings. Something magical happens and things just work.

So what you've got is malware requiring physical access to the device, a dodgy app that slipped through the accreditation process but was subsequently pulled and a theoretical vulnerability that Apple have patched.

If you thing that compares to the privacy sham or security shambles that is Android then you really must be a Google or Samsung shill. (It was obvious from the links you included in your post.)

Know how many people get viruses or malware on their iPhone (without jailbreaking) ... 0.

Looks like you don't know enough people. It has been done, without jailbreaking, and we only know because the developers publicized that fact themselves.. If you want to keep the same answer, perhaps you could rephrase the question as "How many times that Apple admit that they served up viruses or malware in their App Store?"

So you think its better to run extra software, waste more ram, cpu and storage space ... so that you don't get something that iOS users just aren't going to get in the first place?

But what if I don't _want_ a misplaced sense of security based on faulty assumptions?

You utterly fucking fail at understanding security. [...] The only known threats on iOS devices have come to jailbroken phones and the jailbreaks themselves.

It ain't just a river in Egypt.

And that's not even considering threats that come from Apple itself, without any need to install apps or change settings. Something magical happens and things just work.

Until then [I] just make it obvious [I'm] nothing more than a fanboy.

No argument here.

Know how many people get viruses or malware on their iPhone (without jailbreaking) ... 0.

Looks like you don't know enough people. It has been done, without jailbreaking, and we only know because the developers publicized that fact themselves.. If you want to keep the same answer, perhaps you could rephrase the question as "How many times that Apple admit that they served up viruses or malware in their App Store?"

So you think its better to run extra software, waste more ram, cpu and storage space ... so that you don't get something that iOS users just aren't going to get in the first place?

But what if I don't _want_ a misplaced sense of security based on faulty assumptions?

You utterly fucking fail at understanding security. [...] The only known threats on iOS devices have come to jailbroken phones and the jailbreaks themselves.

It ain't just a river in Egypt.

And that's not even considering threats that come from Apple itself, without any need to install apps or change settings. Something magical happens and things just work.

Until then [I] just make it obvious [I'm] nothing more than a fanboy.

No argument here.

Know how many people get viruses or malware on their iPhone (without jailbreaking) ... 0.

Looks like you don't know enough people. It has been done, without jailbreaking, and we only know because the developers publicized that fact themselves.. If you want to keep the same answer, perhaps you could rephrase the question as "How many times that Apple admit that they served up viruses or malware in their App Store?"

So you think its better to run extra software, waste more ram, cpu and storage space ... so that you don't get something that iOS users just aren't going to get in the first place?

But what if I don't _want_ a misplaced sense of security based on faulty assumptions?

You utterly fucking fail at understanding security. [...] The only known threats on iOS devices have come to jailbroken phones and the jailbreaks themselves.

It ain't just a river in Egypt.

And that's not even considering threats that come from Apple itself, without any need to install apps or change settings. Something magical happens and things just work.

Until then [I] just make it obvious [I'm] nothing more than a fanboy.

No argument here.

Know how many people get viruses or malware on their iPhone (without jailbreaking) ... 0.

Looks like you don't know enough people. It has been done, without jailbreaking, and we only know because the developers publicized that fact themselves.. If you want to keep the same answer, perhaps you could rephrase the question as "How many times that Apple admit that they served up viruses or malware in their App Store?"

So you think its better to run extra software, waste more ram, cpu and storage space ... so that you don't get something that iOS users just aren't going to get in the first place?

But what if I don't _want_ a misplaced sense of security based on faulty assumptions?

You utterly fucking fail at understanding security. [...] The only known threats on iOS devices have come to jailbroken phones and the jailbreaks themselves.

It ain't just a river in Egypt.

And that's not even considering threats that come from Apple itself, without any need to install apps or change settings. Something magical happens and things just work.

Until then [I] just make it obvious [I'm] nothing more than a fanboy.

No argument here.

It sounds to me, to be honest, that this was a difficult decision from Google's point of view. I say this because the fact it voided the warranty was obvious from the beginning, and this is a high profile project that would have been closely watched by Google from the beginning. The fact they took several days to eject the app from the store suggests they didn't actually want to, but felt obliged to either because they were under pressure from other members of the OHA, or simply because they didn't want to set a difficult precedent.

I think it's seen as Google is more and more afraid of losing control of Android and the whole reason of why they have Android to begin with. (Remember, Google was deathly afraid of Apple's iPhone OS back in the day - because they were dependent on Apple for mobile revenue. Android was seen as a way to ensure a stream of mobile ad revenue goes to Google).

In fact, Google's biggest threat is Amazon who is having a lot of success with their Android OS.

To combat this, Google has been closing off the source of a lot of Android applications, as well as enforcing the terms of OHA agreements and the like. A regular OHA Android with Google comes with a lot of apps that simply aren't in AOSP - either there's features missing (and the AOSP one is a bare bones version) or by integrating apps to use things that are Google-specific - e.g., forcing use of Google Services Framework. GSF is good in that it abstracts most of the Android APIs away so devs don't have to worry about supporting Gingerbread through Kit Kat, but it also has a nice side effect of tying those apps to Google Play store so devs won't try to submit to the Amazon App Store nor make the app available (easily) to the Kindle.

Google's scared - they bought Android for the purpose of not being locked out of mobile advertising, and it's that very thing that's threatening them.

I think the CM installer was difficult because what CM does may go against Google's best interest (i.e., ensuring you're seeing ads and all that).

It isn't a one-click method to install the CM firmware though - just a method of making the installation via PC less painless. All the app does is basically enable USB debug and help with the ADB setup.

Ars did a pretty decent writeup of the installation process here; http://arstechnica.com/gadgets/2013/11/android-roms-the-easy-way-testing-the-new-cyanogenmod-installer/ - it's certainly not a one-step job.

It would not come close to a 2006 macbook pro.
ARM cpus are not that performant. Ghz is not something you can compare that way.

They're not as fast as x86 yet, but they're catching up. Intel's latest Bay Trail Atom CPUs are fast (outclassing the old Atoms, but benchmarks put the Apple A7 at a bit faster.

Some of it can be explained by CPU speed (the Bay Trail ran at 1.33GHz vs. 1.4 for the A7), but it also means the speed advantage at the low end low cost x86 is being rapidly reached by ARM CPUs.

In fact, Intel wants to position the Atom (especially Bay Trail) as a very fast embedded SoC for mobiles, but if existing SoCs are starting to catch up to it, there's very little advantage.

It also means when Android goes fully 64-bit, you can expect some massive performance improvements (most of it comes from the ARMv8 64 bit architecture more so than any specific microarchitecture change).

But less snide British snark.

I suppose you could http://arstechnica.com/ as well.

Hey, if you're really a masochist, you can go to http://beta.slashdot.org/ for the worst of all worlds!

I'm pretty sure the Boston thing let everyone know that facial recognition isn't what Hollywood has led us to believe it is. here's a link

Facial recognition cant track a damn thing "plenty fast" unless it already know who you are. By that I mean that your identity and location are obviously known. If a guy they're looking for in Ohio pops up in San Fransisco no one would have a clue. And yes, that's if all these systems were interconnected...which they aren't.

So let's get back to the "cards are used to track us because it's a pain to fingerprint every piece of spare change" discussion, please.

Playing devil's advocate here... Why is this result some failure of the judge/jury of this case?

When the guy who invented public key encryption tells you that the basis of the patent had been around for years, that is a failure of the jury in this case.

Except he didn't, and they didn't. Read page two of this article from yesterday about his testimony.

Basically, TQP admits that their patent is obvious in view of a combination of two references, one of which is Diffie's work, and the other of which was some work by Lotus: neither Diffie nor Lotus invented TQP's invention, but if you slap the two together in a reasonable way, they teach everything in TQP's invention, so it's obvious.

Except, Lotus didn't publish their work until after TQP filed their application. And legally, that means it's not prior art, even though they were working on it in secret for some time. In other words, even though someone else invented what they did, it doesn't count, because that someone else kept it secret.

So, Diffie gets on the stand and talks about his work on crypto, which was the first half of TQP's combination. On cross examination, TQP's lawyer points out that he didn't really invent it, did he? And Diffie says that someone else invented what he did, but it doesn't count, because that someone else kept it secret.

So, it sounds like the jury was persuaded by Diffie that TQP's patent was valid.

Newegg lost the trial but has prevailed on appeal with past cases against patent trolls. Newegg had budgeted its legal warchest to include appeal, so the fight ain't over yet.

Buying decisions are often NOT made based on how well a product scores on benchmarks. Evidence: iDevices

Except they win most benchmarks handily.

You can't run a commercial(non-personal) server. But you can run a server for friends and family. http://arstechnica.com/information-technology/2013/10/google-fiber-now-explicitly-permits-home-servers/

The latest CPU is the A7, which is also different from other ARM processors on the market (for one thing, by implementing the ARMv8-A 64-bit architecture; I think it's the only currently-shipping 64-bit ARM processor).

It is, actually - every other 64-bit solution aims to ship in 2014, and Android I think is only scheduled to get 64-bit support in late 2014 as well.

And you want to know why the A7 is so fast? The ARMv8 architecture changes up how ARMs work so they're much more efficient - and faster. The A7 only runs 32 bit code a little faster than the A6, but when you run native 64-bit code, it speeds up seriously because of the way ARMv8 works.

If you're an Android fan, I would suggest buying nothing until Android gets 64-bit native, because it's going to get the advantages we're seeing with the A7 - yes, right now the A7 is keeping up with SOCs with twice the cores (A7 - dual, Snapdragon - quad) and over 50% higher clock speeds (1.4GHz vs. 2.2GHz). Imagine how fast Android will be with those advantages - it'll be 4-6 times faster than what we have today. Doubling the cores and bumping the speed up 50%, that is.

And I'm sure Intel's worried - the latest Bay Trail Atoms are basically even with the A7 in performance. Sure it's WIndows vs. iOS, but on the benchmarks, if ARM is catching up to Atom, then Intel's Atom advantage is shrinking fast. Intel has positioned the mobile Atoms as way better performers than ARMs, after all.

Once the quad core 2.2GHz 64-bit processors come out, Intel could very well be left in the dust.

spammers go to prison[1] or are fined[2]
[1] http://arstechnica.com/tech-policy/2009/11/godfather-of-spam-goes-to-prison-for-four-years/
[2] http://arstechnica.com/tech-policy/2008/11/facebook-spammer-fined-almost-1-billion-under-can-spam/

spammers go to prison[1] or are fined[2]
[1] http://arstechnica.com/tech-policy/2009/11/godfather-of-spam-goes-to-prison-for-four-years/
[2] http://arstechnica.com/tech-policy/2008/11/facebook-spammer-fined-almost-1-billion-under-can-spam/

What?

Of your examples, the first comes closest to reality. It's wrong, of course, but you could make a good argument.

The original iPhone browser wasn't (and still isn't) good enough for high-quality web apps. Of course, at the time, neither was any browser. If you'll recall, Apple didn't seem interested in third-party apps at the time. They were much more interested in controlling what apps were on the platform. (The ability to local/offline local/offline web app with a nice icon on the home screen icon was little more than a vague promise as late as October 2007.) Really, it's difficult to say that it had web apps at all.

The release of the SDK looked more like an attempt to regain some control over the iOS software market, as intrepid hackers had already developed native third-party applications. Jobs couldn't stop it, and the endless exploits were an embarrassment. The world would not let him have his completely closed platform. The SDK let them have some control those nasty third-party apps.

Palm never released a native SDK. The closest they came was the PDK, which isn't quite the same thing. I'm not sure who was complaining, as even the internet doesn't seem to remember. Today, new standards like webGL and the web audio api negate the need that Palm's PDK intended to fullfill.

RIM has always had a native SDK. Nor do I recall anyone complaining about webworks, not that it would matter if they did as there has always been an NDK.

It is so much better to let the exit node owners to monitor your traffic right? Ok fine, they can't trace it back to you, but do expect every malicious thing possible to be done on your traffic.
http://arstechnica.com/security/2007/09/security-expert-used-tor-to-collect-government-e-mail-passwords/

The PS4 is smaller than the second PS3 slim. I wouldn't call that a trip back to anything. The XBox One on the other hand is as big as the original 360 and looks like a crappy HTPC case. Look at the ars technica comparison if you want to see the difference.

If you liked that, I would recommend this and that, also.

Great idea but it's not exactly a secret that Google has a lot of trouble convincing carriers and OEMs to update their devices. Ordinarily, that would blunt the ability to fix problems and add features to existing devices but Google has an answer to that. Since Google can't convince carriers and OEMs to update their devices (apart from Google's own Nexus line), Google crafted a workaround.

If you have an Android device and you check your installed apps (make sure its on the All tab and not the Downloaded tab) you'll probably see an app called Google Play Services. If you check the permissions on this app you'll see it pretty much has the authority to do pretty much anything it wants. It can even alter its own permissions without notifying the user and updates itself silently without relying on the Play Store to do so. Ordinarily, this kind of God-like app would be creepy but Google has basically used it to bypass carriers and OEMs and push out new features without having to actually update the OS. Pretty much any device running Froyo (2.2) or higher uses this.

I wonder if Google actually needs to update the Android OS itself to fix bugs or if they can just use the Play Services app to work around this.

Yes, filing false DMCA is explicitly defined by the law as perjury and the EFF is currently pursuing a number of these cases. The problem is that perjury is defined as the "willful act of swearing a false oath" so they're just going to claim that they didn't know the takedown notices were wrong and that it was just a mistake.

Which raises the question, when did they find out the program kicked out false positives and did they continue to use it after that? IANAL, but if they used a program they knew would commit perjury, I can't see how it's different than committing the perjury themselves. I find it pretty implausible that a company that lives by its copyrights doesn't know -- and is not required to know -- what a legitimate copyright claim is.

Maybe next year, maybe in 5 years, or maybe in 10 years but every single enterprise will eventually be forced to make this switch as Microsoft evolves and changes ('implodes' is the word that comes to mind) as it tries to maintain growth and earnings...

Microsoft is doing extraordinarily well in the enterprise market and talk of an implosion is nonsense.

Commercial Licensing revenue was $9.594 billion, with a gross margin of $8.801 billion. This is growth of 7 percent and 8 percent, respectively. SharePoint, Exchange, and Lync all achieved double digits growth, and multi-year licensing revenue was up 8 percent.

Commercial Other revenue was $1.603 billion and had a gross margin of $0.275 billion, growing by 28 percent and 161 percent, respectively. Cloud revenue was up by 103 percent, with both Office 365 seats and Azure customs both increasing by triple digits. Two thirds of Dynamics CRM customers are now opting for cloud deployments.

Windows Division notional revenue is up 4 percent at $4.581 billion, but operating income is down 20 percent at $2.242 billion. This shows just how significant the impact of the decline of the PC market is, as well Microsoft's continued failure to capture any significant share of the tablet market.

Server and Tools revenue was up 11 percent to $5.052 billion, and operating income was up 17 percent to $2.026 billion. In contrast to the Windows Division results, this shows the much greater resilience of the purely enterprise-focused offerings.

Microsoft posts record Q1 revenue, increased operating income: Windows OEM revenue sharply down, but enterprise sales buoyant.

Until VERY recently, the AOSP camera app was pretty crippled compared to the camera apps that shipped with the phones insofar as things like HDR, anti-shake, etc. were concerned.

Still is, actually. Google's been slowly closed-sourcing a lot of Android in an attempt to thwart manufacturers using AOSP from shipping phones that work almost like, but without, Google. (Remember Android was purchased by Google because Google was worried Apple would turn the screws down on Google and iOS.). With stuff like the Kindle showing that AOSP is worthwhile, Google's been withholding new development on AOSP to favor official Android releases.

Ars Technical details the differences between "official" and AOSP.
http://arstechnica.com/gadgets/2013/10/googles-iron-grip-on-android-controlling-open-source-by-any-means-necessary/

Interestingly, only Samsung has a complement of apps that can be a 1:1 replacement for Google's.

I'm one of the people who is still mad about the OtherOS removal. Yes, I'm aware that due to how the PS3 hypervisor limits the system that running Linux on a PS3 is comparable to running it on a Raspberry Pi. Heck, you've got more usable RAM on the current Pi than on the PS3. That's not the point.

The end result of the SCEA v. Hotz fiasco is that once the warranty period is up, Sony can do whatever the hell they want to your console. Any feature is fair game. Sony could legally push an update that turns it into a paperweight if they desired and you would have no recourse. As an addendum, the warranty isn't transferable so this could legally kill the used system market if they so desired.

The warranty time used to be a safe period at the beginning of a piece of consumer electronics usable life where if it broke you would be able to get a replacement. Now, it should be seen as the entirety of the devices usable life.

If you are planning on buying a PS4, make sure that you buy the extended (2yr) warranty. Make sure that you get your $450 worth over then next 3 years. Go into this with eyes wide open.

Yes, this doesn't just apply to Sony but they are the ones specifically have it in their warranty clause, went to court to confirm the legality of it, and are otherwise actively hostile to their customers.

http://arstechnica.com/gaming/2011/02/otheros-class-action-lawsuit-geohot-sony-now-share-same-charge/
http://www.groklaw.net/article.php?story=20110218181557455

http://arstechnica.com/tech-policy/2013/11/apple-hopes-to-win-back-380m-in-damages-re-trial-against-samsung/ [arstechnica.com]

Of course Slashdot'll never report it, cause they're in Apple's pocket.

http://arstechnica.com/tech-policy/2013/11/apple-hopes-to-win-back-380m-in-damages-re-trial-against-samsung/

Of course Slashdot'll never report it, cause they're in Apple's pocket.

... the recommended work-around means significantly longer charging times: http://arstechnica.com/gadgets/2013/11/reports-of-overheating-chargers-halt-hp-chromebook-11-sales/

Or they could ship beefier chargers.

It's the one problem I have with USB charging protocol - there isn't any. There's no way for the device to detect anything other than "a charger is connected" - which leaves a lot up in the air. Is it a 500mA charger? 800mA (initial USB charging spec basically said you could assume 800mA)? 1A? 2A? More?

Now, your device COULD try to ramp up the charging current draw and see if it can find the "knee" where the charger output drops as it goes into constant-current mode. However, there are plenty of crappy barely adequate chargers out there that would probably smoke, overheat, catch fire, etc., as they try to handle the load without going into constant current mode. And the output can be so noisy that it's impossible to determine. (That's why your touchscreen stops working when you plug it in - upgrade to a better charger)

It is sort of where the Apple method is superior in that it at least can tell you electrically (because some "2A" marked iPad chargers are actually wired for 1A charging - fraudulently marked chargers, what else is new?).

... the recommended work-around means significantly longer charging times: http://arstechnica.com/gadgets/2013/11/reports-of-overheating-chargers-halt-hp-chromebook-11-sales/

even when the phone is switched off, it continues to slowly ping cell towers

Got a source for that? According to Samsung and Nokia, they have no idea how that would be possible*. I'm not saying they aren't "under oath to lie about it", but if you're going to pimp that legend, at least enlighten us as to the source of your infallible research on the topic.

[*] http://arstechnica.com/security/2013/11/samsung-nokia-say-they-dont-know-how-to-track-a-powered-down-phone/

Sounds like you missed this little tidbit.

Actually, if you look at the benchmarks it loses in everything but the GL benchmarks. Then go and look at the benchmarks at phonearena and the 5S hands the Nexus 5 it's ass on pretty much every test.

Actually, the Nexus 5 comes on top of the iPhone 5S in the GLBenchmark v2.5.1 tests in the HotHardware article, but loses in the GFXBench 2.7 tests in the Ars Technica article.

How did this happen? After all, GFXBench is the successor of GLBenchmark. My first guess was that maybe GFXBench 2.7 was compiled for 64-bits on the iPhone 5S, while GLBenchmark, being older, was probably running in 32-bit mode. (These tests measure mostly GPU performance, but getting the CPU to perform faster should help at least a little.) But it turns out that GFXBench 2.7 probably hasn't yet been recompiled to run in 64-bit mode on iOS yet.

Actually, if you look at the benchmarks it loses in everything but the GL benchmarks. Then go and look at the benchmarks at phonearena and the 5S hands the Nexus 5 it's ass on pretty much every test.

Actually, the Nexus 5 comes on top of the iPhone 5S in the GLBenchmark v2.5.1 tests in the HotHardware article, but loses in the GFXBench 2.7 tests in the Ars Technica article.

How did this happen? After all, GFXBench is the successor of GLBenchmark. My first guess was that maybe GFXBench 2.7 was compiled for 64-bits on the iPhone 5S, while GLBenchmark, being older, was probably running in 32-bit mode. (These tests measure mostly GPU performance, but getting the CPU to perform faster should help at least a little.) But it turns out that GFXBench 2.7 probably hasn't yet been recompiled to run in 64-bit mode on iOS yet.

Mozilla, behind the scenes, no in the open, at W3C and IETF is making sure it stays that way as much as possible.

If you think things can't change you clearly don't live in the real world.

Mozilla was important and Mozilla remains important.

As an example is iOS. An other example is Androidm which is getting more and more closed:
http://arstechnica.com/gadgets/2013/10/googles-iron-grip-on-android-controlling-open-source-by-any-means-necessary/