Looking at the website, here is some of the included software (pulled directly from the website):
Metrics Kit
Metrics API — Lightweight API for recording user metrics from apps and system services.
Event Recorder Daemon — Saves recorded user metrics and transmits them in small batches when there’s an internet connection.
Metrics Instrumentation Daemon — Records information about the system, such as performance info.
Phone Home — Anonymous user counter.
A Linux distro that phones home. Well, now I think I've seen it all!
I work for Endless and work/worked on some of these metric subsystems and this is pretty much FUD. The metrics (excluding phone home) can be turned off from the installation screens. Phone home sends a single ping to us per day that's not user identifiable and the only thing we keep there is the country, make, model, and a few other things (you can see all of them here: https://github.com/endlessm/eo...) to know what devices are out there that we should try to support and to see our OS adoption trends.
I've met and talked to Jon McCann about GNOME3 and he's got a pretty good head on his shoulders about usability and if the rest of their crew is similar, the project is for sure moving forward. Sure, the icons won't be in the same place nor will your resource meter stay docked in a taskbar but you trade that change off with a cleaner design, more screen real-estate, and pretty snazzy but subtle effects. Once you have the presentation layer in JS with the help of debugging tools like lg (similar to Firebug) you can rapidly modify/develop/iterate over new UI designs without much time spent handling memory allocations, de-referencing null pointers, nor adding metric tons of boilerplate code. Not to disagree with other knee-jerk reaction commenters, JS can be used for evil but when used carefully it can be a very powerful RAD tool.
Increased speed of hashing is usually a bad thing since passwords stored many times use a one-way hash function. With a faster hashing speed those passwords will be faster to crack. Personally, I'd opt for the highest-enthropy, slowest-speed, and lowest collision ration hashing function.
For Android, install Debian Linux in parallel using LinuxInstaller (not on the market but I'm sure you can track it down using google) and run whatever the heck you want on it.
PS: I'm working on reimplementing the functionality of that app at https://github.com/sgnn7/Android2Linux which can help you figure out how to do it manually if you can't find it.
Slashdot Mirror
Looking at the website, here is some of the included software (pulled directly from the website):
Metrics Kit Metrics API — Lightweight API for recording user metrics from apps and system services.
Event Recorder Daemon — Saves recorded user metrics and transmits them in small batches when there’s an internet connection.
Metrics Instrumentation Daemon — Records information about the system, such as performance info.
Phone Home — Anonymous user counter.
A Linux distro that phones home. Well, now I think I've seen it all!
I work for Endless and work/worked on some of these metric subsystems and this is pretty much FUD. The metrics (excluding phone home) can be turned off from the installation screens. Phone home sends a single ping to us per day that's not user identifiable and the only thing we keep there is the country, make, model, and a few other things (you can see all of them here: https://github.com/endlessm/eo...) to know what devices are out there that we should try to support and to see our OS adoption trends.
As hinted by the interview (and from some other sources), next model is in the works with better specs than Model A/B.
I've met and talked to Jon McCann about GNOME3 and he's got a pretty good head on his shoulders about usability and if the rest of their crew is similar, the project is for sure moving forward. Sure, the icons won't be in the same place nor will your resource meter stay docked in a taskbar but you trade that change off with a cleaner design, more screen real-estate, and pretty snazzy but subtle effects. Once you have the presentation layer in JS with the help of debugging tools like lg (similar to Firebug) you can rapidly modify/develop/iterate over new UI designs without much time spent handling memory allocations, de-referencing null pointers, nor adding metric tons of boilerplate code. Not to disagree with other knee-jerk reaction commenters, JS can be used for evil but when used carefully it can be a very powerful RAD tool.
Increased speed of hashing is usually a bad thing since passwords stored many times use a one-way hash function. With a faster hashing speed those passwords will be faster to crack. Personally, I'd opt for the highest-enthropy, slowest-speed, and lowest collision ration hashing function.
For Android, install Debian Linux in parallel using LinuxInstaller (not on the market but I'm sure you can track it down using google) and run whatever the heck you want on it.
PS: I'm working on reimplementing the functionality of that app at https://github.com/sgnn7/Android2Linux which can help you figure out how to do it manually if you can't find it.
I would venture to guess that he will do fine