Amazon WorkSpaces was a doddle to get up and running as I am very familiar with VDI and workspace concepts. I’d not touched AppStream before, so I needed a bit of primer. I found this video by Thorr Giddings to be excellent. To the point and, for someone with quite a bit of experience, I was able to pause the video at the various steps and get the process down. The best 8 mins of my time this week!
In case you don’t know, Amazon AppStream is a fully managed application streaming service. You centrally manage your desktop applications on AppStream and securely deliver them to any computer. You can easily scale to any number of users across the globe without acquiring, provisioning, and operating hardware or infrastructure. AppStream is built on AWS, so you benefit from a data center and network architecture designed for the most security-sensitive organizations. Each user has a fluid and responsive experience with your applications, including GPU-intensive 3D design and engineering ones, because your applications run on virtual machines (VMs) optimized for specific use cases and each streaming session automatically adjusts to network conditions.
This week I spent time working with Amazon WorkSpaces. In case you don’t know, Amazon WorkSpaces is a managed, secure cloud desktop service. You can use Amazon WorkSpaces to provision either Windows or Linux desktops in just a few minutes and quickly scale to provide thousands of desktops to workers across the globe. You can pay either monthly or hourly, just for the WorkSpaces you launch, which helps you save money when compared to traditional desktops and on-premises VDI solutions. Amazon WorkSpaces helps you eliminate the complexity in managing hardware inventory, OS versions and patches, and Virtual Desktop Infrastructure (VDI), which helps simplify your desktop delivery strategy. With Amazon WorkSpaces, your users get a fast, responsive desktop of their choice that they can access anywhere, anytime, from any supported device.
Well, it’s just gone past a month since I joined Droplet Computing, and I’ve been busy, busy, busy, as well as you would expect when you start with a new company. As you might suspect, I’ve been quite “internally focused” (which sounds like some sort of medical examination!). But I’ve been trying to hold true to my goal of making Friday my geek-out day where I just get some technical playtime. I’ve been considering renaming Geek-Out Day as Michelle’s Mad Half Hour. You never know, it might catch on.
Note: Before you go down this particular rabbit hole. Three words of advice.
Firstly, even with all the CPU accelerators in place and as many of the performance barriers removed, this emulation is not very horribly quick. It’s useable, but you could just go out and buy a cheap Chromebook, and get fantastic performance.
Secondly, the version of ChromeOS currently available on Android Studio is quite old its version 6.7.
Finally, although this performed better than the nested Windows version I had running on my ESXi host, I found it crashed more frequently on Ubuntu than it did on Windows10. I’d be tempted to try this on physical Windows.
For me, the deal-breaker is the ancient release of Google ChromeOS available through the ChromeOS Repo. Its something I might come back to using a Windows build in a few months time. The setup here works for ALL operating systems including Windows, just skip the Linux bits if you setup on Windows.
I recently had a need to install Ubuntu to a physical box (I know what a concept!) and I connect it remotely using VNC Viewer from RealVNC. One thing I noticed was how poor the screen resolution was on my 27″ wide-screen. I assumed I’d just need to crank up the resolution relative to my screens capabilities. The trouble was that there were only 3 resolution modes available.
1024×768 (4:3)
800×600 (4:3)
848×480 (16:9)
I must admit my first thought was perhaps this was an issue with my graphic controller not being discovered. Actually, it turns out that Ubuntu doesn’t ship with many resolution modes.
To add additional resolution modes open a terminal………
1.) Type the command to retrieve the display mode:
xrandr
This should give us an output like so:
Screen 0: minimum 320 x 200, current 1024 x 768, maximum 4096 x 4096
VGA-1 connected primary 1024×768+0+0 (normal left inverted right x axis y axis) 0mm x 0mm
1024×768 60.00*
800×600 60.32 56.25
848×480 60.00
640×480 59.94
Make a note of the video type in this case VGA-1.
2.) Next, we need to retrieve the configuration settings for creating a new resolution mode for example 1920×1080:
Well, I’ve just completed my first full week here at Droplet Computing – and I’m loving every moment.
There are so many things I could blog about right now, but I’m opting to do a blog post a week – mainly so I don’t fire everything off in a hailstorm only to dry up months later. But also because I’m drinking from the firehose (more Silicon Valley-speak) at the moment. Blogging isn’t really what I’m here for, and there’s other “real” work that must take a priority. I have a very healthy to-do list that needs focusing on – I’ve got a security guide to write for a government based deal, and partner enablement collateral to update and improve, as well as QA testing.
But anyway, I thought I would start off with discussing a pretty critical use-case that I’m already seeing out there with customers – and what my colleagues are seeing in terms of engagements with partners and their customers.
The blogpost titles need a bit of explanation.
The metaphor of the “rockpool” came from a customer who we need to buy a beer sometime (many beers!). I think it’s a wonderful metaphor for what is beginning to become a concrete fact. Many organizations have had programs to decommission Windows XP from their estate, but the rapidly retreating tide of Windows XP has left behind significant rockpools of Windows XP. Often Senior Management has little or no visibility of this fact. That isn’t down to not knowing their environments, but more to do with how impossible it is to keep a handle on the vast expanse of technologies at use in various parts of a sprawling organization. There’s also a kind of reluctance to admit to Senior Management that these rockpools of Windows XP exist. Ironically, these rockpools form a small percentage of the environment, but in a company of 25K, 50K, 75K or 100K that small percentage actually represents a significant thorn in the paw of IT strategy to get off legacy Windows, and onto Windows10.
This is also something our technology partners are seeing as well. Those partners have major projects to roll out new EUC projects that are based around the more “workspace” approach. Those of us who have been in the space for a while will know that the “one-portal-to-rule-them-all” concept is not new… But old ideas that once gained little traction in the past can come along a decade later and be successful. Bottom-line is there are often few really new innovative ideas in our industry, just concepts that have been knocking around for some time, whose time has now come. Of course, many of these new projects are geared up to automate logins and fulfilments for cloud-native applications, and the kind of apps found present in a Windows10 environment. Trouble is, that does not help any accounts department still using macros in Microsoft Excel 2010. It’s in this way that Droplet Computing complements (never ever, competes!) the Workspace model, which is really the future of EUC delivery for the conceivable future. IMHO.
So far, so legacy. The other big opportunity I’m seeing is on the horizon. Hopefully, not too distant – and that’s getting Droplet Computing on ChromeOS. I saw a news article recently how the education sector has been moving away significantly from Windows to adopt Chomebooks and Pixelbooks. There’s some (but not much) evidence of that happening in the public sector as authorities try to squeeze the very last from budgets that are already under pressure. The bottom line here is people who must upgrade (because of Windows XP and also Windows7), but don’t have the budget to do so will creatively find other solutions. Necessity is the Mother of virtue after all. Again, the problem here is getting legacy applications on to those devices, without having to resort to constructing a big VDI solution (load-balancers, DMZ navigation, storage, image build optimization etc., etc.) to run a couple of poxy but important legacy apps. I’ll blog more about Google’s Project Crostini in future, once I’ve got my hands dirty.
That leads me to “Shadow XP”. To be fair this is my feeble attempt at clickbait marketerism (did it work?!? ). We have all heard over the years about Shadow IT. The situation where developers and middle-managers whip out their credit card to dial-up resources from the public cloud. The reasons for that are well documented elsewhere, but the result is the same. It creates a kind of stealthy IT infrastructure that is not detectable on the Senior Management radar. Put simply, you don’t know, what you don’t know. And what you can’t see, doesn’t exist until it comes along and bites you on the bum. In the world of Shadow IT, this is usually a financial ceiling being triggered. In the world of Shadow XP that is an unexpected security breach caused by an operating system you believed had been expunged from your organization years ago. I accept that you, my friend, have absolutely not one drop of Shadow XP remaining in your environment, and like the Trojan’s you have nothing to fear about the wooden horse that appeared within the walls of your fortress this morning.
Dismiss Shadow XP as FUD and “Fake IT News” if you like, but it’s better to be safe than to be sorry after the fact…
As part of my work at Droplet Computing, I need to test our software on 4 different platforms (Windows, Apple Mac, Unbuntu and RHEL… and if I’m feeling frisky Chromebooks too!). As Apple Mac physical user, it makes sense to use virtual machines for this functional kind of testing (performance testing is another matter and has to be really done on physical systems). Being a long-standing vSphere user, it was logical to crank my home lab back up and use that gear than buy 3 laptops.
That was a pretty easy affair, but I was tussling with Unbuntu even with VMware Tools installed using Windows10 jump box to access the lab (which coincidentally resides in an enclosure in my garage. I’m using those horrid powerline adapters to get ethernet into there at the moment, needless to say, I hope to borrow a masonry drill in the next couple of days) so I can be wired directly to the wifi router that sits behind my telly.
So I thought I would give Unbuntu “Screen Sharing” a bash to see if that was any better than VMware Console. You can find Screen Sharing by simply typing “Sharing” and enabling it like so:
Trouble was I kept on getting refused/access either using the free VNC Viewer or the Apple Mac’s own Go To Server options.
Turns out Screen Sharing has its own encryption settings which are incompatible with these viewers. The easiest way to fix this is to use a dconf editor to turn off the encryption – and Bob’s your close relative…
1. Open a terminal and install dconf with:
sudo apt install dconf-editor
2. Run dconf-editor with:
dconf-editor
3. Browse to org -> gnome -> desktop -> remote-access and turn require-encryption to OFF
I did find VNC to be more network-friendly, but not as effective as a masonry drill… 🙂
Category: View/EUC |
Comments Off on Ubuntu Screen Sharing, Encryption Settings and a Masonary Drill
Well, you might have noticed my last couple of blog posts have been about this company, Droplet Computing.
I wondered if there was a bit of hint of a possible new direction for me? You’d not be wrong. I’m pleased to announce (sounds a bit grand, I’m not sure people are hanging on every one of my pronouncements!) that I’ve joined the company. I guess it’s like that old Victor Kiam ad from the 80s (70s!?!?) I liked the company so much, I decided to join. If you don’t get that referrence then you really are infuriatingly too young. Be gone with you! :-p
I first came across Droplet Computing more than a year ago when they came “out of stealth” (to use a bit of Silicon Valley-speak) at Cloud Field Day in Silicon Valley. I was immediately taken by their pluck and chutzpah. For me, it’s not just about the technology, although that plays an important part in the equation – but also the spirit of the company. What attracted me to Droplet Computing was how they were approaching the challenge of delivering applications in an entirely new, and novel way. In a crowded marketplace of server-based VDI, application sequencing and application virtualization – that is important. For a new company to stand out from the crowd and “move the needle” (more Valley-speak) you have to hit the target in three main areas.
(1) Offer the customer a net-new method of solving a problem, and net-new opportunities to take a new approach.
(2) Offer value-for-money to customers especially if you’re looking at unseating an incumbent or making sure that you win out in any vendor drag race (even more Valley speak)
(3) Offer performance improvements, whilst at the same reducing the complexity associated with server-side solutions that inevitable incurs multiple servers or virtual machines, fault-tolerant load-balancers, and high-availability solution to protect data center infrastructure.
If you been around for as long as I have – you will have heard the “any, any, any” pitch original espoused by Citrix, and then co-opted by VMware…
Droplet Computing supports Windows, Apple Mac, and Linux. This achieved by leveraging the client-side resource of the Windows PC, Apple Mac or Linux Workstation. It might not have escaped your attention but many modern laptops now have the kind of resources servers used have a decades ago. Those resources are vastly underutilized, so that platform offers great opportunities to more the workload from the MOST expensive place to run any computing activity (the data center) back to one of the most cost-effect places to run applications. There are other host devices on our radar, but for now, it’s important not to bite off more than we can chew. OR if you enjoy Valley-speak, not “boil the ocean”.
[Incidently, Droplet Computing is a UK start-up so hopefully, we will be short on Valley-speak, and long British classic understatement. 😉 ]
Here really isn’t the place for me to “pitch” Droplet Computing. All that remains to say is I’m really excited to be joining the company at such a critical point, and I know it’s going to be a great experience, mainly because I will have SO many different things to do. Initially, I will also be responsible for creating and reviewing technical documentation (Hello Grammarly!), be a liaison between the customers and development for product feedback and contributing to the overall product strategy. I’m excited to be working back in “vendorland” and moreover getting my hands dirty with technology at the coalface.
One of my first tasks will be to develop and deliver technical channel enablement program. That will mean getting to know all the partners really well, and really listening to their concerns and priorities, and help them deliver the technology to customers. I’m sure over time as we grow, my role with develop – in other words I will be asked to even more with the same amount time! :-p
Finally, I’d like to give a shout out to my former colleagues at SureSkills in Ireland. You guys are a great bunch of people and for me were a great illustration of what being in a team really means. I wish you every success in the future. 🙂
Category: Announcements |
Comments Off on Hello Droplet Computing
The last couple of weekends I’ve spent playing with Droplet Computing application containers solution. As ever getting “stick time” with any technology inevitably leads to thoughts about future functionality. I think the tricky thing for any new company is how far they want to carve out new features of their own, and run the risk of re-inventing a wheel that’s already been invented and in use already.
The dilemma though, is if you don’t spell out a management vision for a technology that’s essentially a platform, do you run the risk of looking like you’re lacking “vision”? The danger is you just want to be yet another vendor, with yet another ‘single pane of glass’ to be added alongside all the other ‘multiple pains of glass’ that customers have to toggle between. I guess the short part of that long-winded statement – what’s the best approach? To integrate or innovate?
I guess some Smart Alec would say the ideal thing would be to do both. Listen to customers and their needs and requirements and come up with solutions and functionality that addresses those needs. The only downside of this customer approach is customers can have a tendency to demand things, because they think they “should” be there. Only for the ISV to find out that this was tick-box exercise, and you have squandered precious development time for no reasonable benefit. It used to infuriate me when I suggested areas for improvement to VMware, only to be asked to explain and justify my thinking. Couldn’t they just see it was obvious! Of course, the reason I was asked to make my use case every time was to avoid the very situation I’ve just described. So featurism – the desire to add more features and options without a good use-case – is a crime I know I have been guilty of in the past. It’s crime I’m likely to continue to commit until I retire.
So, that gets me to the explanation of the title of this blogpost. Drip. Drip. It strikes me that the best kind of improvements to a new technology take little coding effort and improves functionality for all customers. A rapid series of quick updates is far easier to pivot, than massive undertakings that might take months to complete.
I think there’s another distinction to make with this type of approach. Do those drip-drip enhancements improve the users experience, or the administrator’s life and the deployment experience? For that reason, I’m going to separate them because at the end of the day no end-user ever patted on my back for well-administered systems.
User Experience:
Printing:
At the moment the only print support inside the container is for the native print driver that needs to be installed and configured by the administrator. Of course, customers may already have a license for some kind of universal print solution such as UniPrint. I think it would be great if Droplet Computing had some type of redistribution deal with a company like UniPrint. Ideally, this feature would retrieve the print configuration from the device OS, and then bubble those up into the container OS. This means the print configuration is ultimately managed by existing policies, profiles and/or scripts used to prepare the users environment to the device OS.
Unity-like Functionality:
If you’ve ever used something like VMware Fusion, you’ll have come across so-called “unity” style experience. This unity experience would essentially “hide” the Container environment as much as possible. Leaving just the application floating on the screen, and perhaps also creating shortcuts to Droplet Computing Apps contained inside the Droplet Computing Container. The end-user doesn’t need to interact with the “tiles” view in the main application.
But instead gains access to their application from an icon on their desktop. That said I’ve always been irritated about desktop icon clutter, where the entire desktop is covered with icons. Some kind of “Droplet Computing Apps” folder on the desktop that contains all the icons would be neat.
Content Redirection:
This is a Citrix feature that’s been around for sometimes. There are two types of “redirection”; one that takes from the device OS into the Container OS, and another that takes you out of the Container OS back to the Device OS. The former is 9 times out 10 the most common.
It’s very common for a user to find a document in a folder and want to open it with a double-click. Historically, in Windows that process been controlled with MIME file associations held in the registry. It can be tricky to get right. After all, generally file extensions tend to have no version information in them. For instance, the .PDF extension doesn’t help me decide if that application should run locally or within the Container OS. Nor does it help me in a situation where 9 times of 10, it should open locally, but in particular application scenarios it should open in the Container OS.
However, it is possible to create program logic that says for all Excel 2010 spreadsheets requiring Macros, to open in Excel 2010 in the Container OS, and for all spreadsheets created in Office 2016 open them Excel 2016. It would be possible to redirect these double clicks for the entire legacy XLS, XLM and XLT files to the Container OS. And to redirect all XLSX, XLSM, XLTX, and XLW to be redirected to a newer version of Excel running in the Device OS.
This kind of redirection also requires a method of passing the location of the file to the Container OS which I can used to retrieve the file. It’s one thing to call an .EXE using file extensions, and then another to then retrieve the data. It will generally require a communication channel and a file sharing protocol between the Device OS and Container OS. And then there’s the tricky issue of authenticating the users access to the file – would that use the Device OS credentials passed-through to the Container OS, or would it use the credentials of the Container OS?
The other type of redirection flows in the opposite direction. This is typically where a link to some multi-media format is found in a web page or embedded as a link inside an application running in the container. In most cases that YouTube link, MP3 or MP4 video would be best played by locally installed application within the domain of Device OS. I see this as being less of an issue because the action happens less frequently as a double-click to open a file – because it’s easier to create and encode a simple “multi-media” rule to redirect all such links back to the Device OS.
Administrator Experience:
Multi-Container Support:
Currently the Container OS being used is Windows XP, and I understand a Windows 7 Container OS build is on its way. Although I think the numbers of users needing both Container OS’s at the same time would be quite small, it would be nice if there was an easy way for administrators to give access two more than one container at time – and for users to have an easy way to toggle between them. This isn’t a biggie as I suspect the number of people doing this will limited, and the best practise will be to keep these images to a minimum. Right now, it’s up to the user to browse between various image files. A task that’s probably beyond the abilities of the average user.
Tile Management – Clipboard and Browsing for .EXE:
Right now, the administrator has to type in paths to the EXE’s held within the Container OS. I would like to see the ability to browse these paths, rather needing to type them. Together with that I’d like to see the ability to copy an existing “tile” and modifying to reduce this sort browsing function to a minimum. It’s perhaps not a huge issue – it maybe that many customers of Droplet Computing are using the Container OS to deliver a single strategic legacy application rather than multiple applications after all.
Ideally, I’d like to see some sort of programable or scriptable method of setting up this environment, even if it something as crude as copying down an .ini file. I’ve no idea of where the tile data that makes up granted applications is stored, but I understand it’s not held within the Droplet Computing Image. So, it must be held somewhere probably in an ASCII file of some description. I assume the tile configuration is held in the user’s profile – so if they roam around the organization they find their Droplet Computing Container configuration follows them.
Web-Browser Support:
Currently, the Windows XP version of the Container OS contains no web-browser. I think that’s intentional to reduce the attack surface that legacy browsers bring, as well as keeping the Droplet Computing Image slim. That does present challenges – such as downloading software into the Container OS. I was forced to do that with an external NAS device that wasn’t too painful, but it does mean sourcing every piece of software from the Device OS and leaving it on shared locations.
It makes things like setting up the Container OS for Dropbox, Google Drive and OneDrive trickier. A lot of the download pages for these sites just inspect the OS with the web-browser to detect the extension required.
[Note: It’s perhaps worth noting that some of these extensions no longer work with Windows XP. For instance, Dropbox no longer supports Window XP for their download that extends the Windows Explorer environment.]
In the end I installed the K-Meleon (http://kmeleonbrowser.org/) web-browser into the Container OS that then allowed me to get some of my online software providers and extensions.
Conclusions:
This is my third and final post on Droplet Computing, but I’m sure I will be back for more in future. It’s worth remembering that users care less about HOW they get their applications, more than they just get them. So, whether its local or remote VDI, Server-based computing in the form of Citrix or Microsoft RDS or a Droplet Computing Container – they really aren’t that bothered by the delivery mechanisms. I know WE are, but they aren’t. And this is a reality that is often forgotten.
Ease of use is critical, and any delivery mechanisms that “gets in the way” of the user being productive is a distraction by any other name. Any feature or absence of a feature that results in a help desk ticket needs to be addressed. And, ideally, the delivery mechanisms must offer improved performance, ease of use and value for money to be able to unseat the incumbents. The ideal should be all three – but if a company can deliver two of these in a solution they will get traction in the marketplace.
It’s interesting how application delivery in the form of Containers has come full-circle. The much-loathed PC is a resilient little computing platform, one that has endured and survived huge changes in the last 40-odd years. Dismiss it at your peril. For me it’s testament to the economies of scale that the PC has honed over the years. Despite the rise of tablets and phones, these devices have excelled at delivering simple single-use applications.
But when it comes to the more productive knowledge work, it’s still the Office Suite of applications they spend hours in front of writing reports, presentations and maintaining the dreaded spreadsheet. Alongside these business-critical end-user applications, is a whole raft of applications that customers want to carry on using well beyond the vendors perception of end-of-life. It’s for these reasons I think the “Container” approach as delivered by Droplet Computing has legs. I can see customers adopting not just a method of delivering legacy applications to any type of device (Windows, Mac, Linux) but also as an application delivery method for new applications too.
NOTE: Okay, I fess up that shameless nod to one of my favourite bands of the 80’s the indomitable “Echo and The Bunnymen” and their ‘hit’ “The Cutter”. What can I say I spent the later part of the 80s dressed in black moaning about how terrible life was… But hey, didn’t we all do that as teenagers?
This blogpost represents a walk thru the Droplet Computing container application and will attempt to describe the technology whilst keeping eyes focused on the practical side of life. I think I have one more Droplet Computing blogpost in me, and that post will be about where I think the next iteration of features should take them, and some of the challenges around achieving that. There are plenty of other things I want to learn about Droplet Computing, not least the process of authoring .droplet image files. So, whilst this blog does cover some very modest “administrator” like functions, it’s still very much focused on the “user experience” rather getting into much of the weeds of management.
Being a Mac user, I was supplied with the OS X version of Droplet – but a Windows and Linux version exists. The main thing to say is the functionality is the same regardless of device type, and the image file that makes up the environment in which applications work is portable between three support device types. Remember, Droplet Computing is container-based technology, it’s not a virtual machine or application virtualization. Apps are installed “as is” without any special packaging or sequencing process. And I think this will appeal to customers who do not have the time or resources for a dedicated team of packaging experts.
In the Apple Mac system images are moved from the location from which they were downloaded to this path:
These .droplet image files basically holds the Container OS files, I’m my case Windows XP together with any applications that have been pre-installed there. Droplet Computing provided me with the .zip file that contain both the core application and the image. When starting Droplet Computing for the first time you’re asked for the .droplet file, and if required it will move it to the images path. Currently, it’s Droplet Computing that provide the base .droplet file from which you can make multiple copies, and install software using the usual methods.
[Technical Bit: Early versions of Droplet Computing used a web-browser such as Google Chrome to provide the runtime environment. This approach has been dropped for the moment, as Google were pushing too many updates to Chrome to make this a reliable process that didn’t trigger endless regression testing. Droplet Computing has adopted a Chromium web-browser which they control to side step this issue. Needless to say, that the end-user never sees this hidden web-browser.]
Start and Load a Droplet Computing Container/Application
When Droplet Computing is loaded for the first time, the user has access to locate their image file, and there’s an option to control how much memory is assigned to the container, as well as set the location of their “Shared Folder”. This allows for the easy transfer of small files to and from the host and the Droplet Computing Container. Personally, I didn’t use this shared folder feature – opting instead to connect the Container OS to my home NAS server, and find my software there.
I’ve an old 13” MacBook Pro with 8GB of RAM and SSD drive which is circa 2012. So, it’s by no means a powerful machine by modern standards (it suits my needs perfectly fine until it stops working!). Clicking the big orange “Start Container” erm, starts the container…. That process took on my machine about 1min and 30seconds which I don’t think is too shabby considering the hardware involved, and the start-up time compares very favourably to a locally run virtual machine using VMware Fusion or Virtualbox.
Note: Currently this progress bar, really only shows that the container is loading, it doesn’t really show how far complete the process is.
To make my life easier, Droplet Computing has pre-set-up an application as part of my sample image that was notepad. A simple “launch” button option loads the application from within the container.
Note: Ordinary users can remove application tiles from this UI at will.
Shutting down an application is the same in the container as it would be in Windows XP. Clicking the red X in the top right-hand corner will close the app or using File, Exit. It’s the container OS’s job to check that files have been saved, and if the users chose to save some data, then it currently defaults to the user profile settings. In the world of a generic unmodified Windows XP installation, this is the “My Documents” folder. (Gee, remember when every folder in a Windows install had the word My appended to it for no apparent useful reason!). One thing that’s worth noting is that currently it is possible to shut down the container and the OS container, with open and unsaved files in the application using the power button. This does not suspend the Container OS, and when you start the container again, that data will be lost.
Note: The power button shutdown applications and the Container OS.
The Edit options allow you to view/change the applications configuration parameters, and these amount to simple variables such as name, .exe path, and description. Currently, there isn’t a browse option to locate the .exe, you have to type the path manually. Incidentally, this sort of browse functionally looks easier on paper than it is to implement in practice especially if you want to make sure the Container remains a secure environment.
You can upload an icon to act as friendly logo, this currently means browsing for .png, .jpeg, and .jpg files. This browsing is from within the Host OS, not the Container OS. So, I took a screen grab of the TextEdit application from the Apple Mac. I think in future Droplet Computing will inspect the .EXE and present icons from with it.
What can I say I like pretty icons!
Adding a New Application
The Droplet Computing Container is password protected, and adding a new application requires the administrator password. Droplet Computing sets a default password for both access to the Container. The important thing to say is this a password for Droplet Computing. It’s not the password for the Container OS admin account, nor is it the password for the local device. So this password sits independently of those and is designed to secure the access to the Droplet configuration such as adding/removing tiles, and opening up the ContainerOS to install new software.
Remember, Droplet Computing passed recent PEN Testing with flying colours, and so I don’t imagine this is an issue.
Once validated the container unlocks the options to add more applications for the user, revealing a + application tile from where you can add the parameters.
Note: My sample .droplet image was a bare-bones install of Windows XP, that didn’t even include MSPaint.exe! A situation that might bring a tear to the eye of old-timers out there who are fans of pixelated artwork. This configuration of the tiles view is user specific and is not saved to the .droplet file. It means the .droplet file can be replaced with a new image/build without upsetting the users configuration.Note: First time I tried this it didn’t work because I’d missed the r in Program! There is no clipboard buffer in the container so you cannot copy and paste from the device to these fields or copy them within the application. I assume the lack of a clipboard is a security decision. Copy and Paste is allowed between applications within the same container.
There’s currently no “browse” option here to navigate into the container, nor does Droplet Computing validate these paths to make sure they are correct. I knew that a legacy version of Microsoft Office 2010 had been pre-installed to the Container OS, so the way I validated the path was by doing the following:
I asked Droplet Computing to “Show Container”
Which reveals the administrator-only “spanner” icon, that allowed me to run Windows Explorer to check the path to winword.exe
Once I’d found the install directory, I was able to make a note of the path (without speech marks incidentally) and the .exe.
As you can see in the screengrab above, this administrator mode exposes aspects of the Container OS shell in the form of the Control Panel, Explorer, Task Manager, Command Prompt, PowerShell (if installed) and sending the Ctrl-Alt-Del keystroke to the Container OS.
When my work was done, I could see both Notepad and Microsoft Word.
There’s currently no method of copying a tile, to be able setup a new application by quickly modifying the path to the .EXE and the icon file. That said, this is a one-off operation that doesn’t take that long to configure. I notice there’s no way to drag tiles around, and they are sorted by application “name” field. So used a naming convention of Microsoft Word 2010, Microsoft Excel 2010 and so on to make sure they were grouped together.
Once multiple applications are available to the user they can switch back to the list of tiles, using the “Show Apps” option. This appears once the 1st application is loaded in my case, Microsoft Excel 2010
They can then load another application such as Microsoft Word 2010. The task bar shows the applications that currently open like so:
Installing new software to the Container OS
Adding new software to the Container OS involves a couple of steps:
From host locate the source software
Place on shared location in such as NAS Server
Download and Run installer within the Container OS
As example of doing this for Windows XP I used PuTTY. By far the easiest thing to do is to put the .exe or .MSI on a NAS server, and then map a network drive from the Container OS to the NAS Device. I did this by entering the administrative mode, and then running a Command Prompt
From there I was able to carry out a net view on the IP address of NAS server to see the shares on it:
And then a net use command to map a network drive:
From there I could use the copy command to copy the PuTTY.exe file to C:\Program Files. Once that was done, I was able to add PuTTY as tile to main view.
This work does beg the question on how networking is arranged inside the Container OS. In my case the Windows XP instance has a DHCP address from an internally supported IP range. So, it did not get an IP address from my home router. DNS and Routing queries get sent to an internal service which then piggy backs off the host networking. This allows for outbound access to my network, and the internet – but with no corresponding inbound access. This was just-enough networking to get me to my NAS server. As an aside, I notice Internet Explorer was not installed in my Windows XP image.
Conclusions:
From what I can see Droplet Computing has put together a robust release 1.0 product with PLENTY of scope for future features and functionality. They have developed their own in-house approach that solves the issue in a unique way. Personally, I think that’s no small achievement. It’s perhaps worth restating what those issue entail. As with server virtualization there’s always been that challenge of extending the lifetime of a legacy application beyond the life of the hardware and operating system for which it was first designed. Other attempts have been made using server-based computing (Citrix/MSFT-TS) and virtual desktop infrastructure (Horizon View and others). But these are have been datacenter focused solutions. I’ve championed both of these approaches in the past, and continued to do so – with the caveat that they place user-workloads in the most expensive computing space known to the Enterprise. So whilst VDI and SBS remain useful tools in a companies armoury, we have to acknowledge that much vaunted “death of the PC” and “Year of VDI” hasn’t happened. The PC remains the resilient and cost effective method of delivering a compute experience that hasn’t been eclipsed by the tablet or the dumb-terminal (I prefer to call them smart terminals, personally)
The bonding of hardware, operating system and an application has been ‘loosened’ in the last couple of decades. But they are still close coupled together. It’s only really containers on the server-side with technologies like Docker and Kubernetes that has really been a significant challenge and change in the way applications are developed. I think the time is right for that “container” approach to applied to desktops as well. Creating a mirror image of what’s happening in the space of server-side application or new paradigm for how companies might deliver applications in the future. The issue of legacy application support isn’t going away, because it has gone away for the last two decades (and a bit more) that I’ve been in the industry. So as companies see operating systems like WindowXP and Windows7 fall off the support cliff, I suspect that the same situation will be faced with Windows8/10. And there’s more. If I thought technologies like Droplet Computing were just about legacy applications, I’d be less excited by this space. The fact is I think many companies once they harness the power of container technology for legacy applications, will be thinking about using at as method of deploying new applications.
