Pastebins are incredibly useful. But most of the public pastebins are not suitable for sharing within a company (think code fragments, log messages etc.) and most private pastebins are either ugly (except hastebin!), hard to setup/maintain and usually forced to be behind the firewall (for security).
I got my invite for the Bitcasa beta last week but only got around to installing it yesterday. I’ve only used it sparingly thus far. If you are in a hurry, here’s the TL;DR version:
- Users might find the “cloudify” model confusing
- Built using osxfuse (not to be confused with MacFUSE) and Qt
- Infinite storage sounds too good to be true. What’s the catch?
- Building trust with users will take time
Cloudification and Confusion
When a folder is Cloudified, a corresponding virtual folder is created on the Bitcasa server and the contents of your local folder are copied up to the server. When Connected to the Bitcasa server, any changes or additions to the folder will live on the server. When not Connected to the Bitcasa server, any changes or addition to the folder will live locally.
Just think about that for a second. The “cloudify” model sounds great in principle, but it does add a lot of complexity in terms of how users interact with the system. For instance, when I’m offline and make changes to one of my cloudified folders, that change happens presumably locally. I would assume that when I come back online, these changes are synced back to Bitcasa ala Dropbox. But what if I accidentally disconnect a folder, make some changes and then reconnect — per the FAQ, the changes made locally won’t be synced.
The consumer cloud storage is fairly mature right now and one can learn a lot by looking at how people respond to other systems. This thread on Quora is particularly insightful: again and again, simplicity comes up as one of the key reasons behind Dropbox’s success.
My prediction is that Bitcasa’s cloudify feature will be leveraged primarily by power users and the rest would end up using the default Bitcasa folder, Dropbox style.
Nuts and Bolts
Bitcasa seems to be built primarily using Qt. This isn’t a surprise: Qt is a mature, open source and cross-platform library.
$ otool -L Bitcasa Bitcasa: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5) /usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current version 44.0.0) @executable_path/../Frameworks/libmacfuse_i64.2.dylib (compatibility version 10.0.0, current version 2.0.0) /usr/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current version 44.0.0) /System/Library/Frameworks/CoreServices.framework/Versions/A/CoreServices (compatibility version 1.0.0, current version 53.0.0) @executable_path/../Frameworks/QtWebKit.framework/Versions/4/QtWebKit (compatibility version 4.7.0, current version 4.7.4) @executable_path/../Frameworks/QtXml.framework/Versions/4/QtXml (compatibility version 4.7.0, current version 4.7.4) @executable_path/../Frameworks/QtGui.framework/Versions/4/QtGui (compatibility version 4.7.0, current version 4.7.4) @executable_path/../Frameworks/QtNetwork.framework/Versions/4/QtNetwork (compatibility version 4.7.0, current version 4.7.4) @executable_path/../Frameworks/QtCore.framework/Versions/4/QtCore (compatibility version 4.7.0, current version 4.7.4) /usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 52.0.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1105.0.0) $ mount Sample Videos on /Users/diwaker/Bitcasa/Sample Videos (osxfusefs, nodev, nosuid, synchronous, mounted by diwaker) TryBitcasa on /Users/diwaker/TryBitcasa (osxfusefs, nodev, nosuid, synchronous, mounted by diwaker) TryBitcasaDedup on /Users/diwaker/TryBitcasaDedup (osxfusefs, nodev, nosuid, synchronous, mounted by diwaker)
Note further that Bitcasa represents “connected” folders as mount points over the existing folders. This is why when you disconnect a folder and make changes, they won’t propagate to Bitcasa’s copy of that folder. They are using osxfuse which implies that Bitcasa is intercepting file system calls; this is in contrast to Dropbox-like systems that detect changes to the local filesystem asynchronously. I haven’t compared fine-grained read/write performance just yet.
Here’s a snapshot of the Bitcasa Folders UI:
Bitcasa also does some deduplication. Uploading 100MB of mostly random data took around 4 minutes on a pretty fat pipe which isnt’ bad at all. Copying that data back out took just as long, if not longer. A copy of the same folder took less than 10 seconds to cloudify!
Much has been said about Bitcasa’s security. However, most of the articles are concerned with a specific dimension of security: encryption.
A detailed discussion of Bitcasa’s security in general and encryption, in particular, deserves a post of its own. For now, suffice to say that even after several years of user experience, Dropbox still hit some pretty nasty security snafus in 2011. Like a lot of you, I’m very concerned about security, especially with a service that is offering me infinite storage for free! It takes time to build trust with your users — there’s no short cut.
Overall, Bitcasa is definitely interesting. Dropbox was almost beginning to monopolize the consumer cloud storage market, so some good competition will hopefully benefit the end users in the long run.
Here’s the situation: say you are at a friend’s place and as all responsible hosts, they have a password protected wifi network. Your friend is busy (or unavailable) so you can’t ask her for the password. Of course, you are known to not give up easily. You look around and realize: aha! someone else over there on the couch is busy with their laptop, so they must know the password. Unfortunately, they don’t. But the password must be somewhere on their laptop, since they are connected after all. So how do you find it?
OK, that probably sounds contrived. But the truth is that I did have the need to extract the wifi password from my wife’s laptop earlier today and thought I’d share the (pretty simple) process.
Step one: open keychain access
Step two: search for the network name (SSID)
Step three: check ‘Show password’ (you may need to enter your password first since this required Administrator privileges).
For years, free/libre/open source software (henceforth referred to as FLOSS) have proclaimed, year after year, how that year is the year of Linux, or the year that open source will become mainstream, or the year that open source will finally take off etc. But it never has, at least traditionally speaking. Linux based desktops haven’t penetrated either the enterprise or consumer markets; with a few notable exceptions (Apache httpd, for instance), most FLOSS products — be it office software like OpenOffice, multimedia software such as Gimp or Inkscape — remain popular with economically insignificant niches. And yet, this year, more than ever before, open source forges ahead with its silent victories.
Consider the following shifts:
- all the top brands of the day — Apple, Google, Facebook, Twitter, Amazon — they ALLstand tall on the shoulders of FLOSS giants.
- Contributing software back to the open source community is becoming increasingly common, even expected. Take a look at the GitHub repositories of Twitter and Facebook, or the various Google projects. In fact, when screening engineering candidates, I often look for and encourage people to talk about their open source contributions.
- Most of the activity around “big data” and “cloud computing” is being driven in large part by FLOSS, whether it is the Hadoop-powered ecosystem or the Xen/Linux powered Amazon Web Services.
- Given the current smartphone landscape, it is highly likely that Android will become ubiquitous on tablet devices and a variety of consumer smart phones. Already, Android has more search mindshare than Linux, despite the fact that Linux is part of the Android stack.
- If you start a software company today, I would bet that you will find yourself bootstrapping almost entirely using open source software. The entire development process — from the GCC compiler toolchain, to the build systems, to the scripting languages, to the version control systems, to the code review systems, to the continuous integration systems — everything is dominated by FLOSS products. Good bug trackers and enterprise Wikis are the last bastions but it is just a matter of time.
I’ve had a chance to see the enterprise software market up close and increasingly find more and more open source everywhere I look. FLOSS has not arrived, it has taken over.
It is no secret that I’m an open source evangelist and so when it was time to set up internal infrastructure at work, naturally the first order of business was to evaluate the various OSS projects out there — everything from wikis, bug trackers, source control, code review and project management. Running Ubuntu LTS (10.04) on all of our servers was a no-brainer and there were plenty of excellent options for most everything else as well (a follow-up post on our final choices later). The Linux ecosystem is fabulous for most of the infrastructure needs of a startup, but I learnt the hard way that there are still some areas where Linux needs a lot of work before it can become competitive with proprietary, non-Linux solutions.
Centralized account management (users and groups) and authentication is critical component in any IT deployment, no matter the size. Even for a small startup, creating users/groups repeatedly for each new server, separate authentication mechanisms for each new service is simply not scalable. That is precisely why Active Directory is so ubiquitous at enterprises.
LDAP was the obvious solution in Linux-land and I figured it would be trivial to setup an OpenLDAP server that can manage user/group information for us. It would also be the single authentication source for all servers and services. I was so wrong.
After struggling with OpenLDAP for several painful hours, I gave up — the documentation is fragmented, Google doesn’t help much and personally I think the LDAP creators had never heard of “usability” when designing it. The seemingly simple task of creating some new users and groups involved several black-magic incantations of the LDAP command line tools. Getting servers to authenticate against the resulting directory was even harder.
Just as I was about to throw in the towel and setup an AD instance in-house, I stumbled upon the 389 Directory Server (now known as the Fedora Directory Server). With a new found hope, I set about installing it on Ubuntu and hit another roadblock — there are no up-to-date packages of FDS for Ubuntu. Reluctantly, I setup a Fedora instance (the only one so far) and installed FDS. Thankfully, Red Hat has put together really comprehensive documentation and guides for the Directory Server, which was invaluable.
From there on, it was mostly downhill (only a few minor hiccups). Finally we have a nice GUI to manage users and groups, and all servers/services authenticate against a single Directory Server. But the journey was unnecessarily painful. Here’s what I’d like to see:
- Up-to-date packages of FDS for Ubuntu. Sane defaults and functionality out-of-the-box
- Ready to consume documentation on how to integrate LDAP with various web applications, Linux distros etc (I’ll put together some of this soon)
- More awareness — I should have found FDS a lot sooner than I did, but it is certainly not very well marketed
- Single sign on: This is a whole different beast
At my previous company, we had a Cisco VPN solution. There were plenty of Cisco compatible VPN clients on Windows and Mac. In fairness, it was relatively easy to get vpnc working on Ubuntu as well. In fact, with Network Manager, you can manage your VPN connections using a simple and intuitive UI. But the setup was not very reliable and my connections would get dropped relatively frequently. It was impossible to have a long-running VPN session without disruption. I’m not sure if the problem was with the Cisco hardware or the Ubuntu vpnc client; I did see similar issues with the built-in VPN client on Mac OS X.
But at least VPN on Linux works. I can’t say the same about other remote access mechanisms, in particular IPSec and L2TP over IPSec. It took me some time to figure out which package to use (Strongswan, Openswan, iked etc etc); another couple of hours to get the Openswan configuration just right; several hours of struggling to automatically setup DNS lookups when using the IPSec connection (gave up and ended up using entries in /etc/hosts!). There is no UI in Network Manager to manage IPSec connections either. Strongswan does have a NM plugin, but that only works for IKEv2 (certificate based authentication), while I had to use IKEv1 (shared key based authentication).
At the end of the day, I do have a working IPSec tunnel and it is definitely more reliable than the Cisco VPN (been up for more than 2 days without disruption). But all this can and should become a lot more seamless.
These are a few areas where Linux failed me in setting up the infrastructure for a startup; it shines most everywhere else. Hopefully these last few kinks will get ironed out soon.