Showing posts with label Google. Show all posts
Showing posts with label Google. Show all posts
Wednesday, May 22, 2013
Monday, April 8, 2013
article on "Google Chrome OS" - Wikipedia, the free encyclopedia
Google Chrome OS - Wikipedia, the free encyclopedia
It also includes a reference to an article named "poking around …", which basically explains, how to get a bash session on Chrome OS.
It also includes a reference to an article named "poking around …", which basically explains, how to get a bash session on Chrome OS.
Wednesday, March 27, 2013
The demise of Google Reader: Stability as a service
The demise of Google Reader: Stability as a service:
Om Malik’s brief post on the demise of Google Reader raises a good point: If we can’t trust Google to keep successful applications around, why should we bother trying to use their new applications, such as Google Keep?
Given the timing, the name is ironic. I’d definitely like an application similar to Evernote, but with search that actually worked well; I trust Google on search. But why should I use Keep if the chances are that Google is going to drop it a year or two from now?
In the larger scheme of things, Keep is small potatoes. Google is injuring themselves in ways that are potentially much more serious than the success or failure of one app. Google is working on the most ambitious re-envisioning of computing since the beginning of the PC era: moving absolutely everything to the cloud. Minimal local storage; local disk drives, whether solid state or rust-based, are the problem, not the solution. Projects like Google Fiber show that they’re interested in seeing that people have enough bandwidth so that they can get at their cloud storage fast enough so that they don’t notice that it isn’t local.
It’s a breath-taking vision, on many levels: I should be able to have access to all of my work, regardless of the device I’m using or where it’s located. A mobile phone shouldn’t be any different from a desktop. I may not want to write software on a mobile phone (I can’t imagine coding on those tiny touch keyboards), but I should be able to if I want to. And I should definitely be able to take a laptop into the hills and work transparently over a 4G network.
Furthermore, why should I worry about local storage? The most common cause for throwing a computer on the bone pile is disk drive failure. Granted, I keep machines around for a long time, so by the time the disk drive fails, it’s more than time for an upgrade. But local disks require backups; backups are a pain; and it’s all too common for something to go wrong when you’re doing a restore. I’d prefer to leave backups to a professional in a data center. For that matter, there are many things I’d rather leave to a data center ops group: malware detection, authentication, software updates, you name it. Most of the things that make computing a pain disappear when you move them to the cloud.
So I’ve written two paragraphs about what’s wonderful about Google’s vision. Here’s what sucks. How can I contemplate moving everything to the cloud, especially Google’s cloud, if services are going to flicker in and out of existence at the whim of Google’s management? That’s a non-starter. Google has scrapped services in the past, and though I’ve been sympathetic with the people who complained about the cancellation, they’ve been services that haven’t reached critical mass. You can’t say that about Google Reader. And if they’re willing to scrap Google Reader, why not Google Docs? I bet more people use Reader than Docs. What if they kill the Prediction API, and you rely on that? There are alternatives to Reader, there may be alternatives to Docs (though most of the ones I knew have died on the vine), but I don’t know of anything remotely like the Prediction API. I could go on with “what ifs” forever (Authentication API? Web Optimizer?), but you get the point.
If Google is serious about providing a platform that lets us move all of our computing to the cloud, they need to provide a stable platform. So far, the tools are great, but Google gets a #fail for stability. Google understands the Internet far better than its competitors, but they’re demonstrating that they don’t understand their users’ needs.
Om Malik’s brief post on the demise of Google Reader raises a good point: If we can’t trust Google to keep successful applications around, why should we bother trying to use their new applications, such as Google Keep?
Given the timing, the name is ironic. I’d definitely like an application similar to Evernote, but with search that actually worked well; I trust Google on search. But why should I use Keep if the chances are that Google is going to drop it a year or two from now?
In the larger scheme of things, Keep is small potatoes. Google is injuring themselves in ways that are potentially much more serious than the success or failure of one app. Google is working on the most ambitious re-envisioning of computing since the beginning of the PC era: moving absolutely everything to the cloud. Minimal local storage; local disk drives, whether solid state or rust-based, are the problem, not the solution. Projects like Google Fiber show that they’re interested in seeing that people have enough bandwidth so that they can get at their cloud storage fast enough so that they don’t notice that it isn’t local.
It’s a breath-taking vision, on many levels: I should be able to have access to all of my work, regardless of the device I’m using or where it’s located. A mobile phone shouldn’t be any different from a desktop. I may not want to write software on a mobile phone (I can’t imagine coding on those tiny touch keyboards), but I should be able to if I want to. And I should definitely be able to take a laptop into the hills and work transparently over a 4G network.
Furthermore, why should I worry about local storage? The most common cause for throwing a computer on the bone pile is disk drive failure. Granted, I keep machines around for a long time, so by the time the disk drive fails, it’s more than time for an upgrade. But local disks require backups; backups are a pain; and it’s all too common for something to go wrong when you’re doing a restore. I’d prefer to leave backups to a professional in a data center. For that matter, there are many things I’d rather leave to a data center ops group: malware detection, authentication, software updates, you name it. Most of the things that make computing a pain disappear when you move them to the cloud.
So I’ve written two paragraphs about what’s wonderful about Google’s vision. Here’s what sucks. How can I contemplate moving everything to the cloud, especially Google’s cloud, if services are going to flicker in and out of existence at the whim of Google’s management? That’s a non-starter. Google has scrapped services in the past, and though I’ve been sympathetic with the people who complained about the cancellation, they’ve been services that haven’t reached critical mass. You can’t say that about Google Reader. And if they’re willing to scrap Google Reader, why not Google Docs? I bet more people use Reader than Docs. What if they kill the Prediction API, and you rely on that? There are alternatives to Reader, there may be alternatives to Docs (though most of the ones I knew have died on the vine), but I don’t know of anything remotely like the Prediction API. I could go on with “what ifs” forever (Authentication API? Web Optimizer?), but you get the point.
If Google is serious about providing a platform that lets us move all of our computing to the cloud, they need to provide a stable platform. So far, the tools are great, but Google gets a #fail for stability. Google understands the Internet far better than its competitors, but they’re demonstrating that they don’t understand their users’ needs.
Monday, July 30, 2012
Google Script: Enterprise Application Essentials
Google Script: Enterprise Application Essentials: 
How can you extend Google Apps to fit your organization’s needs? This concise guide shows you how to use Google Scripts, the JavaScript-based language that provides a complete web-based development platform—with no downloads, configuration, or compiling required. You’ll learn how to add functionality to Gmail, spreadsheets, and other Google services, or build data-driven apps that run from a spreadsheet, in a browser window, or within a Google Site.
How can you extend Google Apps to fit your organization’s needs? This concise guide shows you how to use Google Scripts, the JavaScript-based language that provides a complete web-based development platform—with no downloads, configuration, or compiling required. You’ll learn how to add functionality to Gmail, spreadsheets, and other Google services, or build data-driven apps that run from a spreadsheet, in a browser window, or within a Google Site.
Tuesday, October 4, 2011
Saturday, September 17, 2011
Oracle's draft for the JCP clears an important hurdle - The H Open Source: News and Features
Oracle's draft for the JCP clears an important hurdle - The H Open Source: News and Features: With JSR 348, the developers introduced a draft to redesign the Java Community Process. Having gone through Public Review, the specification has now cleared an important implementation hurdle [--] only Google remains sceptical
Google buys another thousand IBM patents - The H Open Source: News and Features
Google buys another thousand IBM patents - The H Open Source: News and Features: Google expands its patent armoury again, purchasing another thousand patents from IBM covering mobile, search, enterprise Java and scripting
Google to provide location service opt-out for Wi-Fi owners - The H Security: News and Features
Google to provide location service opt-out for Wi-Fi owners - The H Security: News and Features: In response to criticism from several European data protection authorities, Google is to provide owners of Wi-Fi systems an opt-out that will prevent their system's information being used for location-based services
Wednesday, September 14, 2011
Wednesday, September 7, 2011
Tuesday, September 6, 2011
Thursday, September 1, 2011
Gone again: James Gosling leaves Google - The H Open Source: News and Features
Gone again: James Gosling leaves Google - The H Open Source: News and Features: After less than six months, the inventor of the Java programming language turns his back on Google to join Californian start-up Liquid Robotics ...
He is also devoloped the Gosling Emacs quite a couple of years ago.
He is also devoloped the Gosling Emacs quite a couple of years ago.
Tuesday, August 16, 2011
Google attacks Lodsys patents - The H Open Source: News and Features
Google attacks Lodsys patents - The H Open Source: News and Features: "Google has applied to the US Patent Office for the re-examination of two patents owned by Lodsys. The company is currently taking action against several developers of mobile applications for patent infringement"
Tuesday, August 9, 2011
Saturday, August 6, 2011
Subscribe to:
Posts (Atom)
