system.reflecti0n.net

Just thinking out loud really, but it's another of those “Why Not?” sort of statements. Yeah, I do those from time to time...

This feels like a possibility because Microsoft has already demonstrated a fondness for packaging the Vista OS in every conceivable way, from Home Basic to Ultimate. Their marketing team is out of control and the sheer number of Vista packages on the shelf at your local computer store is proof-positive of this.

So What to the Boys in Marketing See?

The continuing rise in the sales of the MacBook (at least within North America) means there is a growing market for boutique PCs that sport few variation on hardware configurations that the Windows team could make good use of, producing a Windows kernel that is tailor-made for running on Macbooks.

This is not such a bad line of work to pursue since there's a) a market, and b) the future MinWin kernel is to make specialized editions of Windows more probable through its modularity support... so why not a kernel of Macbook optimized modules.

Keeping it Simple

At the very least it could settle the presumption by Windows apologists that the Mac OS works so well because the hardware variations are so limited that Apple doesn't need to produce a swiss-army-knife of an OS like Windows. That is, if M$ did the same by producing a Mac edition of Windows they too could tailor their kernel to only work with the drivers necessary to operate a Mac. Heck, maybe even leave out the option to install drivers to alternate hardware (i.e. why leave in code to replace the ATI video card with an Nvidia card? It's not even supported within the hardware so there's no need for support to change it).

Embedded software engineers have been making good use of this practice the days of the old Atari 2600. Hey, we always write better software when we get control over the largest possible set of variables. Hardware is possibly the most visible and significant issue any programmer deals with.

Tags: windows, apple, windows7

I am really getting to hate all the sites that matter-of-factly ask you for your login and password to your GMail/Hotmail/Yahoo account so you can "tell your friends" about the new website you joined. This was a dodgy proposition the first time I saw it nearly 2 years ago, and I still think its dodgy no matter how big and popular the site is, no matter how nicely they ask for it. My login and email provides unfettered access to my email and any of the associated services. It's simply STUPID to trust that to anybody. I image it's akin to leaving your PIN number at BestBuy so they can purchase something on your behalf when you're not around, just because their management thinks you's like it.

I'm not against the notion of sharing my whereabouts with people, but my passwords? Nope, no chance. That doesn't mean I can't share my list of like-minded friends with new and exiting websites I join. All that's needed is a more sensible and secure way to share information that leaves third-party access up to the discretion of the end-user at all times.

Enter the Contact-Management API

Suppose each of the big email engines confirmed to a small data-sharing API... Basically just a small agreement that when you enter a URL like this:

http://mail.somesite.com/sharing/7a45e9b923749d839f8f093eee

...The URL part would be an MD5 sum or one half of a GPG-key, unique to the third-party requesting the shared data, and unique to the website hosting your email account. A well-formed request like the one above would provide a response like this:

bob@example.com,Robert Terwilliger
tina@somesite.com,Tina Argent
...
melvin@somesite.com,Mel Absolute

This is a simplistic example. The response could easily be a microformat or RDF or any format that could be easily understood among third-parties.

How Sharing Works in the Contact-Management API

When the need arises to share your contacts with another website the site making the request would email you with a 'sharing' key. On opening the email you would copy the key into your email site's "Contact Sharing Manager" along with an expiry date selected by you. It would look something like this:

Now the you get to decide who, how often and when a third-party gets access to your contacts. Without sharing your password. And the best part is the sharing is under the control of the user.

More advanced features could be added at the discretion of the email portal, like providing the user a way to select which contacts get shared, on a per-sharing-key basis, access logs (in case the website keeps coming back to get more contacts).

I think this is simple enough to be managed by almost anyone who grasps the utility of sharing their contact info when they sign on to a new website.

Preventing Contact Siphoning

How Much Data to Share?

The user-selected expiry date for sharing could prevent some abuse of sites extracting too much from a credulous user, especially if it's understood within the API that there is some upper-limit to how many contacts get shared per-request. This could curb abuse when the API only coughs up 5-10 contacts a day, giving the user an opportunity to monitor a new website through the shared contacts and decide if he wants to "open up" more or all of their contacts for sharing. If the newly joined website turns out to be a bit dodgy, the user can stem the tide by revoking the key immediately. Revoked keys could be tracked by the email provider and possibly warn others of high incidence of user-revokes.

Where Does the Data Go?

We can take the security/paranoia up a notch by requiring the sharing key to not return raw data, but decrypt a URL at the third party making the request. This URL would be an endpoint where the email provider could "inject" the contacts into your third-party account. This would be a handy way to verify where the data is being sent to, and enforcement could be done by declaring ahead of time which domain the Sharing Key belongs to. This two-step process would stop anonymous third-parties from "phishing" popular email portals for Sharing Keys.

This is only the beginning of the protection measures that could be provided. Optionally logging, tracing and emailing usage reports could also enhance the end-user's control over their personal data sharing. Heuristics or machine-learning could be applied at the email portal to build a profile of legitimate use of the Contact-Management API.

Nice Idea, But Who's Going to do the Hard Work?

Well, even as I wrote this I considered the possibility that this sort of sharing is already developed at that new Data Portability workgroup but they are directing their energy in documenting and organizing the work that's already been done, a lot of which is just different markup standards and microformats for identifying what kind of data you're sharing instead of how to control sharing. I was a little disappointed to see that, but they're pretty up front that they're not about developing new technologies.

Then I looked at Google's OpenSocial API Developer's Guide but at a glance the security is based on trust of a site in general. I think if I wrap my head around it you could make the OpenSocial API into something that provides some of the features I describe, but Googles documentation actually says: "but this decision is up to the container" - the container being website that can host OpenSocial gadgets so really it's up to the site itself if it trusts third party sites so no, it's not within the user's control.

In the Future, Everybody Will Share Data for More Than Fifteen Minutes

I've only made a cursory survey of the options and features available in either Data Portability or OpenSocial but I still think there is a gap here that would provide untold value to the people who actually use, instead of those who create the places to visit in, the Internet. Greater control exercised by the end-user has been the trend in more recent waves of popularity on the Internet. Now it's time for users to do more than just cast a vote on their favourite bookmarks. The Contact-Management API is one step toward the inexorable goal of letting the end user decide who, where, when and how often their data is shared.

Tags: data portability, contact management, social graph, security, architecture

You know, for something that looks as cheap as this, the eeepc actually works really really well.

By really well I mean that all the advertised features work as advertised. Event the wireless networking runs surprisingly fast.

By cheap, I mean this looks like one of those cheesy toy laptops you'd get at Zellers for your 8-year-old nephew. You know, it would have an equally cheesy brand name like Panthertronics or some atrocity towards compound words.

The New eeepc - First Impressions

Back to the point, at first try, you wonder what you've plonked your $300 over... apps like Firefox and OpenOffice seem to take an age to show a splash-screen, let alone load. But once you get past those seemingly long app loads, the apps themselves seem to run nice and smoothly. I don't have the booklet with me, but the 512 Mb of RAM is probably DDR. I think the bottleneck must be the solid-state drive. I'll gladly accept the slow SSD since it probably makes it possible to run this gadget on a battery no bigger than three “C”-cells.

I'm glad to be using it now, but I got off to a bumpy start. After poking around with the default OS (based on Xandros, once upon a time the basis for the Corel Linux OS) I noticed ASUS included a booklet on how to install Windows XP Sp2 on the device. 2Gb of storage be dammed, here I have written proof that ASUS wants me to install other operating systems on their hardware. This was too good to pass up!

Installing Windows Xp on a 2Gb eeepc

Unfortunately for me, the only valid installation I had for XP was an old Sp1 install disk. Nevertheless I plodded on using my external DVD drive. In about 50-60 minutes the install was over, but my hunch was the included drivers were never going to work without Sp2 installed, especially the wireless support, which changed so much from Sp1 to Sp2. So I found my network install of Sp2, copied it to a USB key and got down to work.

Installing Xp Sp2 on a 2Gb eeepc

This is where things started going downhill. First, I get the message like Sp2 cannot install because there is not enough disk space. No surprise there, I had partitioned the SSD in two, 1.5 and .5 gigs. I plugged the USB into another laptop and manually extracted the files onto yet another USB key. Now I could install Sp2 directly from the USB key using the Update.exe command (look inside the subfolders of the i386 folder extracted). Again, another 30 minutes or so to get the service pack installed and you're off to the races.

Off to the Races... or the Glue Factory

Now it was finally time to unwrap the ASUS-provided driver CD. In it goes and directly offers to install the ACPI drivers-- not even a reboot is asked for, that's not so bad. Now on to install all the other drivers... whoa, eight more drivers huh... and four reboots, well it's nice of them to let me know. I start flipping through the Saturday afternoon sports offerings on TV, keeping one eye on the eeepc, as each reboot required me to login again as I didn't leave the administrator password on 'blank'.

This ASUS drivers CD worked as advertised though, after about an hour of waiting and watching all the drivers for video, audio, wireless and networking were all installed, with no effort on my part except to login after each of the four reboots. I really want to hand it to ASUS, they did everything possible to make this device work for their customers. I don't always have such a smooth ride installing that many drivers at once.

Windows Update - to the Gates of Hell

Up until this point I was pretty stoked that I was going to get to use the eeepc with all my favorite software, especially AbiWord and Windows Live Writer (the possibility of having a handy little 1.2-lb. wordprocessor in my backpack was the driving issue for me). Though I may be a fool, I am never foolish, so my next stop had to be Windows Update to finish off the job of patching up my new teensy (tEEEnsy?) pc.

And this is where using Windows XP Sp2 on a 2Gb eeepc comes apart at the seams. There are simply too many updates on to a fresh Sp2 system to install them all on a 1.5 Gb partition (i would later try using a full 2Gb partition, no dice either).

About ¼ of the way through the 89 patches pumped in to the system by Windows Update and i started getting repeated warnings about running out of drive space. This happens around the 100Mb-free point. Eventually all the updates fail as there is no room left to finish the installation, let alone download all the necessary install files.

The forensic evidence turned up a folder at C:\Windows\SoftwareDownload which is where the BITS service downloads all the update files that will get installed on your computer. Note, if you TURN OFF Automatic Updates after starting Widows Update, the BITS service will continue to download updates into the SoftwareDownload folder until all the files are completely downloaded. in other words, if you start deleting files in this folder to make room, more files will turn up in there place! Maddening, to be sure.

A leafing through the booklet at this point, to see if there was a warning about installing on 2Gb systems turned up nothing, but ASUS did recommend compressing the drive. Since I corrupted the SoftwareDownload service by deleting all the downloaded files, I chose to start from scratch again, meaning installing XP Sp1, Sp2 and drivers all over again, then do a drive compression and see how far I'd get. I did this only because I love to use Live Writer so much.

Hard drive compression did the trick, I was able to finish all of the Windows Updates. But upon reboot that useless appendage called “Windows Genuine Advantage” crashed. I tried to ignore this, but it seemed to be preventing me from installing Windows Live Writer as well.

A search through Google turned up a KB article indicating that the licensing database used by WGA can become unusable if the system drive is heavily fragmented. Lo and behold, this was true, Disk Defragmenter displayed more red than all the fans at a Montreal Canadiens home game. Repeated attempts to defragment the drive made little to no improvement (seriously, i tried about 20 times). This was probably a side effect of so little leftover space (about 200Mb even after compression) and the system drive compression itself.

Without Windows Live Writer, there really is no point to using Windows (even though reboots were complete in under 10 seconds) and I can get AbiWord for Linux just about anywhere.

Back to the Beginning: Xandros Linux for eeepc

So that's what brought me here. Along the way I tried “eeedora” the Linux distro based on Redhat's Fedora distro, but I never did get the wireless adapter working, in spite of numerous forum posts about the same.

The re-install of Xandros wasn't straightforward either. it seems results may vary when restoring by external CD/DVD. ASUS recommends getting a 2Gb USB still and performing the factory restore by booting from the USD key instead of external CD. Luckily, the instructions on their support forum were excellent and worked as advertised.

So here I am. Contentedly typing up this blog post and several others in OpenOffice 2.0 (I would be happily typing away if only I could get AbiWord to install, but maybe that's another blog posting) when I realized that this thing does work every bit as well as you'd need it to. Given it's small size, it demonstrates ASUS's sage engineers as the least bit of frustration would send this tEEEnsy device hurtling across any large open space. (Yeah, that last part probably only makes sense in my mind, but I keeping it in there, it's my blog and I don't have to make complete sense...)

Conslusion

Really, skip getting that next-gen iPod. An eeepc is going to be far more useful if you have any inclination to blog, or write for pleasure at any time in any place. Seriously, you'll love having the compactness of a paper-and-pen notebook combined with the word-processing options of a mouse-and-keyboard notebook.

Update: AbiWord is now installed... I repeat, AbiWord is loaded and running... one step closer to perfection!

Tags: eeepc, winxp

I've been managing a few website profiles for a couple of years through Google's Webmaster Tools. I was disappointed to notice only a month ago that Google never indexed my sitemap URLs. Instead I would get a long list of 404s that were not URLs from my sitemap files.

404 Whatever

It never mattered much to me since these sites were getting indexed organically through legitimate links on other sites. But I approached it as an opportunity to fix and and maybe give a boost to the pagerank on these sites.

It seems the URLs that Google had a problem with were all folders. I.e.:

http://www.somesite.com/somefolder/ 

...or: http://www.somesite.com/some-other-folder/ 

...or: http://www.somesite.com/yet-another-folder/without-content/ 

I generate the sitemap XML myself with a small custom app, so I went to the sitemap files to see if I'd made a mistake somehow. I didn't find any of the URLs that Google had a problem with, but all of Google's example bad URLs were actually truncated versions of the real URLs that I put in the sitemap XML. I.e.:

http://www.somesite.com/somefolder/index.html 

...was being shortened to: http://www.somesite.com/somefolder/

Ok, so Google works on scales of millions and billions, any savings made by truncating the default page name from a URL is not out of character. That makes some sense.

No Google, it's not YOU-- it's ME

So now my problems really begin because the platform the websites are using is 100% SEO-optimized virtual URLs and the filter won't turn on unless it ends in "*.html" -- Changing the filter rule to use "/*" would always break the site because it would try to SEO optimize all the other files on the site (e.g. .css, .jpg) so that was of no value.

So my option was to turn off the URL-rewriting or fix it in some way. Turning off SEO URLs would break nearly all the organic links accumulated over the past 2 years so that was out of the question. That left me looking for some way to fix it.

301 to the Rescue

Since I don't have any control over Google's will to chop up my URL I figured the next best thing was to tell Google there's nothing at the end of those truncated URLs. So I found a filter on the platform that would getting engaged on every http request, but wasn't interfering with the non-.html files on the site. I cranked up Eclipse and added some code to detect a truncated URL, paste the "index.html" part onto the end then redirect the request to the expanded URL, along with the requisite "HTTP 301" code so Google gets the correct message.

Mission Accomplished! ...WTF?

So I wait a week and what do I see in Webmaster Tools? Google tells me "we've found some URLs in your sitemap contain too many redirects".

Apparently, something is lost in the translation, as what they really meant by "some" was "ALL" and "too many" means "one". Yet again, absolutely none of my sitemapped URLs are being indexed.

I was beginning to think that this Google Sitemaps stuff was a load of bunkum, except I had a third site that was operating on yet another platform that had nearly all of its sitemapped URLs indexed according to Google.

Ok, I Tried Playing Good Cricket and Got Judo-Flipped

Yes I played within the boundaries, well within the boundaries, for many many months and got nowhere. So if there was going to be any fix for this I was going to have to leverage Google itself knowing that it was parsing and truncating my sitemaps file.

The given part was that if I'm going to use a common default web page name like "index","default" or "home" Google was going to chop it off of the end of the URL. So the next way to go must be to avoid using any defaults names in any of the URLs.

Lucky for me the web platform causing the problem really didn't care what the web page name was, as long as it ended in ".html" the filter was going to parse everything else in the URL, except for the html page name! So I opened up a sitemap XML file in notepad and changed every instance of "index.html" to any other name. I.e.:

http://www.somesite.com/somefolder/index.html 

...was changed to: http://www.somesite.com/somefolder/somefile.html

...Since I was familiar with these URL names I varied many of these file names so they doubled as keywords relevant to the content found at that URL.

We're Done-- When Google Says "We're Done"

After about 20-30 minutes of painstaking notepad editing I re-submitted my sitemaps to Google. Within 30 minutes Google's crawlers had downloaded and validated my sitemaps as error-free... 30 minutes!

Conclusion: "Solutions: good. Wasted time: bad!"

The real shame is when I sent useless sitemaps to Google, it took them nearly a week to process them and post results. If they had just provided a little more feedback than "404-this" and "too-many-301s-that" we both could have saved ourselves A LOT of wasted time.... I wonder how much time is lost (human and computer) every day because of badly-formatted information?

Tags: web design, seo, google, optimization, webmaster tools

If you're in the business of selling on software as a service, here's a little tip:

If you must write a brand new feature at the customer's request, you've already lost the sale.

...Yeah, you heard me. Software I've had a hand in has been sold as a service hundreds of times over. To companies you'd know by name to be sure. But in all my years of coding for a living, I've never seen the deal get closed on the basis that we added a feature to our existing product.

That's not to say I've never extended the features of an application I've helped to create-- but it's always for a client (i.e. someone who's already "signed on the dotted line").

I've spent many a late night trying to appease many a sales executive to create the product they wished they had to sell and since I'm the kind of guy who keeps mental tabs around these sorts of things I can tell you that I've never seen additional features turn a customer into a client.

This is just one of the facts of life for those of us who work in the application service provider space. File this one under: "Birds and the Bees for ASPs".

Tags: coding, application service providers