Autonomous driving may be closer than we think

Tesla’s Autopilot chip supplier NVIDIA on new self-driving system: ‘It’s basically 5 yrs ahead and coming in 2017’ – Electrek

On a conference call with CEO Jen-Hsun Huang following the results, analysts were particularly interested in the company’s push in AI and the automotive industry, especially since Tesla’s started delivering every single one of its vehicles with NVIDIA’s Drive PX2 supercomputer.

Huang offered some very interesting insights into how he sees Tesla’s self-driving program playing out.

He says that by introducing the necessary hardware for full autonomy now, Tesla  “sent a shock wave through the automotive industry”:

“And I think what Tesla has done by launching and having on the road in the very near-future here, a full autonomous driving capability using AI, that has sent a shock wave through the automotive industry. It’s basically five years ahead. Anybody who’s talking about 2021 and that’s just a non-starter anymore. And I think that that’s probably the most significant bit in the automotive industry. I just don’t – anybody who is talking about autonomous capabilities in 2020 and 2021 is at the moment re-evaluating in a very significant way.”

Huang continued by saying that autonomous driving is not a “detection problem” but an “AI problem” and he insists that it’s going to be solved in 2017.

As the article notes, Huang is obviously biased. Still his reasoning here seems a little too specific to just dismiss as marketing fluff. It seems the the work of engineering a functional solution is nearly complete. There are still the nontrivial legal and business model problems to be solved and that probably won’t happen in 2017. But it appears increasingly obvious that this is all going to happen sooner than most people are expecting.

Integrating legacy applications into a Chrome OS environment – Updated

Why some people need to continue running an old OS

New versions of an operating system offer many advantages.   They usually fix bugs and annoyances in the previous system and offer many new features to both users and developers.  Attracted to these advantages, most users soon replace an older system with the new update.

As users increasingly switch to the newer version, programmers start to put less and less effort into writing and updating programs for the older system.  Because of this new programs or major updates to older programs increasingly either won’t run on the older OS or run poorly.  This in turn causes even more people to abandoned the older system.  It’s a natural progression that has played out many times since the first computer was powered up.

But there is also another side to this situation.  In addition to adding new features, developers of newer versions of an operating systems also often remove features that older programs may have relied upon to run.  As a result older programs sometimes no longer run properly on the newly updated OS.

In some cases programmers will update older programs to run on the newer system.  But no matter how popular a program may be, many developers may still find they lack either the time, resources, ability and/or desire to upgrade their programs.

So when it comes time to update an older computer, users sometimes face a dilemma.  While they may be excited about running all the new software that their older operating system won’t support, they may also need to continue using older programs that the updated operating system won’t run.

This is a problem I began facing several years ago when I started to consider upgrading my aging Windows XP computers.  I knew, based on past experience, that upgrading would not be a simple task because of several legacy applications I used to run my business.  But I also believed I could eventually get everything transitioned.  Transitioning to a new version of Windows was never trouble free, but up until that time I always found work arounds to keep my older programs running.

Unfortunately I soon found that this time my assumptions were not entirely correct.  Starting with Windows Vista, Microsoft decided to become more aggressive in removing support for legacy software.  As a result I and others found that the programs I relied upon everyday to do my job simply would not run properly on either Windows Vista or later on Windows 7.  I knew I could find workarounds for some programs (like XP mode), but even those workarounds that did work were often more complicated and troublesome than previous workarounds.   I also realized that keeping my older programs running on future version of Windows would likely become an uphill battle since Microsoft seems determined to continue leaving its past behind.

I wasn’t the only person who discovered what Microsoft was doing.  Businesses in particular realized that this time the cost of transitioning to a newer version of Windows wasn’t going to just be the cost of buying a new computer.  This time many organizations also needed to develop entirely new business processes based on new software.   This is particularly a problem for businesses who bought expensive industrial equipment designed to last decades and that require custom Windows XP or earlier applications to operate.  Not surprisingly many have dragged their feet as long as possible.  A process that seems to be repeating itself now with Windows 7.

Keeping key software running while moving forward

At first I thought my only choice was to bite the bullet and find replacements for all my legacy software.  But I decided that if I was going to go to all that trouble, why stick with Windows at all?  When I really thought about it, I realized I wasn’t finding any of the post Windows XP upgrades to be all that compelling.  If I was going to be forced into a forklift upgrade, why not take my time and explore other options?

At first I tried several different versions of Linux.  But eventually I took a chance and bought a Chromebook.  I found, much to my surprise, that I really loved how it worked.  The system isn’t perfect, but it is improving quickly.  I like the direction it is heading and it was a good fit for my lifestyle.

But I still needed to figure out what to do about the older applications I had to continue running.  I could find replacements for a few applications, but several were specialized programs that I knew would never be updated.  Abandoning them all at once would be costly and wasn’t a viable option.

For better or worse I needed to find a way to run both a new, modern operating system like Chrome OS and my old Window XP system at the same time.  The challenge was to do this as seamlessly as possible.  Instead of having two independent systems, what I wanted to do was create what would appear to be a single solution.  I don’t entirely have this figured out and it is still a work in progress, but for those who might be interested what follows are a few things I have discovered on how to make this work.

New on new, old on old

One of the first things I noticed doesn’t even involve installing new hardware or software.  It was simply that I found things worked more smoothly when I used an application only on either one operating system or the other.  Even when it is possible, I noticed that trying to keep two versions of the same application running on two different systems is complicated and time consuming.  In most cases it simply isn’t worth the effort.

For example I quickly found there was little benefit in trying to maintain the ability to check my email on both my Chrome OS and legacy Windows systems.  Checking email is much easier and more convenient on my Chrome devices so why fight to maintain that ability on my Windows machine?  This was also true with browsing the web and was among the first actives I stopped on my legacy OS.

A second related issue is that I have given up on trying to keep programs on my legacy system updated.  This is particularly true with large complicated programs like web browsers and office suites.  Even when these programs continue to be officially supported on my system, I often find developers have little interest in doing any more than the minimum work needed to keep them running.  Because of this I have increasingly noticed new updates are more unstable than the versions they replace.

So as a rule I try to only run newer and updated programs on Chrome OS and only older legacy applications on Windows.   Also since most of these older applications rarely access the Internet, I no longer consider the lack of new security updates on a legacy OS like Windows XP to be a significant concern.

Running a single desktop

I knew early on that the only way I could run both Chrome OS applications and Windows XP applications was by running two separate machines.  In my case I decided to retain my existing legacy desktop machine (uninstalling all but my legacy applications) and buying both a Chromebox and a Chromebook. But I also realized that having to move between two different keyboard/mouse/monitor setups, one set connected to each system, would be a headache.  I needed to figure out some way to integrate my legacy Windows desktop directly into the Chrome OS desktop.

My first thought was to use Chrome Remote Desktop (CRD) to access my legacy machine.  While this is a functional solution, I found it to be a less than ideal for a couple of reasons.  The first is that CRD (at least as currently implemented) tends to be slow even over a local network.  In the world of networking tools it is what is known as a “screen scraper” and by default screen scrapping has a tendency to have relatively high latency and be bandwidth intensive.

The second issue was that CRD relies on the Chrome browser being installed on both machines  With Google having ended Chrome updates for Windows XP in early 2016, I knew this wouldn’t remain a viable long term solution.

I decided a better alternative was to utilize a desktop sharing solution that was already available on many Windows machines.  Remote Desktop Protocol (RDP, formerly Terminal Services) is a Microsoft protocol for viewing a Windows desktop across a network.  It is a multiplatform, multiuser solution that is even functional over the Internet if you open port 3389 on your router.  Because it is based on a lower level protocal performance has a tendency to be quick even in low bandwidth situations (an RDP server sends compact information that describes a desktop rather than what is essentially a series of screenshots of the desktop).

A RDP server is built into all Pro versions of Windows.  All that I needed was a Chrome OS RDP client.  A quick search of the Chrome Store soon found Chrome RDP.  Chrome RDP isn’t free, but it is well worth the $10 price.  For me it is fast enough over a local network that it seems like I am directly connected to my Windows computer.

There is one minor issue to be aware if you are trying to use the Chrome RDP client to access a RDP server running on Windows XP or earlier.  By default Chrome RDP won’t log into these version of Windows.  But there is an easy fix.  You just need to change a setting that disables Network Level Authentication (Options:Advanced, check “Allow Non-NLA Connections).

The only downside for some users is that a RDP server is not available on Windows XP Home.  In this case there are two alternatives.  Probably the best bet is to just upgrade to a Pro version of Windows.  For Windows XP you need to find a retail copy of Windows XP Pro (either the full or upgrade version – the OEM versions won’t work).  You can commonly find a copy of this and other Windows Pro versions on places like Ebay if you look around.  [Yes, I am also aware that technically a RDP server is already built into most version of Windows including the Home edition and that there are various hacks to enable it.  I’m sure most of these probably work fine, but since there are always possible issues with any hack I won’t make any recommendations here.  Google and proceed at your own risk if you want to explore this option.]

Be aware also that the Chrome RDP client does have a few limitations.  The big one is that it won’t, at this time, pass any sound from a Windows system even though this is technically possible.  For me this isn’t a problem since none of my legacy applications rely on sound.   But I recognize that this could be a significant problem for others.  I’ve also run into some rare Windows applications that for some reason don’t play nice with RDP (e.g. there is an odd bug in Word 97 where the “cut” command (but not the “copy” command) occasionally fails.

If you can’t upgrade to Window Pro, find Chrome RDP to be a less than ideal solution, and/or are running a legacy OS other than Windows, the other alternative is to use something similar to CRD called VNC.  The VNC protocol has been around for years and there are multiple different clients and servers available for different operating systems including a free client in the Chrome store.

I have found the open source version of RealVNC server works well on Windows XP.  There are also versions available for various Linux distributions.  My understanding is that a VNC server is also included in Mac OS X version 10.4 and later.

Overall VNC is lightweight and easy to install.  While it is still a “screen scraper”, personally I found the performance to be better than CRD and for me it is more stable and easier to use.  Also unlike CRD, VNC doesn’t require the installation of the Chrome browser on your legacy machine.  Keep in mind that in many situations you also have the option of running both Chrome RDP and VNC and can rotate between them as you see fit.

While using either a RDP or VNC client to access my legacy Windows machine works well most of the time, there are a couple of minor issues that I have run across mainly related to the keyboard layout used by Chrome devices.  Even though I might see a legacy application on my screen, the keys on my keyboard still function like they would if I was using a Chrome OS application.

In my case some of my legacy Windows programs require use of function keys (F1, F2, etc) to run properly.  By default Chrome OS doesn’t enable these keys even if you plug in a PC/Windows keyboard.  Fortunately there are two easy solutions.  The first is to just hold down the “Search” key and press one of the keys on the top of your keyboard.  For example pressing Search+[]]] = F5 (if you are using a Windows keyboard on a Chromebox  press the “Windows” key and the F5 key instead).  The other alternative is to change a setting in Chrome OS to force it recognize the top row of keys on your keyboard as function keys.  In this case if you want to again use a Chrome key as usual (e.g. to mute sound or darken the screen), simply hold down the Search and press the appropriate key to temporarily restore that function.

Sharing files between Chrome OS and a legacy OS

The next issue I faced was how to share files between Chrome OS and my legacy Windows OS.  In Windows files are typically stored on a local hard drive and shared via the SMB/CIFS protocol (aka Windows File Sharing).  Macs and most Linux systems also usually support this protocol via some implementation of Samba.

When Chrome OS was first released, the only way to store files was either on a small local drive or remotely on Google Drive.  However support for other file systems has been added to Chrome OS through the File System Provider API.  While this API doesn’t directly support any particular file system, it does allow third party developers to add support for many alternative systems.

Assuming your legacy OS machine has been setup to share files. using a SMB/CIFS plugin is easy.   All you need to do is download and install one of two SMB/CIFS clients from the Chrome Store and run the app.  Both programs will ask you to enter the IP address (or DNS domain name) of your legacy OS machine, the “share” or file folder you want to connect to and your username and password if any.  If you are on a large Windows network, you may also need to enter your Windows Domain name (most people can leave this blank).

Unfortunately there is one annoying bug in the File System Provider API that for some reason Google seems to be in no hurry to fix (the bug report was first filed over 2 years ago).  The native File app in Chrome OS can always access a remote file system.  But the Chrome browser itself cannot.  What this means is if you find a file on a website that you want to save, Chrome will only give you two choices – the local “Download” folder on your machine and Google Drive.  Your remote file system won’t be an option.  This means you have to download the file locally and then open the File app to transfer the file to your remote file system (highly annoying).  Oddly enough you are able to upload a file from your remote file system to a website in most cases (flash based upload apps seem to be the exception, but at least these are slowly going away).  So adding an attachment to GMail thankfully works.

Feel free to visit this bug report and click the “star” in the upper left corner to encourage Google to fix this issue if you are so inclined.  You must be logged into your Google account for this to work and will be emailed any updates on the issue if they ever start working on it.

If you want, in some cases you may also be able to access your Google Drive files from your legacy system.   There are two ways this can be done.  The first of course is to use a web browser.  But since keeping a modern web browser running under a legacy system often becomes increasingly difficult, this may be a less than ideal solution.  Also using files this way is often a two step process since in most cases since you typically can’t use a browser to directly open most files.  Instead you first have to download the file to a local folder and then open it using a legacy application.

The other option is to install the Google Drive Sync application.  The Google Drive Sync application will create a folder on your system called “Drive” and keep that folder synchronized with the contents of your Google Drive account.  By default the “Drive” folder will be placed in your “My Documents” folder in Windows, but you can override this during install by selecting the “Advanced” tab (note: you typically cannot change this after installation without reinstalling the program).

For the most part Google Drive Sync works well and unlike CRD it doesn’t require the Chrome browser to be installed.  Hopefully this means it will remain a relatively long term solution.  The only issue that you might want to keep in mind is that, since multiple users could potentially be syncing different Google accounts on the same machine, the program is designed to only run and sync your files when you are logged into your account.  If this is a problem you may want to consider either scheduling Google Drive Sync as a Windows task or using Microsoft’s srvany application to run it as a Windows service.

Bear in mind that my rule of “old on old, new on new” also seems to apply to data files as well as applications.  In other words if you primarily work with certain files on either your legacy or Chrome OS system you should store your files on the relevant system.  The problem of course is certain files (like images and pdfs) may be needed on both systems so it can sometimes be difficult to decide where to store them.

Although each situation will be different, in most cases I have found it is usually easier to access files on an SMB/CIFS share from a Chrome OS device than it is for a legacy system to access files on Google Drive.  As a result I usually default to storing my files on my legacy Windows system.  I definitely try to avoid placing a file in both locations since this creates synchronization problems (you are never quite sure which one is the one you need).

The downside is this is not the best alternative if you need remote access to your files.  But there are a couple of workarounds.  The first is to buy a router with a built in VPN server and use the VPN client built into Chrome OS to access a SMB/CIFS share sitting behind the router.  The problem is the process of setting up a VPN server usually requires networking skills that are beyond the capability of the average Chrome OS user.

A second option is to install a web server like Apache on your legacy system (usually enabling password protection and encryption via https) and then opening a port on your router to expose the server to the internet.  For Windows based systems I recommend using XAMPP (last supported version for Windows XP is 1.8.2 ).  The default install of only Apache and PHP is typically sufficient.

I have found this is usually a faster and more reliable way to access your files particularly over flaky internet connections.  But you won’t be able to use the standard “open file” dialogue box to access your files .  Like using a browser to access your Drive files, you will need to use a browser to first download your files to the local Download folder and then access them from there.

The problem with setting up a web server is again that it usually involves skills beyond the average Chrome OS user.  But for any company or organization with access to a good system administrator, this and setting up a VPN are both viable alternatives.  I have placed some instructions on setting up Apache and a few tiny but helpful php files in this zip file for those who might be interested (the php files are just small, human readable text files).  A Chrome OS text editor can be found here.

Finally no discussion about file management would be complete without addressing the issue of backup.  While each situation is different, in most cases you want to accomplish three things with a backup system.  The first is you want to get copies of your files off site (in case your house burns down and/or your online account is closed or hacked).  The second is ideally you want to make additional copies and store them over time (in case you find you suddenly need something you accidentally deleted last week or last month).  Finally both these things should happen automatically.

Keep in mind you will likely have files both on your legacy system and in Google Drive and should always have backups of both.  This typically will require you to have two different types of backup systems.

If you want you can setup a third computer in a remote location and use it for your backups.  But this process can be fairly complicated, more expensive than you might think and rather high maintenance (at least it has been for me).  Today I usually recommend using one of the many cloud based backup systems now available rather than rolling your own.  For a legacy system, I personally like Backblaze (if you also decide to use Google Drive Sync, be sure to see additional instructions here).    For backing up a Google account I’d recommend taking a look at something like Backupify (if you have a G-Suite type account) or CloudAlly (if you have a standard Google account).

Sharing printers and scanners


Printing on Chrome OS is a bit of a challenge because the native printing system in Chrome OS is via Google Cloud Print (GCP).  As a result printing from both Chrome OS and a legacy OS means figuring out how to enable GCP and still being able to print using a legacy OS print driver.

One option is to connect a printer to your legacy box as normal, install the Chrome browser and then enable GCP (with Windows XP you also need to make sure to install the “Microsoft XML paper specification pack”).   While this works, it probably won’t be a long term solution because it again relies on installing the Chrome browser which may not be supported and/or functional over the long haul on your legacy system.

Because of this I usually recommend buying a GCP ready printer.  GCP ready printers are network printers which means they are essentially a computer with a printer built in.  As a result they aren’t dependent on a connection to a separate computer to control them or run the GCP software.  Instead network printers today are usually configured via a web browser.  You no longer need to install and use the custom configuration software that was typically needed in the past.

The only issue here is to make sure the printer you buy still has drivers available for your legacy system.  While most major manufactures seem to be doing a pretty good job of maintaining legacy drivers, I would recommend verifying this before making a purchase.

In many cases to enable GCP you just connect the printer to your network, open the printers configuration application in your web browser, find and click the GCP menu and register the printer.  Registering a printer usually just involves entering your Google username and password.

One of the problems with GCP of course is that it makes printing offline impossible.  But there is a workaround if you have a relatively modern GCP ready printer.  One nice thing about most modern GCP ready printers is that they typically also implement a newer printing protocol called IPP Everywhere (see my previous comments in this post for more background).  An app in the Web Store called “Wifi printer driver for Chromebooks” taps into this capability via Wifi Direct (which is based on IPP Everywhere) allowing you to print offline.  You can even use the printer at a friend’s house or in a hotel if they have enabled Wifi Direct on their printer.

Once this is done you need to decide how you want to connect the printer to your legacy machine.  There are a couple of possible ways of doing this including using a USB cable.  But I find the easiest and most flexible way is to connect to it over a network using LPR (aka LPD/LPR or Line Printer Remote protocol).  I found doing so allowed me to place my printers in more convenient locations and makes sharing them with other users easier.

The LPR protocol has been around for decades and has been built into almost every network printer ever constructed.  Almost every major legacy OS has the ability to connect to a LPR printer.  The only thing that is a little tricky with using LPR in the case of a legacy OS like Windows XP is that the LPR software may not be installed by default.  In the case of Windows XP, you need to use the Add/Remove Windows Components applet in the Windows Control Panel.  In the applet it is listed under “Other Network File and Print Service”.  Once the LPR software is installed you install your printer driver via the “Add Printer” wizard in Windows as normal.  For other legacy OS’s you will need to use Google to search for the relevant instructions.


The most convenient way to add scanning capability is to use a network connected multifunction device that can print, scan, copy and/or fax.  Similar to stand alone network printers, these devices usually come with all the software needed to handle most scanning, copying and faxing functions already installed in the machine itself.  Unlike in the past,  you no longer need to install separate software packages on your computer in order to use them (one example).

What this means is that you can walk up to these machines and scan a document without dealing directly with your computer.  Depending on the device settings, scanned documents are immediately converted to a file (pdf, jpeg, tiff, etc) and sent to some type of local or remote storage device (network share, ftp site, website (e.g. Google Drive), flash drive, etc).  Some even have built in OCR.  Unless you have unique requirements, odds are you can find a device that will fit your needs.

My current machine allows me to scan either directly to my Google Drive account or to an FTP folder.  Having set up shortcuts with common default settings, I can usually scan documents by only hitting a few buttons.  I then just look for the file in either a Google Drive folder or a folder on my legacy machine.  In many cases this can eliminate the need for dedicated scanning drivers or software on either your Chrome OS or legacy machine.

Obviously being able to scan to a Google Drive folder is the easiest way to make scanned files available on Chrome OS.  While in my case I didn’t find this difficult to do, unfortunately this isn’t yet a common feature on most multifunction devices.  I am hoping that perhaps someday Google will create something like a “Google Cloud Scan” program to encourage manufacturers to add this capability in a consistent manner (although I’ll admit I’m not holding my breath).

The easiest way for a network scanner to send a file to a Windows machine is to have the scanner upload a file to a shared folder via SMB/CIFS.  However like Google Drive support, this is also not supported in all multifunction devices.

Instead uploading files to an FTP site seems to be a more common alternative and this of course requires installing some type of FTP server on your legacy system.  Fortunately there are several FTP servers available for Windows and most other legacy OS systems.   Most are easy to install and use.

I have found Filezilla Server works well (version 0.9.42 was the last to officially support Windows XP).  The server even comes with a nice Windows program that makes configuring it easy.  Slimftpd is also a super small FTP server that I have found to be fast and stable (basic instructions).  Because you are typically running these servers within your own network (not exposing them to the internet), security usually isn’t a major concern.

When choosing a scanner there are a few limitations on some machines that you may want to be aware of and avoid.  First of all I have found that some scanners don’t always scan edge to edge.  This is particularly true of automatic document feeders that sometimes cut off the top and bottom of a page (this is usually not a problem when you scan using a devices flatbed scanner).  Depending on what you are scanning, this may or may not be a problem.

In addition image quality can vary significantly.  Text based documents usually look fine, but detailed grayscale and color photographs will quickly reveal a marginal scanner.  Unfortunately price isn’t always a reliable indicator in this regard and testing directly isn’t always an option today when most are bought online.  But if you ask around you might find someone who has the model you are interested in and is willing to post or email you a sample scan in the format and resolution you typically use.  I usually find 300 dpi grayscale or color is the minimum necessary to archive common paper documents in a readable form.  In most cases avoid the black and white setting.


Of course not all of the above advice is entirely unique to Chrome OS.  Much of it could also apply to almost anyone who has invested heavily in a particular operating system and now needs to move on.

With the release of Windows 10, I suspect it may not be long before those who have spent years pouring their data into Windows 7 start facing many of the same issues Windows XP users had to deal with over the past few years.  Perhaps a few of them will find some of these strategies helpful.

Updated March 5, 2017