computer technology

Copy vs Dropbox UPDATED: iOS and Linux

gregladen — Sat, 19 Apr 2014 11:33:52 +0000

Copy vs Dropbox UPDATED: iOS and Linux

UPDATE: Linux Install.

Installing Copy on Linux was pretty easy. You go to the web page, download a tarball, upack it, then inside the tarball figure out the folder that matches your OS (i.e., 32 vs 64 bit) and go into that folder. Then run the Agent. That may, if you are good, put a thingie on your notification area. Click on that and then sign in and install and stuff, that's it.

There are two pages you might find useful, one for Ubuntu the other for Copy more generally if needed.

Notably, the install on Linux was easier for Copy than for Dropbox. Dropbox install LOOKS easy but never goes as planned, in my (extensive) experience with it.

Copy is a new cloud storage service that may be a serious competitor to Drobbox. I just installed it and I like it.

Dropbox gives 2 Gigabytes for free, 100 Gigabytes for 9.99 a month, 200 Gigabytes for 19.99 a month, and 500 Gigabytes for 49.99 a month.

Copy gives 15 Gigabytes for free, 250 Gigabytes for $10.00 a month, and 500 Gigabytes for 15.00 a month (cheaper if you pay by the year).

I know for a fact that Dropbox works well with Linux and Mac and I assume Windows. Copy claims to be compatible and well integrated with all of these system. I've not thoroughly tested Copy yet, but they do seem to work differently.

To make Copy work on my Mac, I installed the app from the menu by downloading the image file and doing the drag and drop thingie. I then ran the application and after a few short steps I had a new folder on my computer called "Copy." It was place within my home directory, though I had the option of using a different folder. The installation program conveniently (or obnoxiously depending on how well you keep your lawn trimmed) placed a short cut on the shortcut bar in "finder."

At a couple of times during the process of signing up and installing I was given the option to just move everything from my computer, or from "another cloud storage device" to Copy, which I chose not to do because that would have certainly involved upgrading to a paid account; I wanted to try this out with the free storage first, though I'm not adverse to buying storage if I need it, especially at rates so much lower than Dropbox.

The first thing I did was to attempt to drag and drop a folder that has several files in it into Copy. The folder held a handful of subdirectories, several hundred files, and was in all about 1.2 gigabytes in size. Within a few seconds upload started. Seemed to be about on par with Dropbox, but I did not take any measurements for comparison. Copy allows local syncing, which of course I've not tested yet.

It is difficult to recommend for or against Copy until it has been out a while longer, but at the moment it seems to be essentially the same as Dropbox but cheaper. Will Dropbox lower its price? Will Copy be amazing like Dropbox is? Will this work just as well on my Linux machine?

Tune in next week for another installment of .... "Copy vs. Drobox"

____________
UPDATE: I've installed the iPad app. Installed cleanly, much crisper, easier to use, better laid out than Dropbox, a total win. And it functions fine.

Tomorrow PM I plan to install Copy on my Linux laptop. Later in the week, on the Linux workstation.

gregladen Sat, 04/19/2014 - 07:33

Bash 4.0 = **, $>>, and associative arrays

gregladen — Thu, 26 Feb 2009 08:41:04 +0000

Bash 4.0 = **, $>>, and associative arrays

Bash 4.0 includes associative arrays, a superwildcard called "**" and a new redirection operator. Details are here.

gregladen Thu, 02/26/2009 - 03:41

Tags

Technology

computer technology

Technology

Some of my favorite new features:

There is a new shell option: `dirspell'. When enabled, the filename completion code performs spelling correction on directory names during completion.

My sepllnig skucs

The parser now understands `|&' as a synonym for `2>&1 |', which redirects the standard error for a command through a pipe.

For some reason I always forget the correct order of that string of characters.

If a command is not found, the shell attempts to execute a shell function named 'command_not_found_handle', supplying the command words as the function arguments.

Very cool from a user interface perspective. Now I can write my own snarky error messages if the user doesn't have the prereqs installed.

Bash 4.0. It's like a whole new world.

Most of it looks very good, but I have admit when I see 'associative arrays' mentioned, I start to worry if they are getting a bit close to the line of what is better left for the likes of Perl or Python. Suppose it can't do much harm (you can always just not use it...). I prefer to keep shell scripts simple and hand over to Perl, etc., if I want something with more logic, etc.

Automatic spelling correction trains your fingers to spell badly. It's much harder to untrain fingers that have been mis-trained than to train right in the first place.

Interesting philosophical divergences here. Heraclides: I find it interesting that the array is possibly on the other side of the Script River Styx. I'm not disagreeing (or agreeing) with you, just bringing it up. It would be like this: A shell scripting lanaguge would be going too far if ... then fill in the blank (a priori) if certain things are implemented. Structurally, a SSL should not be object oriented. With respect to text manipulation a SSL should not have regular expressions fully implemented. With respect to variables, a SSL should not have arrays. With respect to file manipulatoi, a SSL should not have complex built in search functions and so on.

Were I to agree with you, I'd say that the way to implement arrays would be the same way one implements searching or other text manipulation, with a set of stand alone functions such as tr, grep, awk, and so on. We would want an "array" program.

Independant programs have all sorts of upsides, including that they follow the basic Unix Philosophy. The down side is that they would be independent threads. We have somehow come to fetishize process number as a number to minimize (rather than redesign our systems so that process number increase is efficient and non undesirable)

One thing I would say is that arrays may not be making bash more complicated. They may be making bash less complicated.

Nathan: I understand why you say what you say, but it is a little like saying "Wheel chairs are not helping the paraplegics. If they didn't use wheel chairs they'd be better off." Aspellia is a perfectly valid disability.

Too short on time to think properly, but if you go way back, scripting was literally just commands in a file. Add to this a means to pass external variables and replace them and you have a reusable command stream. In many ways this should really be the essence of scripts still.

As a rule of thumb I find it wise to move "up" to the next level of programming if there is any risk of the current level getting more complex than it is well suited to. This requires forethought, which isn't a perfect art... The general cut-offs are vague, of course, but the point is that some things that are quite clumsy in, say, bash, are trivial in a language suited to it and that you're better off to move "up" earlier rather than later, so that the code is smaller (less migration work).

Its not about "complexity", it's about "appropriate tools".

My usual rough rule is that scripting should be limited to commands, variables, and dead-simple logic. If you start looking at working around a lack of data structures, more complex logic, numerical work, etc., you are (well and truly) ready to move up to Perl or whatever.

A lot can be done with grep, cut, paste, etc., if you use a file as your "data structure" and for some tasks that's appropriate, but a character of these is that their logic is largely linear.

This "moving up" theme also applies to Perl: Perl (5) really isn't that good for writing anything too large in my experience! (Been there a few too many times...)

Reminds me that one of those things I'm "supposed" to do before a keel over is write my own programming language...

Young Heraclides: Scripting was originally commands on punch cards!!!!

But yes, I see your points.