I decided that the best way to test the NC10 from Samsung would be to blog about it, saving throughout the day as I went along... kind of taking it with me.
First impressions were pretty good; as can be expected from Samsung. They are anything but sloppy when it comes to design, and like Apple and Sony, use their design as a kind of trademark. I'm not saying that the most important aspect of a great netbook is design or aesthetics... but usability and great design often go hand in hand so it was a good start. In addition, netbooks can often have a toy-like feel and appearance. Samsung pulls away from this slightly in build quality, but the blue version I picked up did not help.
The next big deal for me was the keyboard. I've always believed that system input is underestimated, but especially for the purpose of netbooking, a usable, scalable keyboard was a real must; on this the NC10 really delivered. At 93% the keyboard is almost full size and this really pays off... primarily because with little adjustment I can touch-type as I would do on a full kb.
The mouse-pad on the NC10 leaves a lot to be desired. The issues seem to be reflected by the user community, in that the pad is unresponsive (even more so in outside of Windows).
The other harsh comparison is between the netbook and any full size notebook. Prior to the netbook I had been using a Dell 14.4 notebook, and the difference was just a little too much to handle. Switching between the two is not a great idea, because it makes the netbooks feel "toy like".
I guess you just have to remind yourself that you are dealing with a different piece of technology here; that its like comparing a noteboook to a cell phone. Just not possible. That helps. For me it was important to remember that the netbook came in at 2.8lbs versus the my notebooks 5.39lbs, not to mention the bulkiness.
I guess the real question comes down to usage and portability. The questions I need to consider are:
1) How will I be transporting the netbook? Will I be using vehicles mainly for transport, in which case the weight would be a little irrelevant, or will I be using a great deal of public transport in which case weight is everything to play for?
2) When I arrive at my destination, how will I be using it? As a system all day on a desk, which again means that a larger size will be better for stability and day-long operation, or will I be taking it into lectures and perching it to take notes... in which case again size is everything to play for.
I decided not to go too much into performance simply because netbooks are much of a muchness. They share the same specs and often the same hardware, so trying to compare them is a little rendant.
Price was an important question for me when I went into the netbook market, and I was please to note that the NC10 would set me back just $380, when my Dell notebook had been around $900. This might seem like a worthless reference, but the feeling that you are carrying less money around is important, it avoids over protection and extreme worrying about loss/theft.
...tbc
Sunday, June 28, 2009
Saturday, June 27, 2009
The Height of Security
Over the last year or so, I've been battling with a way of properly securing my wiki. I've gone through a vast array of cunning systems designed to even stop me from accessing my own system.
The first method was a code book; a simple one but effective and offering physical protection, this method is achieved by simply choosing a new chapter from any given book each month, taking the first however many chars you would like and selecting the first letter or the last letter or a combination to form a password. This method is pretty secure but does require a book (or I suppose an electronic version).
The second was a password map. This is the age old method of creating a A = r , B = p method using symbols and case matching to achieve a secure password. Then you just need to generate a plain text word (such as the month name, lunar cycle etc) and then convert it using the map. Again effective because it requires 2 stage authentication (access to the map and knowing the key word).
Both these methods are very physical. They work, but require either the book, or the map and to remember the chapter and the key word respectively. In essence, not ergonomic to the user, in the brain-workout department!
Many services in the US now use physical token authentication. I've seen services similar in the UK, but only for higher security apps. Physical token uses a simple device, shaped like a usb key or card in some cases. These devices generate seemingly random codes to use at authentication point along with a a password. The devices do not communicate, but rather hold a complex mathematical calculation to generate the code based on date, which the authenticating system also holds.
So far I've seen variations of this used by eBay/PayPal and brokerage services in the States, along with my bank in the UK. The UK version is calculator size and requires you to enter a challenge code before the auth code is released, increasing the level off security even more so.
So I've been dreaming of using this with my wiki for some time. MediaWiki is fairly extensible and I've known there was an addon that should support token authentication. You can of course go through the rigmarole of setting up your own authentication service, but this requires server software installed on a non-Linux client and then a PAM authenticator installed on the local server. Its a little long winded and resource hungry but is secure.
The other method is achieved by using a proxy service like Verisign's PIP. This allows tokens to be linked to the OpenID system (kind of a universal username and password). By using this system I was able to link the Wiki in with OpenID which in turn linked to the token.
The best part about this was that I was able to use my PayPal key and register it with PIP, saving me the time and cost of an additional token. This cross linking is now always possible, but I imagine that in the future it will be.
So all in all a very successful project, as my Wiki is now protected by secure token authentication. The only slight issue I have is the "forgot your token?" link which allows a one-time access code to be sent via email. This seems a little redundant to me, and dangerous if you are in the habit (as many of us are) of leaving yourself signed in. All in all though, pretty darn secure.
The first method was a code book; a simple one but effective and offering physical protection, this method is achieved by simply choosing a new chapter from any given book each month, taking the first however many chars you would like and selecting the first letter or the last letter or a combination to form a password. This method is pretty secure but does require a book (or I suppose an electronic version).
The second was a password map. This is the age old method of creating a A = r , B = p method using symbols and case matching to achieve a secure password. Then you just need to generate a plain text word (such as the month name, lunar cycle etc) and then convert it using the map. Again effective because it requires 2 stage authentication (access to the map and knowing the key word).
Both these methods are very physical. They work, but require either the book, or the map and to remember the chapter and the key word respectively. In essence, not ergonomic to the user, in the brain-workout department!
Many services in the US now use physical token authentication. I've seen services similar in the UK, but only for higher security apps. Physical token uses a simple device, shaped like a usb key or card in some cases. These devices generate seemingly random codes to use at authentication point along with a a password. The devices do not communicate, but rather hold a complex mathematical calculation to generate the code based on date, which the authenticating system also holds.
So far I've seen variations of this used by eBay/PayPal and brokerage services in the States, along with my bank in the UK. The UK version is calculator size and requires you to enter a challenge code before the auth code is released, increasing the level off security even more so.
So I've been dreaming of using this with my wiki for some time. MediaWiki is fairly extensible and I've known there was an addon that should support token authentication. You can of course go through the rigmarole of setting up your own authentication service, but this requires server software installed on a non-Linux client and then a PAM authenticator installed on the local server. Its a little long winded and resource hungry but is secure.
The other method is achieved by using a proxy service like Verisign's PIP. This allows tokens to be linked to the OpenID system (kind of a universal username and password). By using this system I was able to link the Wiki in with OpenID which in turn linked to the token.
The best part about this was that I was able to use my PayPal key and register it with PIP, saving me the time and cost of an additional token. This cross linking is now always possible, but I imagine that in the future it will be.
So all in all a very successful project, as my Wiki is now protected by secure token authentication. The only slight issue I have is the "forgot your token?" link which allows a one-time access code to be sent via email. This seems a little redundant to me, and dangerous if you are in the habit (as many of us are) of leaving yourself signed in. All in all though, pretty darn secure.
Subscribe to:
Posts (Atom)
