The Unctuous Rants of Leif Andersen

Your Fiduciary Source for Science, Technology, Rants, and Occasional Journalism

Archive for category Google

Blender GSoC Week 7 Status

Jul 11

Posted by Leif Andersen in Google, Linux/FLOSS, Programming, Technology | No Comments

Overall, I think this has been a good week.  I worked almost exclusively on the image comparison diff tester this week.  I wrote it in python, and it can actually work independent of blender (although it does assume that blender is on your system, and in your path, although that can be changed with the –blender-bin flag).  This means that the tests folder can be put in a zip, and placed in the same location as where the current regression tests (for blender 2.4x) are located on the website.
As I said last time, the general way to run the tests is by using python run.py.  You can use the -v flag to see the output of blender as it’s rendering it.  Also, it might be possible to avoid even having to download the images at all, by using the recently built –built-tests flag, which, instead of rendering tests, will render the images and store them in the known good folder.  (It uses the version of blender in your path).
Through the use of the –image flag, you can compare any blender image on your harddrive (currently assuming it’s in the right file structure), this allowed me to make other image comparison tests, that compared blend files built by pyunit based tests.  This (along with the hashcode operator I started putting together last week), means that most of the tools for building good unit tests (and regression tests in general), are almost build (I think).  Meaning that now the only missing piece of the puzzle is the one I was working on several weeks ago (without luck), which is:
  • A.  Getting the python API to work in background mode (which blender currently isn’t designed to do).
  • B.  Getting the python API to work properly in foreground mode (lots of stuff in bpy.wm crash.  (At least it did as of a week ago, do to low bandwidth caps here, I won’t’ merge until tomorrow evening (when I get home), so they may have been fixed by now)).
Although Andrea only looked at my code to determine good structure, etc.   I believe that most of the bugs have been removed.  (Although, this is python, and bad code doesn’t show up until someone tries to run it, and I haven’t made regression tests for my regression tests. ;) (at least not yet anyway, and it’s not on my radar in the near future)).
The comparator is also capable of producing animation tests.  However, this code is slightly buggier.  Also, by default, I’m not running the animation tests in the current regression suite, because it takes the running time up from 2:30, to over an hour.  I have a –animation flag, but it doesn’t work at the moment.  (Although the underlying code works, so it’s basically just a matter of plugging the code into the flag).
Finally, because the animation images make the overall file size ~240 MB (as apposed to 30 MB), they are not in the default build.  But rather, the user has two choices, they can either A:  Render Good ones, or B.  Use a hash code (and download images (or generate them) if something goes wrong).  The hash code also work in images.  However, the code for this is only half built.  The test case classes support it, but the surrounding structures don’t use it yet, this shouldn’t be more than an hours worth of work to implement it fully.
Finally, I didn’t do as much work as I would have liked in the HTML output.  Now, rather than using static CSS scripts from sphynx, I now build the CSS in the script itself.  (With the exception of images, I’m not sure how to do that as a python script…well, there is PIL, but I’d sooner put bamboo up my fingernails than make the needed images that way).  Although the output is starting to look like it’s from blender’s website.  (Although the table doesn’t quite fit).  Also, it will only generate images for single images (well, that, and animations, but it only does the first frame).  Eventually, the animations will be clickable, and you can view a separate HTML page for the entire animation, but that’s not built yet.  It shouldn’t be too hard to make, but I keep having to do one or the other thing, so the current implementation is old, and would probably cause the script to crash if used.

Overall, I think this has been a good week.  I worked almost exclusively on the image comparison diff tester this week.  I wrote it in python, and it can actually work independent of blender (although it does assume that blender is on your system, and in your path, although that can be changed with the –blender-bin flag).  This means that the tests folder can be put in a zip, and placed in the same location as where the current regression tests (for blender 2.4x) are located on the website.
As I said last time, the general way to run the tests is by using python run.py.  You can use the -v flag to see the output of blender as it’s rendering it.  Also, it might be possible to avoid even having to download the images at all, by using the recently built –built-tests flag, which, instead of rendering tests, will render the images and store them in the known good folder.  (It uses the version of blender in your path).
Through the use of the –image flag, you can compare any blender image on your harddrive (currently assuming it’s in the right file structure), this allowed me to make other image comparison tests, that compared blend files built by pyunit based tests.  This (along with the hashcode operator I started putting together last week), means that most of the tools for building good unit tests (and regression tests in general), are almost build (I think).  Meaning that now the only missing piece of the puzzle is the one I was working on several weeks ago (without luck), which is:A.  Getting the python API to work in background mode (which blender currently isn’t designed to do).B.  Getting the python API to work properly in foreground mode (lots of stuff in bpy.wm crash.  (At least it did as of a week ago, do to low bandwidth caps here, I won’t’ merge until tomorrow evening (when I get home), so they may have been fixed by now)).

Although Andrea only looked at my code to determine good structure, etc.   I believe that most of the bugs have been removed.  (Although, this is python, and bad code doesn’t show up until someone tries to run it, and I haven’t made regression tests for my regression tests. ;) (at least not yet anyway, and it’s not on my radar in the near future)).
The comparator is also capable of producing animation tests.  However, this code is slightly buggier.  Also, by default, I’m not running the animation tests in the current regression suite, because it takes the running time up from 2:30, to over an hour.  I have a –animation flag, but it doesn’t work at the moment.  (Although the underlying code works, so it’s basically just a matter of plugging the code into the flag).

Finally, because the animation images make the overall file size ~240 MB (as apposed to 30 MB), they are not in the default build.  But rather, the user has two choices, they can either A:  Render Good ones, or B.  Use a hash code (and download images (or generate them) if something goes wrong).  The hash code also work in images.  However, the code for this is only half built.  The test case classes support it, but the surrounding structures don’t use it yet, this shouldn’t be more than an hours worth of work to implement it fully.

Finally, I didn’t do as much work as I would have liked in the HTML output.  Now, rather than using static CSS scripts from sphynx, I now build the CSS in the script itself.  (With the exception of images, I’m not sure how to do that as a python script…well, there is PIL, but I’d sooner put bamboo up my fingernails than make the needed images that way).  Although the output is starting to look like it’s from blender’s website.  (Although the table doesn’t quite fit).  Also, it will only generate images for single images (well, that, and animations, but it only does the first frame).  Eventually, the animations will be clickable, and you can view a separate HTML page for the entire animation, but that’s not built yet.  It shouldn’t be too hard to make, but I keep having to do one or the other thing, so the current implementation is old, and would probably cause the script to crash if used.

Tags: , , ,

Blender GSoC Week 6 Status

Jul 11

Posted by Leif Andersen in Google, Linux/FLOSS, Programming, Technology | No Comments

I’ll try to make this short, as it’s late here.
Even though I got sick this week (it turned out to be just a cold/flu), and went out of town (and still am), I believe that this week has been one of the most productive weeks so far.
This week started off with me implementing some of the GUI features I worked with last week, which is to say I started making the image diff tests into an operator.  (Previously they had been baked into the tests directly).  They could be run from a Tests dropdown menu, although there was non feedback outside of the console, leading the user to believe blender had frozen while the tests were running.  Andrea pointed out that this was pointless, and that it should just be a script.  As such, I started implementing it in all in python 2.x.  The tests can be found in tests/render, and I put together a slight howto on how to run them: http://wiki.blender.org/index.php/User:LeifAndersen/GSoC2010/Howto
Render Tests
The current set of render tests requires PIL, and python 2.x. In order to run them, inside the blender source directory, look in: tests/render. There, you should find a collection of files. While the absolute path of those files doesn’t matter (aka, you could move the tests/render folder anywhere, and it would do just fine), those files must be kept in the same relationship to each other. If blender is already in your system path, just go into the folder, and run python run.py, and the script will take it’s course. If blender is not in your current path, open up run.py, and change the BLENDER_BIN variable to you blender binary, and than run python run.py. You can view the results in the console, otherwise you can see a list of all of the results, as well as diffs, by opening index.html in your web browser.
(my most recent commits have temporarily broken this as an operator, but I will soon fix that).  There is a webpage that is outputted which allows you to easily see the difference between the renders.  In addition, the algorithm for analyzing the images is much improved.
I also moved my tests.hashcode module into an operator (bpy.ops.tests.hashcode()), or Tests->Hashcode.  Although it still only gives feedback in the terminal, and only takes some things into account when making the hashcode.
As far as next week goes, I am going to spend a bit of time with the webpage.  It’s not quite flush with blender’s webpage, but it’s getting closer.  But more importantly, I can see a few more options that would allow the user to get more of the raw data behind the images (which I would assume would make it debug).  Most of this I believe can be written in HTML, but some javascript may be useful.  I also plan to get animations working with these tests, and possibly bringing this back in to work with the blender operator.  I also am going to try to get a lot more feedback this week, and hope to have the tool used soon after.  I will also spend a bit of time getting the hashcode operator to take more into account, as well as giving more feedback to the user.  (As in feedback that’s not only just console output).  I would also work on aggregating the data in the blend file for the user to test, but blender is already capable of that.  Finally, I plan on improving the integration of Ctest and CDash, but that seems trivial to do.

I’ll try to make this short, as it’s late here.
Even though I got sick this week (it turned out to be just a cold/flu), and went out of town (and still am), I believe that this week has been one of the most productive weeks so far.
This week started off with me implementing some of the GUI features I worked with last week, which is to say I started making the image diff tests into an operator.  (Previously they had been baked into the tests directly).  They could be run from a Tests dropdown menu, although there was non feedback outside of the console, leading the user to believe blender had frozen while the tests were running.  Andrea pointed out that this was pointless, and that it should just be a script.  As such, I started implementing it in all in python 2.x.  The tests can be found in tests/render, and I put together a slight howto on how to run them: http://wiki.blender.org/index.php/User:LeifAndersen/GSoC2010/Howto
Render TestsThe current set of render tests requires PIL, and python 2.x. In order to run them, inside the blender source directory, look in: tests/render. There, you should find a collection of files. While the absolute path of those files doesn’t matter (aka, you could move the tests/render folder anywhere, and it would do just fine), those files must be kept in the same relationship to each other. If blender is already in your system path, just go into the folder, and run python run.py, and the script will take it’s course. If blender is not in your current path, open up run.py, and change the BLENDER_BIN variable to you blender binary, and than run python run.py. You can view the results in the console, otherwise you can see a list of all of the results, as well as diffs, by opening index.html in your web browser.
(my most recent commits have temporarily broken this as an operator, but I will soon fix that).  There is a webpage that is outputted which allows you to easily see the difference between the renders.  In addition, the algorithm for analyzing the images is much improved.
I also moved my tests.hashcode module into an operator (bpy.ops.tests.hashcode()), or Tests->Hashcode.  Although it still only gives feedback in the terminal, and only takes some things into account when making the hashcode.
As far as next week goes, I am going to spend a bit of time with the webpage.  It’s not quite flush with blender’s webpage, but it’s getting closer.  But more importantly, I can see a few more options that would allow the user to get more of the raw data behind the images (which I would assume would make it debug).  Most of this I believe can be written in HTML, but some javascript may be useful.  I also plan to get animations working with these tests, and possibly bringing this back in to work with the blender operator.  I also am going to try to get a lot more feedback this week, and hope to have the tool used soon after.  I will also spend a bit of time getting the hashcode operator to take more into account, as well as giving more feedback to the user.  (As in feedback that’s not only just console output).  I would also work on aggregating the data in the blend file for the user to test, but blender is already capable of that.  Finally, I plan on improving the integration of Ctest and CDash, but that seems trivial to do.

Tags: , , ,

Blender GSoC Week 5 Status

Jul 11

Posted by Leif Andersen in Google, Linux/FLOSS, Programming, Technology | No Comments

This week has been one of my better weeks.  As usual, there were a few bumps this week, but not too many.
This week dealt with two things:
1.  Image comparison
2.  UI, and thus wrapping unit tests in operators to insert into the UI.
Per Matt Estela’s recommendation, I tried incorporating Perceptual Image Diff http://pdiff.sourceforge.net/ into the tests to compare images.  The pre-compiled binaries work fine, however, compiling from source presents a bit of a problem, even with all of the listed dependencies installed, it complains that several printf stamens are not declared.  I emailed the developer and am waiting for a response.  This isn’t my main priority.  However, I will keep using PIL until such time as a tool like this works.
Getting tests in blender’s UI represents some challenges that do not exist when using CTest as a testing platform.  First of all, I thought a lot about render tests.  If we use blender’s current set of regression tests that blender has, it shouldn’t be very difficult to create a tool that allows a developer to render a blend file, and than compare it to another image file, and than write another tool to run all of the tests.  The problem is that putting this into the GUI, which requires python 3.  And on top of that, developing a good UI for this sort of thing can also be a bit tricky.  Fortunately though, it still is trivial to wrap up unit tests inside an operator, so ultimately, running the tests won’t be too big of a deal, as apposed to setting them up.  I also toyed with writing the operators required in C, although this isn’t as good of an idea as writing it in python, where we could simply give developers a template file to use for their tests, but it may still prove useful.
Next week should be interesting.  Starting on Wed.  and going to the end of the week after that, I’ll be out of town.  With that being said, I won’t be out of communication, but rather, I’ll probably be spending less time on IRC.  (I’ll still try to attend the usual Sunday meeting, as well as spending an hour or so online though).  I will respond to emails as usual, albeit probably a bit slower.   I’ll post an email specifically about this to this list in case this portion of the review is missed.  I still have more UI stuff planned next week, but mainly merging the UI and rendering algorithms into one fluid tool, at which point I’ll start automating it.

This week has been one of my better weeks.  As usual, there were a few bumps this week, but not too many.
This week dealt with two things:1.  Image comparison2.  UI, and thus wrapping unit tests in operators to insert into the UI.
Per Matt Estela’s recommendation, I tried incorporating Perceptual Image Diff http://pdiff.sourceforge.net/ into the tests to compare images.  The pre-compiled binaries work fine, however, compiling from source presents a bit of a problem, even with all of the listed dependencies installed, it complains that several printf stamens are not declared.  I emailed the developer and am waiting for a response.  This isn’t my main priority.  However, I will keep using PIL until such time as a tool like this works.
Getting tests in blender’s UI represents some challenges that do not exist when using CTest as a testing platform.  First of all, I thought a lot about render tests.  If we use blender’s current set of regression tests that blender has, it shouldn’t be very difficult to create a tool that allows a developer to render a blend file, and than compare it to another image file, and than write another tool to run all of the tests.  The problem is that putting this into the GUI, which requires python 3.  And on top of that, developing a good UI for this sort of thing can also be a bit tricky.  Fortunately though, it still is trivial to wrap up unit tests inside an operator, so ultimately, running the tests won’t be too big of a deal, as apposed to setting them up.  I also toyed with writing the operators required in C, although this isn’t as good of an idea as writing it in python, where we could simply give developers a template file to use for their tests, but it may still prove useful.
Next week should be interesting.  Starting on Wed.  and going to the end of the week after that, I’ll be out of town.  With that being said, I won’t be out of communication, but rather, I’ll probably be spending less time on IRC.  (I’ll still try to attend the usual Sunday meeting, as well as spending an hour or so online though).  I will respond to emails as usual, albeit probably a bit slower.   I’ll post an email specifically about this to this list in case this portion of the review is missed.  I still have more UI stuff planned next week, but mainly merging the UI and rendering algorithms into one fluid tool, at which point I’ll start automating it.

Tags: , ,

Blender and Google Summer of Code (GSoC), Month One Review

Jun 21

Posted by Leif Andersen in Google, Linux/FLOSS, Programming, Technology | No Comments

It’s been almost a month since the official start date of Google Summer of Code, and, per Andrea’s recommendation, now is a good time for a month in review.  This won’t go into great detail, I will leave the weekly reviews for that.

So, just a brief checklist of what has happened:

  1. Project Started
  2. Gtest set up
  3. Pyunit setup
  4. tests module created
  5. Hashtests and image comparison tests built
  6. Learned a lot about how the Blender codebase works
  7. Made some hacks and bug reports with the Blender codebase
  8. Initial work on GUI panel for tests (originally dropped, but recently brought back into the foreground)
  9. CMake now using CTest and CDash to report the project

Read the rest of this entry »

Tags: , , ,

Blender GSoC Week 4 Status

Jun 18

Posted by Leif Andersen in Google, Linux/FLOSS, Programming, Technology | No Comments

Overall, I think this week I’ve started to pick up the pace, although not by too much, there’s still plenty of room for lot’s of improvement, but at this point everything is starting to feel like it goes into place, which makes me happy.

I spent a lot of time this week trying to get some of the tests to work in background mode. Unfortunately, several of the needed api calls (saving/loading/rendering/saving images), only work when in regular mode. I also had other problems with API calls not working properly even in the foreground mode, and I’ve done some more hacks on the codebase, and submitted some bug reports, although at this point, I’ve got most of the API calls I need working, albeit they’re still a bit buggy. In the end, we’ve decided to run the tests in the forground (for now), and just run the exit blender api call at the end of the test. The largest problem with this is that if the test segfaults, blender won’t quit, and the user must quit it himself. Also, it’s quite annoying to have a window pop up and close over and over again while running the tests. Thus, as soon as some of the bugs I’ve reported are fixed, I’ll be switching back to background mode.

I’ve also started doing some image comparison tests. I don’t really have any good algorithms yet, so I’m still very open to suggestions. Currently though, I’ve tried several iterations of a histogram comparison. Both comparing all the color bands at the same time, and comparing them separately, the first one is quite a bit faster, although I think that’s do to how I’m using the API calls.

Read the rest of this entry »

Tags: , , , ,

Open Source Alternatives to GMail

May 28

Posted by Leif Andersen in Google, Linux/FLOSS, Technology | No Comments

The following is a thread about my email woes I have posted to the ubuntu forums, I will update it with a solution if I find one, you can fie the thread here: http://ubuntuforums.org/showthread.php?p=9374207#post9374207

I’ve been thinking for the past few days, everyone’s been complaining about facebook, and my opinion has been: “it’s your fault for trusting some random company on the internet with all of your private information, don’t put information on the internet you don’t mind the rest of the world seeing”.

And then I got to thinking, what about Google, no one ever talks about that, and the amount of data we’re giving Google for email. I then think that it’s not a big problem, because you’re emailing people anyway, so it shouldn’t really matter, after all, they could always go publish your mail…so it’s just better to not say anything that could be incriminating over email as well. Also, I’m sending unencrypted messages, so it’s still technically wide open.

But then I start realizing that it’s still a bad thing. True, while no one at Google is reading my email (I think), who says that they will always be the ‘good guys’, which is to say, just like how everyone trusted facebook, and their motivations changed, nothing is preventing google from changing it’s opinions. And, even if Google keeps it’s slogan, and never does become ‘evil’, they could still get subpoenaed, etc. etc. In short, I’m saying I shouldn’t trust this thing with the cloud.

So, this lead me to think, what is there out there besides GMail? Sure, there is clients like evolution or thunderbird, but they fail short. In particular, they don’t really have threaded conversations. Most of the other things I need (tags, filters, multiple email addresses), either come built in, or a solution can easily be hacked, but I haven’t found any way to thread emails, and with the way I use email, I really need conversation threading. Also, it would be nice if I could hide quotes by default…but I think there’s a solution to do that.

Does anyone know of a good alternative to gmail that will thread conversations. Preferably an open source solution. I know outlook will do it for you.

Thank You.

Update:

Okay, I just found out that evolution does have message threading, but rather than being in the preferences panel, it’s located in the View drop down menu.  Apparently Thunderbird does the same thing.
I also tried out Zimbra, and other than that it appears to be based very heavily on java, it does look like it would also do the job, in addition, it’s also really easy to configure (unlike evolution which requires you to know how email works to configure it, Zimbra’s desktop client will let you simply put in you’re credentials to any webmail based service, or to your own server, and it will set the rest up for you.  Although, it automatically downloads your mail, which could get annoying.

Okay, I just found out that evolution does have message threading, but rather than being in the preferences panel, it’s located in the View drop down menu.  Apparently Thunderbird does the same thing.
I also tried out Zimbra, and other than that it appears to be based very heavily on java, it does look like it would also do the job, in addition, it’s also really easy to configure (unlike evolution which requires you to know how email works to configure it, Zimbra’s desktop client will let you simply put in you’re credentials to any webmail based service, or to your own server, and it will set the rest up for you.  Although, it automatically downloads your mail, which could get annoying.

Tags:

Going for Gold: Google Rolls out 1 Gb Fiber Optic Network

Feb 12

Posted by Leif Andersen in Google, Technology | No Comments

Today, Google announced that they are working to roll out a 1 Gb fiber network to select areas, with the hopes of making it a ubiquitous connection.  They claim, the idea is so that next generation apps can be made, without having to worry about bandwidth concerns.   Despite my initial misgivings about running all of our apps in an extremely fast cloud, this seems incredibly cool.

Usually, this is the point where I get up on my soapbox, and complain about how much control Google is having, even though I love it.  This time, I must state how happy I am.  Despite the fact that Google will now have complete control, and can soon be part of every aspect of the internet, this really is a benefit.  First of all, this will provide competition.  The main reason why I support the FCC’s lock down of the internet, is due to a lack of competition between ISPs.  On the other hand, if Google is able to roll out world wide fiber, despite the  brevity of that statement, all ISPs would have a large competitor, meaning that current ethical issues with ISPs would be lowered.  Not to mention the speed.  If this is a success, not only will Google have yet another market share, but they will have one of the fastest connections in the continental USA, and possible the world.

On the other hand, as mentioned earlier, Google is getting quite big.  They now have a hand in everything from your hardware, to your software, to your web searching, to even a large chunk of your content.  If Google pulls this off, they will have a hand in every single level of accessing the internet.  And because they’re currently not a telecommunications company, they could abandon the ideas of net neutrality, and speed up their websites, however, to be fair, with the current leadership of Google, I think they would rather speed up their websites by making them better, not by slowing everyone else down.  To be honest, I think that may be a little much for one company to have, even if it is a company that I love, and would like to work for in the future.

What do you think?

You can read more about this at GoogleBlog.

Google Buzz, and the Invite Craze

Feb 10

Posted by Leif Andersen in Google, Reviews, Technology | 2 Comments

Today, Google unveiled their latest product Google Buzz.  Supposedly, it will be Google’s new way of communicating, not to be confused with Google Wave, which is, well, if you know, please tell us, because the rest of the internet is trying to figure it out.  Currently, if you go to the Google Buzz webpage, you get a nice Google logo, with Google style cartoons, saying all of the great things you can do with Google Buzz, and a video talking about just how great it is.  It also contains a button that says “Try Buzz in Gmail”.  When you click on it, you get taken to your Gmail inbox.  Once their, I noticed that it looked exactly like the old Gmail inbox, that is to say, there was no Buzz.  after a little confusion, I went back to the original website, and noticed a bit of text at the top that said:

We’re still rolling out Buzz to everyone, so if you don’t see it in your Gmail account yet, check back soon.

Meaning that Google has not decided that I’m not worthy enough to actually see Google Buzz on the day that they announced it.  That’s somewhat typical.  I’m just a standard internet user, new to blogging, programming, and engineering, as such, why should pick me, other than that the remainder of the website says that it’s out and ready to use.

Having a private beta is not just how Google works, most companies will do that.  However, Google is notoriously public who they invite, or how to get into this beta, namely, to ask for an invitation.  However, Buzz is working differently.  Google has decided to an approach similar to Twitter.  That is, role it out quietly.  Make it part of some people’s accounts, and eventually to everyone.  In some ways, this is good, it means that you don’t need to create a new account, or fill out some form asking for an invite, etc.  Also, the massive rush for Google Wave invites has been qualmed as well, as the invite isn’t even being used..

All in all, this doesn’t seem like the biggest thing Google had done.  Their video seems incredibly similar to Gmail already.  That is to say, it will likely be the best social network platform on the planet, but everyone will still continue to use Facebook.  Also, it will be somewhat difficult to tell whether I am getting an email from a mailing list, or just another buzz post, with the exception that buzz posts won’t have a little number on them that says unread.  Thus, I must say that this product doesn’t seem very useful.  Now, if they integrated Google Reader, and GMail, and Twitter, and possibly Google Voice, and every other social networking platform into one place, then we would have something.  However, there still isn’t much new going on.

With that being said, I may be grouchy because I didn’t get an invite, like Mike Arrington hates the Pre.

Update: It looks like I’ve been ‘invited’.  I must say, I like the idea much more than Facebook or twitter.  The UI is fast and sleek, I also love how it integrates into Gmail.  My current gripes are the lack of options.  Currently, you are forced to sort by posts with the latest comments, however, this simply means that the top posts in buzz are just popular ones, unless you only follow close friends.  Also, while I like seeing replies to threads I’ve commented on in Gmail by default, that should be an option that can be turned off by request.

Tags: , ,

Nexus One Announcement

Jan 5

Posted by Leif Andersen in Google, Technology | 1 Comment

Today is the big day, where the Nexus One by Google is released.  I previously wrote a post on the price leak being a fake, and I was, in part right, while the price itself was correct, the T-Mobile lock in was not accurate.  Rather, when you go to the website, and go to the checkout page, you get to choose what provider you would like to buy it with, or if you would like to buy it without any provider.  At the time of this release, you can only buy it unlocked or with T-Mobile, however, as you can see from this screenshot, they have plans for other networks.  However, if you click on the Verizon button, it takes you to the droid website.

It also appears that the Terms of Sale Policy is the same as the leaked one.  This clarifies quite a bit.  I was complaining about a few discrepancies in the policy, however, when we take into account that there are going to be multiple providers, each with a different price point, the Terms of Sale becomes logical.

This is a good thing.  Unlike the iPhone, which is currently only provided on one network, you can get the Nexus One to work on any network, CDMA or GSM, however, it appears that currently, only the GSM model is available.  This will promote competition among providers, and a network will no longer be able to rely upon having the exclusive on the best smartphone.

The hardware and software on the phone is nothing special, or rather, the presentation did not reveal anything out of the ordinary with the phone.  And many articles on Engadget provide a good idea of what the phone provides.

The only thing that I am worried about is Google’s reputation.  They have a reputation of just dropping products.  To be fair, this usually only happens to products that are in beta, and they do not claim this is in beta.  However, other than selling a few server based products to enterprise customers, they have little expertise in selling hardware.  They are used to being able to release early, and release often.  For phones, this doesn’t quite work.  Unless you buy the incredibly expensive unlocked option, you are stuck with the phone for two years, and Google can’t just make a slight hardware change to their phone, as they are used to being able to do with their other products.  I am not very worried about Google doping support for the phone in the near future, however when it happens, I also fear that Google won’t do a very good job announcing it.

All in all, I am still very excited for the phone, and now I’m debating about buying this one in a few months.  I still think that there is a few things that they could fix, and I would also prefer a tablet to a phone, but I still am excited for this, and the general direction that Android is going in.

Tags: , , , ,

Nexus One, Price Leak, or Scam?

Dec 30

Posted by Leif Andersen in Google, Technology | 1 Comment

Well, it’s out, or at least the majority of the web thinks it is.  Sites such as TechCrunch, and Engadget, both have articles on the leaked phones price point.  Furthermore, this PDF is supposedly the Terms of Sale that Google creates when you are buying your phone (please comment if this link dies, I have another copy I can link too).  Now, the entire internet is up in arms, some saying how Google is turning into another Apple, others disappointed, hoping that Google would save us from the current state of cell phones, and a few that say that this is no big deal.  I would like to state that all of this is unnecessary.  Why?  These leaked information given is fakes. Read the rest of this entry »

Tags: , , ,