Google Pixel C Review
anandtech.com
anandtech.com
1. Pick a product. (Pages, for example, or Logic Pro. Or the entire platform -- OSX.)
2. Create a new version with significant feature regressions (e.g. Pages 5, iOS in the early years, Logic Pro X).
3. Keep an eye on what features the customers are screaming about losing, and re-implement them (but not the bits nobody cares about).
4. Screams subside, product reaches parity again -- but is a lot less crufty, easier to maintain on new platforms.
Google hasn't mastered this art, and they're unsure what their operating strategy is. First there was Chrome the browser, then ChromeOS (a thin client platform), and Android because they needed a phone OS, then running Android apps on ChromeOS, then this idea of giving ChromeOS touch support so it could replace Android, then the flagship touch-ChromeOS platform (the Pixel-C) has to ship before the OS is ready and it all falls apart. With much wheel-spinning, Google ends up falling behind an in-some-ways-inferior Apple competitor because they don't focus on iterative design.
(Am I barking up the wrong tree here? TL:DR is the Pixel-C hardware looks gorgeous but the software is clearly a case of "dammit, we have to ship now, what OS can we dump on it?" rather than any strategic planning.)
I have a feeling that the code in Android to render a ChromeOS-like UX is sitting nascent on the Pixel-C, just waiting to be patched a few times to smooth out bugs, before being flipped on.
This is a really low bar. Enough Android device makers never provide updates. Got a Nexus One a few years ago, Google updated it for a grand total of 13 months before deciding it was "too old". Of course I didn't get the Nexus One until most of the way through that time period so my Google phone was updated for perhaps six months, not exactly a great user experiance.
> "Galaxy Nexus, which first launched two years ago, falls outside of the 18-month update window when Google and others traditionally update devices."
18 months is far too little, especially if you do not buy a phone on day one.
I don't think Android TV has ever gotten much love either.
Glass went from monthly updates to completely unsupported, practically overnight. That actually was being openly sold on the Play Store for a while too.
I'm not saying they haven't been on the ball with most of their mainstream products, I'm just saying you should bear in mind that they've let plenty of their failures just die on the table too.
It's a 10" Android Tablet. Looks nice enough I guess. Don't really see what it has to do with ChromeOS or the Chrome Books other than the reuse of the name.
And re: the Apple point, this is pretty much exactly as "incremental" over a ChromeOS device as an iPad is with over a MacBook.
Link: http://arstechnica.com/gadgets/2015/12/the-pixel-cs-bumpy-ro... Discussion: https://news.ycombinator.com/item?id=10713384
According to Google [1], "Pixel is Google designed hardware; Nexus is hardware we work closely with partners to design".
[1] https://www.reddit.com/r/IAmA/comments/3w3x7p/hi_im_andrew_h...
Sounds like a reasonable method to ensure you focus on the 5% that's most imortant. http://venturebeat.com/2016/01/05/evernotes-5-problem-offers...
Any other company that we see remove features and not support the ones they created would get absolutely castigated, not referred to as a win/win/win.
Apple is a bad actor for letting iTunes become a bloated piece of shit. They'd be a good actor if they cut all the crap and released a new product, or products, with fewer features but more focus.
You're reframing the argument in an Apple-friendly way. Screaming isn't a sign of a win, it's a sign that Apple doesn't know what to trim ahead of time - that is in no way a win for the customer.
(i guess itunes is privilaged if you're still syncing files back and forth from comp to phone, but who does that anymore?)
(itunes is terrible, by the way; very heartily agreed on that point.)
Except for the customers who bet their livelihood on you and now have to turn their entire workflow upside down to accommodate your lack of interest.
The Pixel C had the potential to be a very nice open machine. It's even shipped with the Nouveau driver. And it runs Coreboot. But sadly Coreboot is locked down in this particular case.
Also, I don't get why they mess up with the keyboard layout. Many useful keys have been removed like tilde or backslash. Yes, they are accesible via a sort-of-compose-key labeled "...". But then I need to retrain my muscle memory.
It's otherwise a fantastic machine, so I'm a bit sad for the missed opportunities.
They don't strike me as an Apple type company that strategizes obsessively around a few products.
One of the things they are especially good at is to never introduce hardware which isnt followed by a serious piece of software. So I think it comes down to a kind of culture Apple have honed over the years.
Likewise, your expectations for long term support on Apple stuff is probably going to be different than Microsoft and Google stuff. I don't think Apple customers are happy with the behavior your describing, they're just way more willing to tolerate it because it's not unexpected.
The thing is, I don't think Google could get away with doing the same things. I think Apple's strategy works for Apple, but I don't think it generalizes.
As an Android user, I am positively revolted - outraged, really - when an Android hardware manufacturer locks the bootloader making custom ROMs mostly impossible. And yet it doesn't bother me that much when Apple does this?
As an Apple user, I'm upset when my Apple device doesn't behave smoothly and responsively. Really, it needs to be like butter. And yet as a Note 4 user, I overlook all sorts of bad Android behavior - slow app startup, poor battery life, not being able to hold more than 3 apps in memory on a 3GB RAM device, dog-slow task button. Not terrible at all, but certainly not like an iphone.
The proof is the amount of ChromeOS devices one sees on sale here in Germany. Almost zero and the ones that do sell, tend to get discounted almost all the way to zero before anyone buys them, just to replace ChromeOS with a standard GNU/Linux distribution.
As for Oracle's suing them, Google should have played by the rules all JVM vendors follow instead of playing dirty on Sun.
Go read some sysadmin posts about Chromebooks, they are highly loved by schools. They are cheap, interchangeable between students with little issue (since it is all cloud based), and have great admin tools when you have a fleet of them.
Not saying you're wrong about Google, though. I'm sure the Pixel-C problems are quite real: I encountered all of them myself, when my Moto-G was essentially bricked by the update to Android 5 (think 10-to-30-second lag on every keypress).
These frustrations with my Apple computer and Google phone are almost bad enough to push me into the arms of Microsoft... or would be, if every interaction I had with Microsoft products didn't immediately show them to be even less competently executed than Apple or Google.
This is aggravating to no end. Top of the line (mobile) hardware, years and millions of dollars in engineering effort, and perf still sucks. I've tried very hard for years to be charitable about this problem: programming is hard, and there are a lot of smart people working on this.
But something is fundamentally broken with Android's abstractions. I don't know enough about Android's architecture to say what it is -- but there is no other reason for perf to still be a problem [1]. Every Android device I've owned has had these issues, while my $45 Nokia Lumia Windows phone has been consistently responsive for over two years, on marginal hardware. What the hell is going on here?
[1] Either that, or critical code paths are being bloated with unnecessary features faster than the runtime and hardware are improving. Which would still be surprising, because that has to be a lot of bloat.
The JVM itself has a certain amount of unavoidable overhead, but even if it was e.g. 10x slower than native code at best, I don't think that's the main problem. I've used systems that were more than 10x slower in benchmark-terms and had less than 1/10th the memory, yet felt much more responsive and performant. The problem is the culture that encourages this massive resource waste and selfish conservation of developer's time --- at the expense of everyone else.
That is not a "certain amount of overhead" but the inherent incompatility with the modern hardware. With Java writing cache-friendly code is extremely difficult: boxing and indirections are encouraged while primitive types are cumbersome and value types are possible only through the direct byte manipulation. Memory overhead is enourmous. A simple collection like a hashmap of short strings can have up to a 75% overhead.
That can't be the whole story though, because C# and VB.NET both (seem to) perform decently under a managed runtime on Windows Phone. Wonder how big of a role the CLR has in typical WP apps and the WP core, as opposed to unmanaged C/C++ code.
On Windows Phone 8.x, it uses MDIL (Machine Dependent Intermediate Language) meaning native code with symbolic names for the on-device linker.
On Windows Phone 10 onwards, it makes use of .NET Native.
Both are based on Visual C++'s backend, which is way more world battle tested than ART.
.NET also supports value types.
Also the XAML layouts are compiled to binay, not interpreted on load like on Android (aka inflated).
Windows Phone also only supports asynchronous code, graphics and sound APIs must be hardware accelerated.
That means a "new Object()" takes up 16 bytes (8 bytes for the object, 8 for the pointer to it). That means you fill a cache line by allocating 4 objects, or 2 objects containing a single reference, or ...
So in java you should never program a line drawing loop by using 2 vectors, because 2 vectors, each with 2 32-bit ints take up 82 (2 pointers to the objects you're using) + 82 (overhead for the objects) + 4*2 (the actual data) 40 bytes of data. No way you can fit that in registers and still use registers to actually calculate things. So instead you should use 4 ints and just forget about the objects, and even that will only work if you never call any functions.
Same loop in C/C++/Pascal/Go/... using structs takes 8 bytes (they don't keep structs on the heap), which, if necessary, fits in 1 register (granted, in practice we're talking 2 registers, but still).
People might reply to this with benchmarks, but if you actually analyse the java code where java beats or is comparable with C/C++ you're going to see zero object allocations. You're not even going to see them using bool in the extreme cases, rather they'll bitshift into ints to effectively generate packed bools (certainly in SAT benchmarks). This is not realistic java code, which would have been way slower.
Java's memory model is the main culprit at this point in time. Java can do incredible tricks with programs, and actually exposes them, enabling lots of language creativity on the JVM. But there's a pretty sizeable cost in speed and memory usage.
Only in JVMs and AOT compilers that don't do escape analysis.
Also don't forget Smalltalk, which also only does references, was running in the Alto, Dolphin, and Dorado workstations.
For example the Dorado was:
- 128-512 kB
- 606x808 pixels
- 4 74181 CPUs
So how does that compare to a beefy Android device?
Also J2ME and Embedded Java are running quite well in many embedded platforms, in a few hundred KB steering soft real time systems like robots and missile radar controls.
So yes, Java might not offer all the memory control features that other GC enabled languages do, going back to Algol 68, Mesa/Cedar, Eiffel, Modula-3, ....
But given the performance of commercial JVM vendors, I would say Google has a lot of blame as well.
EDIT: Forgot to add that when Java 10 comes out with value types and reified generics (according to the roadmap) this will become a moot point, except of course for Android Java given Google's unwillingness to provide support for the real thing.
https://docs.oracle.com/javase/specs/jls/se8/html/jls-12.htm...
"Whenever a new class instance is created, memory space is allocated for it with room for all the instance variables declared in the class type and all the instance variables declared in each superclass of the class type, including all the instance variables that may be hidden (§8.3)."
Doesn't seem to allow for escape analysis eliminating the object. Plus escape analysis wouldn't really save you. These are class instances, you pretty much have to declare them before the scope you use them in, if you're using them in the condition of a while loop (which would be the way to use them).
I seem to have this experience in practice. If you have a value type and loop over it, creating a "dummy" instance of it outside of the loop, then erase and reset it's inner state on every loop iteration is far faster than creating an instance inside the loop. So I don't think escape analysis optimizes this case.
For example, if you declare something like
final class Point {
final int x, y;
//...
}
IBM J9 also does similar optimizations via packed objects, as they call it.
JIT compilers also remove locks and synchronized blocks if heuristics prove their are never needed in the dataflow.
In any case, by Java 10, real value types are expected to be part of the language.
Why ? Because it just went from O(N) with no allocations to O(N^2) because it has to constantly extend and walk a list (the free memory list, which is lower bounded by the number of iterations of the loop) on every iteration of the loop (malloc is O(N), so calling malloc in a loop automatically increases it's complexity, and compilers change stack allocations into mallocs due to optimizations).
I've seen this happen many times. And then, after 2 weeks of searching you find the cause : someone changed 3 * i into i * 3 in a method which caused autoboxing to suddenly actually occur.
Counting on compiler optimizations to save your ass is incredibly, incredibly brittle.
I can provide some presentations from Java Language Summit
> Counting on compiler optimizations to save your ass is incredibly, incredibly brittle.
I agree.
Ada, Delphi, Modula-3, Oberon or Eiffel could have been in Java's place with the right stewardship, but sadly it wasn't it.
I also don't see it getting replaced anytime soon, hence why I welcome the idea of eventually getting value types and proper AOT on the reference JDK while keeping the huge set of libraries that we have available.
In any case, I am both a language geek and a polyglot developer, so I have fun discussing this kind of subjects not being language zealot.
I've noticed that tends to be true in general for benchmarks of high-level languages which show them performing as well as or sometimes even better than C/C++ --- the code performs so well because it's essentially using none of the other language features that most code in the language does. I touch upon this in my other comment here about culture: the language theoretically allows you to write quite efficient code, but it doesn't look "idiomatic" or perhaps isn't a "best practice", so it's discouraged and isn't done. The entire dogma of avoiding any optimisation compounds this problem even more, since once programmers finally realise they have performance issues, they've already created such complex and inefficient code that it's even harder to do any optimisation on.
On the other hand, idiomatic C tends to be written in a simple and straightforward style that is naturally quite efficient already. C++ is similar, although templates, OOP, and all the other new features can lead to inefficient code if not used in moderation.
I suppose the ultimate example of what could be called "intrinsically efficient" is assembly language. With Asm, every instruction, every byte you can save from typing is one the machine also doesn't have to execute, so you're basically forced to optimise as you write. There's certainly no desire to overengineer things, simply because of the extreme tedium and futility of doing so. With no IDE to help you generate classes and autocomplete indirections, it really changes your perspective of what constitutes efficient code.
The problem is that Dalvik never had a GC and JIT support that could compare with other implementations.
Even ART seems to still have lots of optimization opportunities to explore.
Even if some of the code looks like written by devs recovering from years of exposition to hungarian notation.
They are smart engineers though and I have no doubt that if C++ had been the best choice for the platform, we would not be writing apps in java ...
tbh, I am really tired of the simplistic 'because java' argument with nothing to back it up ...
I have no love for the language (although I think it gets more flak than it deserves) but I have spent a lot of time working on the performances of Android apps and none of the issues I have fixed would have been any different in another language.
So given that I enjoy C++, when conding on my own, that is what I end up using for hobby coding between mobile platforms. But the NDK and JNI wrapping take the fun out of it.
By design, the NDK can only access a very small part of the platform APIs.
It is not an issue if you are making something where you are supposed to use the NDK (like a drawing app or a game), but for a 'traditional' app, that's another matter.
But if Clojure did support properly Android and CoreCLR, I would probably use it instead.
As things are, I might go Xamarin in the future.
Otherwise, Kotlin borrows many niceties with c# and allows you to directly use the platform APIs.
You can see this with the Material Design specs as well - the rendered demo videos (e.g. https://www.youtube.com/watch?v=Q8TXgCzxEnw ) from the Design team are amazing, but what's actually been implemented on Android is far less sophisticated and even then they frequently skip frames. Interestingly, many of the Google apps are much closer to the Design specs and perform better on iOS and even on the web, at least in Chrome.
Hopefully this will finally be resolved with the Chrome OS merge (Chrome OS has great performance) - It must be extremely frustrating for the Google Design teams when they can't implement their designs properly on their own platform.
One problem with Android is that they went software rendering since the early days, and even with all the changes to hardware rendering, there are code paths that will trigger software rendering.
Now they started advertising Android M should have proper audio support, but it doesn't seem like it.
Even with ART, it appears that compilation to native code still needs to improve a lot.
iOS and WP have much more care in native code performance, hardware rendering and real time audio support.
Then by making use of programming languages with support for value types, they require way less memory than Android devices.
Apparently it is better to spend resources playing IDE and build tools migrations.
but there is not and never was a global lock.
Also, how much of the performance grade is due to the reviewer ? I see people saying 'one need at least <2013> hardware ...' as if people couldn't do anything before. Coming from someone on a 2007 laptop .. I wonder how much social relativity plays here.
[1] When I boot an old 4.4 phone, I feel relieved to see simple centered gray/blue menus, even after a year of Lollypop 'training'.
>But something is fundamentally broken with Android's abstractions
I think that the core problem is that Android has been built to be a multi process OS at its core with little regards for UI perfs. Things have been moving in the right direction since at least Android 4.0, but it seems that there is a lot of space to cover. Android has just got a RenderThread with Lollipop IIRC, iOS had one from day one.
If you read all the reviews of the Pixel C out there, you'll see that Ars Technica complained about touch sensitivity, but nobody else did; and not even Ars complained about performance or overall reliability.
I own a Pixel C, and haven't encountered any of these problems. It's on the crashy side for an Android device (it reboots itself randomly about weekly), but nothing like the kind of issues that Anandtech had.
My suspicion would be that they have quality control issues, and that Anandtech (and Ars) got defective units, but the Anandtech statement about Google preparing a software patch makes it sound like there's some kind of software issue -- but what kind of software issue affects a subset of devices?
That said, it's a solvable problem - really, the first iPhone in 2007 solved it. This shouldn't be an issue in 2016 anymore.
Hearing about things like this makes me wonder, "What happened to the concept of uptime?" Recently on HN there was discussion about how Windows 10 would force reboots to update, and make users lose all their unsaved work.
20 years ago, I remember Linux/UNIX users would ridicule Windows users for their frequent crashes and need to reboot, and pride themselves on months or even years of uptime. Now we have Linux-based Android that appears to be just as unstable?
I can't say I haven't noticed a few of the lags and keyboard glitches mentioned, but probably not more than a handfull over a month. The Pixel C has nearly replaced my Mac Book Pro 2015 for all of my browsing, note taking and communication.
The keyboard is really good and with apps like Termux, I've also done quite a bit of coding in vim. I'm hoping it'll get split screen soon though.
Feel free to ask any questions.
You could do CTRL-[, but I don't see the [ available on there either (at least obviously).
One of my main reasons for a keyboard on an Android tablet is to be able to access remote SSH sessions, edit files if necessary (vi, etc) and so forth.
For navigating Android
Home — Search + Enter
Back — Search + Backspace
Recent apps — Alt + Tab (same as it ever was)
Missing symbols
Brackets — Use three dots + o for left bracket [, three dots + p for right bracket ]
Back slash — Three dots + equals =
Escape — When would you use this? We don't know. But it lives at three dots + 1
The Pixel C actually has quite a lot of useful keyboard shortcuts: https://support.google.com/pixel/answer/6326992?hl=en&ref_to...
Although that's somewhat of a simplification for delete.
Haven't really needed a separate delete/backspace key. About the only time I use the separate delete key even on windows/linux is in the file explorer.
Page: Fn+Arrows
Delete: Fn+Backspace
The other reasons would be mostly OS X's arguably smoother and overall consistent GUI and its extensibility (through Automator, scripts, globally modifiable shortcuts and the like) and its Unix'ity.
With Termux I was quickly able to grab everything I needed with the package manager. It certainly didn't feel laggy at any time. (Yet)
0: http://www.anandtech.com/show/9972/the-google-pixel-c-review
It sounds like they both suck :)
No sane company is going to invest more money in a platform than they believe they'll eventually get a return for, so that's generally an upper bound. You don't spend 20 billion on a project you think will net you 5 billion in revenue.
That is completely incorrect. It depend on strategy of company . If company consider some product to be strategic place, they will spend hell more than what they will get in return. About android it is same. Google does not think about Android as strategic product (they maybe change their mind after windows 10 attack and Microsoft revive, I dunno).
Mostly they think that is something we have , we provide it to the market , specially to the third world . Just for getting more and more people access to the internet.
That's all.
It also feels kinda old seeing own Google apps completely un-optimized for tablets, while they're cheering for developers to do so for third party apps on IO. If Google doesn't bother, why would anyone else ?
At this point I would normally continue to run our PCMark
and GFXBench battery tests. Unfortunately, the Pixel C's
software makes it incapable of completing either of them. I
made five attempts to complete PCMark, which took a great
deal of time as the test runs over many hours. In all cases
the tablet locked up during the test and required a hard
reboot. It may be possible to eventually get it to
complete, but I didn't feel that it was worth delaying the
review further in the hopes that I could eventually get the
Pixel C to complete the test properly.
Google does know very well this Microsoft is going to hurt them really bad. The recent news about Google working on Desktop OS is google's answer to Microsoft moves. Microsoft prepares itself to make greatest Desktop OS in the whole market in next 3 year.
And Google does know if Microsoft unifies all its user under windows 10 and windows do provide them best desktop experience, eventually they will find a way to take away user from Chrome(browser)/Android to their own platform.
The only move google can make in this position, is to work on windows replacement. (and as news came out, they are doing).
and they choose android rather than Chrome os to be their desktop os. Let's not kid ourselves, chrome os will not be mainstream os maybe until 30 years . (the networking technology is not there yet, it doesn't have anything to do how great/secure is Chrome OS).At the other hand they had android.which is fragmented, which is not that great. but they have a huge userbase. And they are working on a desktop version of android.
Can you point to any link on that ?
Microsofts market share in mobile/tablets is abysmal, at this point it is more likely that users will shift from Android/Windows to iOS and Macs.
Let me know how my countryman earning on average 380 € monthly are going to shift to iOS and Macs.
My point is that the parent just declares what he hopes will happen as if it was a fact without giving any kind of evidence supporting it. And that is exactly what he/she did.
The wifi was flaky at best, often refusing to connect when my nexus 5x right beside it had no problems. Browsing the filesystem was an exercise in madness. My Amiga 500 running at 7MHz was MUCH more responsive. I used a stopwatch to time 27 seconds from double click to actual display of a jpeg image in the image viewer.
I averaged about two OS crash/forced reboots per day on it until I finally gave up and got a macbook.
In my mind, it's a better experience than any of the iPads of various version that I also have, and it is also rock solid.
But really, laptop replacement? Even with a keyboard both an iPad or any Android device will suck. My poor kids are using their iPads in school, but if I had to do serious work with it, I'd probably go insane.
I know this is not what you meant but I find this sentence hilarious. Poor kids indeed, having to endure using an iPad at school, nevermind that for most of us school consisted of just pen, paper, books and not much else :)
Nope. Android keyboards are still terrible. All the android terminals that I've tried suck. It constantly locks up. It's got so much potential, and somehow falls so short.
But we are lacking on the software, and you see it everywhere
-Microsoft and the tablet/desktop os which haven't get
that much hate lately
-ios and let's fix everything we break with the ios7
and newer (e.g. small tiny buttons for music controls on
the lock screen of the ipad....)
-android and... oh well you have the above review.
A web UI isn't good for a touch-only configuration. The web grew up with pointing devices, and "mobile web" apps haven't been competitive with native apps on touch-first devices. A web tablet would suck, too.
Microsoft has been banging their heads against this unwise unification until they missed the whole mobile market. You can't drag Windows into a touch-first world, and your ISVs will never get to where their apps work well in a touch-first world. It just ends up being a not-quite-getting-there mess.
Another way to look at it is: Try using a Google web app on a touch convertible. They're terrible. Not even trying to get touch right.
If you're talking specifically about Google-branded devices (as opposed to e.g. an ASUS Chromebook) the Pixel 2 was released in March 2015, about 2 years after the original Pixel.
Tbh, I would pay an additional $500 to a company that cloned the hardware but offered at least a 512 GB hard disk. I've even give up the touch screen. I'd like a quad core Skylake upgrade while we're at it, but I'm not greedy, I just want a reasonable amount of disk. They could even price it at $2000 and I'd still buy it in a heartbeat. As is, I'm still using my Pixel 2 LS, albeit with a slimline USB key pseudo-permanently attached to provide extra space. Nothing else approaches the power and battery life of a Macbook Pro if I want fully supported hardware under Linux.
ChromeOS + Crouton + a decent SSD would make a killer development laptop.