The Blog of Tom Webster

Chronic Ranter, Reviewer, and Developer. I speak only for myself, opinions are my own.

Bing: Powered by Google - Stolen Search Results

  2011-02-01 08:42:00 PST

Breaking tech news today! It has been uncovered that Bing has been poaching Google search results! Here are the cliff notes:

So what exactly does this mean for Bing? Microsoft is holding a search event later today (which is why Google could be unveiling this now), and Matt Cutts is on a panel with them later today, so I expect we will hear more then.

The original tweet is here: http://twitter.com/mattcutts/status/32459370511994880

Check out the very thorough and awesome analysis of the situation by Search Engine Land.

I think search is going to get very interesting over the next couple of weeks...

Cloudbound: Java?

  2011-01-17 13:16:00 PST

One of the problems I've run into with Chrome OS is the apparently lack of Java. It kind of perplexes me that I hadn't considered Java to be a core web technology before my addiction to Minecraft reached epic proportions, but it also perplexes me that Google didn't consider it a core web technology either. When I try to load up this Java applet on my CR48, I get this error message instead:

Missing Plug-in. Java does require local system support for applets to load, and it would make sense for Google to want as few attack vectors as possible for Chrome OS, but it still is a bit annoying. Not that my CR48 would have the power to run Minecraft, anyway. The system only has a 1.6Ghz Atom processor, I'm pretty sure it wouldn't run very well if it did. I could edit the root file system in DEV mode and install Java, but I'd like to keep this system as clean as possible. Just an interesting notion, nothing more.

Server-Bits #10: Subversion

  2011-01-17 08:42:00 PST

Subversion! One of the best ways to keep track of versions for code, homework, various essays, you name it. If it changes and you want the ability to roll back changes, Subversion is for you. In reality, Subversion is one of many types of versioning software out there, but its the one we are going to cover in this tutorial. If you're really interested in the alternatives, Google around for: Git, Mercurial, among many other smaller projects.

Why would anyone want to set up a software repository? Easy answer if you're a programmer of any sort. I'm a hobbyist programmer, and I constantly break my own code and projects when trying new things. I wanted an easy way to roll back any changes that I had made, while still retaining a history of some sort. I initially did this by copying different versions of the code into different folders, but this proved to be unmanageable in the long run. At the time, I was using 6 different computers to write my code, depending on which location I was in during that day. Manually copying this folder to a USB stick, then re-syncing the changes became a major hassle. Subversion allows you to create a repository in a folder and commit changes to it. Want to update a particular machine with the latest version of the code? Easy, subversion has an update feature that only pulls down the changes of the file since you last synced. Easy stuff, and I'll show you how to build your own subversion repository.

The very first thing you need to do is install subversion.

sudo apt-get install subversion

Yea, that easy.

Second thing, choose a place where your code will live. This shouldn't be your working directory at all, as you don't really directly interact with the subversion repository. I've made a directory inside my home directory called "SVN", and that's where all my projects live. The project I'm working on is called "Hax", so I'll create the Hax repository.

svnadmin create hax

Now I have a directory called 'hax' on my system. If you browse to that directory and look around, it appears a little strange. That's because subversion creates a database system of sorts to manage, store, and compress your code. Again, you will not be interacting directly with this folder. You will write code elsewhere and commit (upload) the code to the repository.

Next, you need a username and password to be able to checkout (download) and commit code. Navigate to your repository/conf. So, in my example, I'd navigate to hax/conf/. Use a text editor to edit the passwd file. The default file should show you how to enter users. I'll go ahead and create my username and password:

tom = password

NOTE: Since this file contains all of the usernames and passwords to access your repository, make sure only you have access. You don't want people commiting code as you. Now, I have a user, tom, and his password is password.

The next file you have to edit is: repository/conf/svnserve.conf Scroll down until you reach the part of the file that lists:

#anon-access = read
#auth-access = write

You want to change this to say:

anon-acces = none
auth-access = write

One last line to change, find the line:

#passwoord-db = password

And change it to:

password-db = password

The first changes you made told subversion that no one should have anonymous access to your code, and authenticated users should have write access to the repository. The second change you made is to let subversion know that we will indeed be using that password file to store users and passwords.

Now you have successfully configured your subversion repository. The next thing we need to do is get your server publishing your repository so you can access it from anywhere. The command for this is svnserve. You can use man svnserve to see all of the options. The easiest way to get your SVN server up and running is:

svnserve -d -r /home/username/path-to-repo

The -d option sets svnserve into Daemon mode, so it will accept TCP connections automatically. The -r option sets the path you gave as the root of the SVN server.

If you want, you can make one directory to house all of your projects. This way, you can commit code to server.com/project1 and server.com/project2, all by running one instance of svnserve. Experiment to figure out which works best for you. For myself, I have one directory act as the root for svnserve, then all of my projects are then organized by category.

Now... This is how you use subversion to checkout and commit code:

To checkout your code:

svn co svn://hostname.server.com/project1

To add things to be committed:

svn add filename.txt

To delete a file (and delete it from the commit):

svn rm filename.txt

To commit your code to the repository:

svn commit -m "Comment your changes!!"

Now, a few lessons you need to take away from this:

  1. You must manually add files to be committed. Just committing code won't do anything unless you tell subversion that a file must be included in the commit. You only have to do this once per new file, after that, subversion remembers that this file is to be included in the commit.
  2. Likewise, if you would like to remove a file and have the repository reflect those changes, you must tell subversion that you are removing the file. Just deleting the file will leave it intact in the repository.
  3. When you use the commit function, please use the -m flag. This will allow you to comment your changes, this is important because if you ever want to roll back to a previous version, you can look through the svn log and see exactly when you made a particular change. To view this log, use the command svn log when you are in your repository. Now you have a basic understanding of subversion and how to set up your server to be a versioning repository. Have fun and happy coding!

If you want to pull your code into Windows to work on it, commit, and other SVN goodies, use the open source TortoiseSVN, it gives you access to all of the SVN power on your right-click menu. Enjoy!

About Server-Bits:

If you've ever wanted to get started building a server, right in your own backyard/kitchen/closet/mother's closet/mother's basement, then this is the read for you. Aimed at the not-so-technical-but-willing-to-learn, this will give you everything you need to build that monster-server you've dreamed of. My goal: To give you a working server, for free, that you can use daily.

Cloudbound: The CR48 (Part 2)

  2010-12-21 06:28:00 PST

The CR48 notebook itself is sleek, simple, and unbranded. Completely unbranded. No logos anywhere. Just a matte black notebook with a rubbery feel. To be honest, reviewing the hardware doesn't really make much sense. The purpose of this pilot program isn't to review the laptop that some company made on contract, the point is to review and bugtest the software. But the readers want to know, just how is the CR48? In a word: Amazing. Like the Nexus One, the CR48 embodies the essence of what Google thinks is possible with a Chrome OS notebook. Simple, from the keyboard to the case, the CR48 is the essence of software driving hardware. Not one logo is shown on the device in any form. Not even an informational sticker or set of warning labels. This is a tool for developers through and through. Honestly, I wish all notebooks were built this cleanly.

A small compliant so far, the battery doesn't quite fit 100% snug to the bottom of the case on one corner. Not a deal breaker by any means, but this shows that the company Google hired is still working out the kinks in the manufacturing process. Granted, this is alpha-hardware, and never meant to be sold to the general public in this form, so I really have no reason to complain. All in all, I really love the simplicity, long battery life, and light weight, easy to carry shape of this build. If this is the template for Chrome OS notebooks, its about to be a very good year for Google. The next post I have lined up is a general overview of Chrome OS, then feature highlights and more in-depth views, including bugs. Stay tuned!

Cloudbound: Chrome OS Introduction (Part 1)

  2010-12-16 07:03:00 PST

Welcome to Cloudbound! My brand new blog category dealing with all things Chrome OS and CR48. As some of you may know already (full disclosure here), I am now part of Google's official beta-tester group for Chrome OS and CR48. Before I get into the specifics, let me go over exactly what Chrome OS and CR48 are, just in case you are new to the game.

Chrome OS is a Linux-based operating system made by Google for cloud computing devices. My, oh my, what a buzz word. Cloud computing. What is it exactly? I can guarantee that most of you do some form of cloud computing each and every day.

Cloud computing is using applications and storage on the internet instead of on your local computer. Ever upload a picture to Facebook, Picasa, or Flickr? You’re using the internet to store those pictures, you are using cloud computing! Ever use Google Docs to type up a paper? That’s another example of cloud computing. Ever listen to music on Pandora, watch a television show on Hulu, or upload a video to YouTube? Those are all great examples of cloud-based media services. So why make an operating system based entirely off of web services? Plenty of reasons! The biggest boil down to the following points:

The next post out will concern the hardware and physical feel of the CR48 notebook and my opinions on the design and build quality. Stay tuned!

Page: 22 of 31