It looks from where I'm standing as if Apple has a methodology for getting rid of legacy cruft while keeping the important bits, viz:
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.)
In Apple's case some of the screaming stopped because people just decided to drop the product (e.g. Final Cut Pro X) and go with a competitor (e.g. Adobe Premiere Pro).
Apple doesn't support aspects of the product they don't want to support. Consumers get what they want from another business. That business gets, well, business. Sounds like win/win/win!
Well it's easy to forget though, that Apple used to have a long running policy of not allowing any apps that compete with built in software. They've softened on that, but it's still often the case that third party software on Apple devices is very much second class citizens. I'm a relatively happy Apple user, but there's a lot of software they provide that is imo awful, but can't reasonably be substituted (I'm glaring at you, iTunes). So I don't think you can really argue what Apple does is a win for for customers.
I don't know about "rapidly". From what I can tell, there is a committed bunch of us who will carry on as long as our devices continue to work. Just because they're no longer being sold, doesn't mean they don't continue to be used. The demand for a relatively cheap high-capacity portable music player hasn't just disappeared into thin air.
The bad actor is the company whose product grows too wide for them to support. Trimming back is a good actor.
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.
> The bad actor is the company whose product grows too wide for them to support. Trimming back is a good actor
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.
Apple as a model for how to produce slick software? Once upon a time, perhaps -- but these days, surely you jest! The quality of their software has become abysmal. The latest versions of iMovie, Pages, Keynote, and Numbers, on the App Store, have a median user rating of one star. Tasks which I was routinely doing with those applications, 5 years ago, are now impossible. That's an intolerable situation.
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.
Android must grind on Google's product vision. Especially with Oracle suing them. This whole app store widget dashboard Java ecosystem is antithetical to the web as a platform Google has wanted since the 90s. ChromeOS is the goal - the problem is getting there without driving all those Android users, developers, and revenue streams away.
I for one hope that ChromeOS goes away, I will never buy a browser as main OS.
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.
In the US I have seen it only once: from people who got them free from Google I/O. But they still sell a lot of these devices. The target market are people who just need a browser or for schools.
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 only that. But they are also doing odd stuff with the hardware, although most users probably don't care about this.
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.
Well, I think the expectations for Apple stuff tends to be different, just because of their identity and their core customers. To draw an analogy, if you drive an Alfa Romeo, your expectations for reliability are a lot different compared to a Toyota Corolla. You certainly wouldn't be happy if your Alfa breaks down... but you wouldn't be shocked either.
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.
Well, let me vote you up to compensate. I think maybe the way you phrased it seemed like you were implying Google hold themselves to a higher standard than Apple, which certainly isn't the case. But I agree with you - Apple users have different expectations than Android users.
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.
Hmm, since I'm getting downvoted (which is fine, maybe you all just disagree), I should clarify none of that is meant as an insult to apple customers. (I'm one of them!) Just pointing out that different brands have wildly different consumer expectations.
Dunno, seems like if they had just called this a "Nexus" and not a "Pixel" most of your points would fall apart, no?
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.
Google specifically bragged about the Pixel C's odd screen ratio as being designed to run side-to-side apps at a specific aspect ratio. That indicates either an Android feature set not currently available, or a Chrome OS one. The device was clearly not designed to run Android as it exists now.
Google's strategy here might just be "hey, you can buy it now if you like, although it's not ready yet, and still get some use out of it early; but after a few point-releases, it'll turn into what it was supposed to be."
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.
I think that thing works for enthusiast projects targeted towards technical users (like, for instance, linux distros), but I have to imagine doing that with a consumer device is a really really bad idea. I'm not sure if this is a great comparison (because it didn't really work out), but people are going to be a lot more patient with, I don't know, something like Firefox OS compared to Android.
I think the jab is misplaced here since Google obviously has the best track record of Android device makers on updating their products. Nexus 10, the spiritual predecessor of Pixel C, is still getting updates. It won't get Marshmallow, but still active after over three years is way better than any other Android manufacturer I know of.
> Google obviously has the best track record of Android device makers
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.
I bought my Note III when it came out in 2013 and have had constant support for it from Samsung. Google dropping support for their own device in their own platform really does not speak well.
That's with mainstream phones, yes. But not with niche products that fail to launch. I have a Nexus Q. Even though it's more powerful and capable than the Chromecast in almost every way, rather than update it to support the new Chromecast protocol, they removed the code that even allowed it to work at all from YouTube and Play Music, effectively bricking it.
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.
That has always been my impression of Google's multi-OS strategy - Chrome OS is the "pure" operating system, where Google gets to say NO to as much as they want and just give users the features they think users need ChromeOS has a vision (even if it is an ever-changing vision), and it's up to the users to conform. Android is the forgiving operating system, it's where the engineers build the features users or OEMs are asking for rather than the features google is asking for.
I'm thinking it was more along the lines of someone in the group responsible for Chromebook Pixel being like "Hey, lets take the Pixel brand and make a tablet under it."
They don't strike me as an Apple type company that strategizes obsessively around a few products.
I am guessing that one of the reasons is that Apple because of their vertical integrated approach to almost everything they do have developed a much better even distributed push forward.
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.
> Despite how fast Tegra X1 is, and the fact that the SoC is seemingly always using its A57 cores, the interface can be quite janky at times. Normally things perform fine, but both Josh and I have observed random lag and frame drops when doing basic actions like scrolling, opening apps, and bringing down the notification drawer.
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.
Completely agree - I'm an Android fan, but it is unbelievable that the performance is still such an issue. Even the Nexus 6P drops frames quite regularly, and that's even with it doing much simpler animations than is common on iOS.
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.
I love Android but I really agree with this statement regarding responsiveness. Unfortunately I see this the most when using the Android Camera app. It just randomly lags now, causing me to miss special moments. I have no idea what is going on. I've searched all the corners of the internet and there's no good way to troubleshoot this.
Yes, my Lumia 630 is faster than most Android devices priced around 200€ and below.
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.
That's the short answer, but to elaborate, it probably has more to do with the culture surrounding the language than the overhead of the JVM, although that also plays a role. What I mean by "culture" is the widespread notion (cargo-cult?) among Java programmers that adding more classes and abstraction is always better, almost like a "best practice", leading to "enterprise" monstrosities with deep inheritance hierarchies and ridiculous amounts of indirection to accomplish the simplest of tasks. The low consideration given to memory management in general (there's a GC, but that doesn't mean you should abandon all thought about memory allocation --- an analogy I like to use is how it's possible to get as good fuel economy with an automatic transmission as a manual, with the right technique) also contributes to the 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.
>The JVM itself has a certain amount of unavoidable overhead
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.
Didn't want to say it outright, but that's my theory too. Having a VM manage everything in a resource/power constrained environment is a crazy idea in the first place. Oracle's JVM is competitive because of heroic engineering, in spite of Java's design -- not because of it. And it still has tradeoffs, like insane memory usage. ART/Dalvik are operating under different constraints, which probably contributes significantly to Android's handicap.
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.
The Go authors had a pretty good article on what's wrong with Java's performance : pointers everywhere. Every last little thing that isn't a primitive type is a pointer. Everywhere, in every bit of code.
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.
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.
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.
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.
"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.
Even if you're right. The issue with coding to optimizations is that it's really, really brittle. You change the position of a variable and suddenly your application runs 10x slower.
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.
From their Google IO presentations and their atitude towards NDK users vs how other mobile tems deal with their devs, I would say Java runs strong within who calls the shots at the Android's team.
Even if some of the code looks like written by devs recovering from years of exposition to hungarian notation.
The NDK is not part of their priorities indeed (although to be fair it seems that things are slowly getting better with a team dedicated to integrating Clion).
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.
I would also used Java if Oracle hadn't dropped the ball in mobile support, as if they couldn't provide JIT and AOT compilers.
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.
I am curious : on what kind of mobile apps are you working on your free time ?
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.
Also different mindset in terms of UX. These are web spirited devices. Material design was like a CSS3.5 demo. Android 4.4 was still lean in terms of usage[1], Material is eye candy but has zero value on in-the-street interactions.
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'.
Tablets are hard.
The SOCs are not that much better than the ones used for phones (when they are not just the same) but they have way more pixels to carry around.
>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.
Most of this review is basically correct -- it's a device with a good screen and good battery life, it'll be a terrible laptop replacement because Android isn't well-suited for that -- but the stuff about poor touch sensitivity, crashing, and performance issues is weird.
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 seems not uncommon on Android. My Nexus 7 has awful touch screen issues that only happen when I have certain updates installed. IIRC in that case they had different touch screen vendors with varying drivers
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?
> what kind of software issue affects a subset of devices?
Could be timing issues at the device driver level. Chips can have a range of timings that will work, but anything out of spec will work on some chips but not others.
Capacitive touch screens are very analog devices that are very sensitive to manufacturing changes, temperature, etc, so interpreting and reading the touches is quite complex and is a large factor in how well the touch screen works.
That said, it's a solvable problem - really, the first iPhone in 2007 solved it. This shouldn't be an issue in 2016 anymore.
I have a Pixel C and haven't run into any of those issues so far (trigger for buying it was The Room 3 not working well on my old tablet). Have mainly used Chrome, BS Player and The Room 3 for several hours and did not encounter any issues.
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.
It has []|\{} keys. You just have to use the modifyer key right of the space bar. I'm used to changing keyboard layout between languages and platforms, so my muscle memory got used to that quite quickly.
I have CMD+arrow keys for that, and those key combinations are often easier to reach that home/end/pgdn/pgup on many keyboards.
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.
Well, these are just Fn + Arrow keys. The end/home thing can get a little annoying when programming, but you quickly work your way arround it, and it surely isn't a problem in vim.
Do programmers actually use those keys? I use Home and End in the web browser... but when coding, I just use the close-to-my-fingers shortcuts. Home = C-<, End = C->, Delete = C-d, Page Up = C-v, Page Down = M-v.
Speaking as a developer who uses a macbook, I kinda agree. Overall, keyboard support on OSX is way inferior to Windows (and, presumably, Linux - it's been a while). Not only do you have to learn really awkward combos for pagedown, end, etc. but each app interprets them slightly differently (or not at all), so it's not even worth the effort. If it weren't for the unixy innards, I would probably move away.
Well I actually run Linux now on my MBP but to demystify, I don't use any of those keys because I only work in vi. You can do those things without the buttons when not in insert mode:
page up/down: ctrl f/b
home/end: 0/$
delete: x
Although that's somewhat of a simplification for delete.
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.
That's my main gripe about that keyboard - no ESC key.
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.
ESC is just the ... button, at your right thumb, and 1 at your left ring finger. It's quite comfortable to type, though, if using vim a lot, you will probably remap it to space.
When I was using an android tablet, I used hacker keyboard for my terminal sessions, because it can be set up to give a pretty full keyboard, including function keys.
So how do you like Termux? I'm trying to find a good terminal for android. I live in the terminal on my laptop and would love to just get rid of it, and move to a tablet. All the terminal's I've tried are really janky though.
All the other terminals I've tried seemed lagging or incomplete. Like they only supported certain programs or ran in a box rather than on the file system.
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)
I would suggest either changing the link to the beginning of the review[0] or updating the title to something like 'The Google Pixel C Software Review'.
So. Google has all the best engineers there is, unlimited supply of money, Android is as old as iOS (in software terms a grandpa) and Head of UX that makes fun of iOS on every occasion he gets. And still. What gives?
Anandtech complains about most of the same things (multitasking ui, large app scaling, blah blah blah blah blah) for their ipad pro and IOS reviews, so i'm not sure what gives either.
iOS has gotten worse over the past few years. I love it that they demand as much perfection as I do. Companies will focus resources where they hear the most noise.
No supply of money is unlimited, and throwing more people at a problem doesn't necessarily solve it.
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.
>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.
It just shows this wasn't supposed to ship with Android on board. Also Google has a bit of a problem regarding Android on tablets and ChromeOS, because I'm not positive they're actually sure where the future is here.
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 ?
If you don't want to read the whole review, this paragraph is a fine summary:
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.
It's really sad, that there is no serious competitor for Windows and OSX on desktop ATM. Linux is still somewhere between X11 and Waylaynd/Mir with it's GUI toolkits support and lacks commercial offering. Android is just not desktop OS and ChromeOS is not a full desktop.
Microsoft's new CEO is much smarter than these.They are shifting their product to be IT company rather than a pure software company.
They will put endless money on bing. They did put Bing in the core of their best product -Windows 10-.
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.
What networking technology does Chrome OS need? It's entirely possible to write great offline apps for it, they are just built using web technologies so you can use the same code online and offline.
Apps are useless if they can't reach their data, because it didn't fit in (tiny) local storage anymore and external storage is unavailable due to lack of (reliable, fast) network connectivity. Although manufacturers could simply offer devices with local storage and solve that.
Well, they probably wont switch and I didn't say that this will happen. I also don't care if company X or Z wins or loses.
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.
I had the same kinds of problems with my chromebook. It would freeze up, mouse pointer and all. Sometimes it would come back after a couple of minutes, other times it wouldn't. Sometimes the whole OS would die and it would reboot.
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.
Interesting. I recently got a chromebook (and not one of the nicer ones) and haven't seen any of this kind of behavior. It's actually been one of the best "just works" items I've bought in a while. I set up crouton so that I could use it for more than a browser, and the only piece of software that's caused any issues is WINE (though I haven't been too adventurous with the kinds of things I install on there).
Meanwhile, I've been using an Sony Xperia Z tablet for a couple of years. It's starting to get old, but Sony have updated it to Lollipop which I think is fair enough.
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 :)
I have the Xperia Z2. I really tried to use it as a laptop replacement. I'm a linux guy, all my work is in the terminal or a webpage, so I thought it would be easy.
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.
Oh wow, they shipped a bad touch screen again? The Nexus 7 2013 had basically the same problem. They fixed it later with firmware updates that basically added a lot of filtering, so single finger touches work basically fine now but multi-touch is still hit and miss (it's too poor to play Love Live for example, but maybe that's a net win, heh).
It's things like this that have pushed me away from the iOS/Android tablet ecosystem and towards an x86 non-rt windows tablet. Having a bigger screen than a phone shouldn't mean having to sacrifice useful development apps, good third party device support, and a liberal programming environment that tries to stuff me in the sandbox.
Well it really depends on what you want the tablet for. As a device to just relax, browse the web and dick around, mobile OSes feel generally faster than full blown desktop ones.
There is an interesting point in this review...
Seems like industry has get good enough to make hardware
-Microsoft and the beautiful magnesium surface pro
-Apple and the aluminum design (the possible saphire
screen and the new aluminum alloy)
-Android several devices...
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.
Interestingly some of the things that have been fixed and make the os nice have been done by apple, ad filter, the future screen color shifting a.k.a. "fluxing".
I wonder why people persist in speculating about OS unification. Chrome OS is great on cheap laptop form factors where Android would suck.
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.
Did anyone see this quote from the review?
"It’s honestly shocking to see these issues on a device designed by Google running software designed by Google."
Gold!
Are there recent Google devices that ship with ChromeOS ? While I believe that Android makes more sense (since it also has a browser and can run classical apps) I wonder what the state of ChromeOS is.
I'm typing this from a Pixel 2015 LS. ChromeOS is great if you're not a dev, and it's still pretty good if you do dev work on it. The problem isn't really ChromeOS (you can replace ChromeOS with Arch or Ubuntu with a little work), but that (judging from the G+ community) a lot of Pixel 2s have been RMA'd for flash disk and audio issues. If you get a good Pixel 2, it's an amazing machine. You might have to RMA it once or thrice to find that machine though.
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.
Which currently does the web fine but doesn't work for native android I have an intel machine for that stuff but for web development the pi is pretty sweet I run rails and node just fine on it with postgresql.
Well unfortunately this requires that you don't make your laptop your main development machine. I prefer to have only one machine and that machine be my laptop, though I do understand wanting desktop.
Just use a Digital Ocean droplet or something; that's what I do, and it works well. I mean, not if you want graphical UIs, but if you're good with Vim and a command line...
I spend a lot of time in places where I have no data access. I need local development capabilities. ChromeOS can do that via crouton, but data access from USB is very slow.
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.
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.)