40 ms·

> At best this is an unfortunate "pilot error" and at worst this is a sign of incompetence. I'm not sure knowledge of an obscure Windows-specific drag and drop

by jiayo 14y ago

> At best this is an unfortunate "pilot error" and at worst this is a sign of incompetence. I'm not sure knowledge of an obscure Windows-specific drag and drop quirk should be a requirement for using Dropbox safely. > you do have separate system and data drives on your machines, right? I'm not sure use of a partition table editor should be a requirement for using Dropbox safely. Most people use the operating system that came installed on their PC as-is. > daily system and data backups to external media Dropbox makes the following claims on their website: "Your files are safe" "Even if you accidentally spill a latte on your laptop, have no fear! You can relax knowing that Dropbox always has you covered, and none of your stuff will ever be lost." "Even if your computer has a meltdown, your stuff is always safe in Dropbox and can be restored in a snap. Dropbox is like a time machine that lets you undo mistakes and even undelete files you accidentally trash. " I think it's completely reasonable to expect Dropbox to be a reliable backup solution as-is.

robomartin 14y ago
OK, let's take a look at your points: > I'm not sure knowledge of an obscure Windows-specific drag and drop quirk should be a requirement for using Dropbox safely. Not a "obscure Windows-specific drag and drop quirk". This is how the OS works. If you are a developer you need to know your OS. > I'm not sure use of a partition table editor should be a requirement for using Dropbox safely. It isn't, but if you are smart you'll take my advice and go implement it right now. > Most people use the operating system that came installed on their PC as-is. Developers are not "most people" and should certainly not behave as such. Your data is the only thing that is important. Your work product. Investing in separate drivers (not partitions, separate physical drives) on every development machine is invaluable. And, backing-them up with disk images on a daily basis is just as important. If the system drive goes out your data is intact. If the data drive goes out the system is intact. Recovery is an academic exercise. If both drives go out it is a little more of a pain in the ass, but at most you'll loose a day's worth of work, not a lifetime or a whole year's worth. > Dropbox makes the following claims on their website: Pardon the raw-ness: I don't give a shit of what anyone says or claims about any service. Neither should you or any serious developer. You, and only you are responsible for the safety of your data. You HAVE TO assume failures, not just locally, but also remotely. Hardware fails. Software fucks-up. Even if Dropbox (or name your service) guaranteed 500% redundancy I'd still have my own backups. It would be irresponsible to do otherwise. Then there's the practicality of the whole thing. The machine I am using to type this has the following physical drives (not partitions on a single drive, these are independent pieces of hardware in the chassis): Internal backup drive External backup drive (USB) System drive Data Library Development The last four are backed-up daily with incremental backups to both backup drives. The data drive alone has over 300GB of data right now. The Library and Development drives are about 150GB of data each. That's 600GB of valuable work in three drives probably representing millions of dollars of work-product and value. So, Dropbox is backup, right? Well, uploading 600GB to your "backup" would take somewhere in the order of 100 days of continuous 24/7 upload with my current DSL connection (~600Kbps upload speed). That's a third of a year. Nope, it's not backup.
- icambron 14y ago
  The OP never said their colleague was a developer. And Dropbox isn't specifically marketed towards developers. When you develop software aimed at the general public, which Dropbox does, you do have to worry about most people. And regardless of how irresponsible the user was or how knowledgable they were, it's still a screw-up on Dropbox's part. "You shouldn't have relied on this service" != "this service isn't doing anything wrong when it breaks." You should lock your doors at night, but the robber who just saunters in to steal your stuff is still a badguy. Also, since this is HN, let's talk about how we build software, as in, put yourself in the position of the Dropbox developer and instead of just the end user. Most of us, I imagine, build software used by non-developers. I hope your attitude towards these things isn't "fuck it, if they were a competent developer like me, they'd have known better", and instead, "damn, I really need to go bulletproof my software so it doesn't delete people's data like that." In that context, there's plenty to criticize and learn from in Dropbox's mistakes here. Edit: grammar
  - jacquesm 14y ago
    > And Dropbox isn't specifically marketed towards developers. Dropbox for teams is specifically marketed towards businesses.
  - robomartin 14y ago
    That's wonderful, except that this thread is about a developer being added and then removed from teams while working at a startup and this triggering data loss. This isn't about grandma storing her pictures of the kids. Grandma ain't gonna join "teams". That's for developers. Did you read the article this thread is about? You could, of course, take the approach that Dropbox should be there to protect everyone from themselves. Fair enough. I have, in other comments, given the example of my own usage, which guarantees that no data can ever be lost by Dropbox. It's simple and it works. I've been constructive here. If you implement my approach you should be safe. Still, don't take my word for it, implement and verify. That's engineering. I have also, in another comment, posted about a feature request that might help insure that this does not happen to casual users: Dropbox, if possible, should modify their client software such that files can only be copied in and out of Dropbox folders and never moved. For the adventurous, they could make this an option that is set by default but can be disabled. A huge warning about the potential for data loss would accompany the act of disabling this feature. In that regard, I've been as constructive as one could be in this thread. In the end, you can't protect everyone from their own mistakes, incompetence or carelessness. And, no, I don't think everyone is stupid. We all make mistakes. I had a very painful data loss event in college, so I learned my lesson very early on. I have never lost valuable data since. I am not going to blame a service for something that is the responsibility of the user. Engineers, in particular, have no excuse for data loss. A 2TB external hard drive is about $100. Please. You could also argue that business users in this day and age cannot be computer illiterate. Being "literate" does not mean being able to open a browser and push a mouse around. If a business owner is not capable beyond that they ought to be smart enough to hire a qualified IT service to help them manage and secure their systems. If they do have in-house IT then data backup and security ought to be one of their top functions. Private users are a little bit of a different story. There's a huge chunk of them that, today, could loose every digital asset they own and have no way to ever recover it. This is still a business opportunity for a startup somewhere. Services like Carbonite and others abound: https://www.google.com/search?q=online+backup https://www.google.com/search?q=online+backup At one point you have to point your finger at the data's owner and say "You, and only you, are responsible for your data". I can guarantee you that if you read the TOS of any online data backup service there's a clause there about the potential for accidental loss. There is no way in hell that an attorney would advise anyone not to have that clause there. And, no matter how good of an engineer you might be, there is no way you would risk it all to offer some kind of an absolute no-loss guarantee. The test is simple: Would you, personally, be willing to be sued into absolute poverty for issuing that guarantee? Probably not. So, we can sit here in righteous indignation for me daring to suggest that users are ultimately responsible for their data and lie to each other or accept the reality that the reality, developer or not. Down-vote away, but I am right. If we go back to the very original article that this thread is about, the programmer who joined the startup team seems to have not had any explicitly-created local backup of the data in question. He got lucky. He said "The client left all the files on my machines, so I didn’t lose any personal data - it wasn’t a catastrophic failure.". That's luck, that is not planning. So, he did OK, he talks about having to re-upload some 2GB of data to a new account. He was off and running after that. I can bet you that, unless he isn't very smart, he now has private local backup of his data in case something like this happens again. And that's the right way to handle it. Don't trust anyone with your data unless you can independently verify the ruggedness and reliability of their solution. Period. If you did not do that, engineer or "civilian", total data loss is on you, not the service.

by jiayo 14y ago

robomartin 14y ago

OK, let's take a look at your points: > I'm not sure knowledge of an obscure Windows-specific drag and drop quirk should be a requirement for using Dropbox safely. Not a "obscure Windows-specific drag and drop quirk". This is how the OS works. If you are a developer you need to know your OS. > I'm not sure use of a partition table editor should be a requirement for using Dropbox safely. It isn't, but if you are smart you'll take my advice and go implement it right now. > Most people use the operating system that came installed on their PC as-is. Developers are not "most people" and should certainly not behave as such. Your data is the only thing that is important. Your work product. Investing in separate drivers (not partitions, separate physical drives) on every development machine is invaluable. And, backing-them up with disk images on a daily basis is just as important. If the system drive goes out your data is intact. If the data drive goes out the system is intact. Recovery is an academic exercise. If both drives go out it is a little more of a pain in the ass, but at most you'll loose a day's worth of work, not a lifetime or a whole year's worth. > Dropbox makes the following claims on their website: Pardon the raw-ness: I don't give a shit of what anyone says or claims about any service. Neither should you or any serious developer. You, and only you are responsible for the safety of your data. You HAVE TO assume failures, not just locally, but also remotely. Hardware fails. Software fucks-up. Even if Dropbox (or name your service) guaranteed 500% redundancy I'd still have my own backups. It would be irresponsible to do otherwise. Then there's the practicality of the whole thing. The machine I am using to type this has the following physical drives (not partitions on a single drive, these are independent pieces of hardware in the chassis): Internal backup drive External backup drive (USB) System drive Data Library Development The last four are backed-up daily with incremental backups to both backup drives. The data drive alone has over 300GB of data right now. The Library and Development drives are about 150GB of data each. That's 600GB of valuable work in three drives probably representing millions of dollars of work-product and value. So, Dropbox is backup, right? Well, uploading 600GB to your "backup" would take somewhere in the order of 100 days of continuous 24/7 upload with my current DSL connection (~600Kbps upload speed). That's a third of a year. Nope, it's not backup.

icambron 14y ago
The OP never said their colleague was a developer. And Dropbox isn't specifically marketed towards developers. When you develop software aimed at the general public, which Dropbox does, you do have to worry about most people. And regardless of how irresponsible the user was or how knowledgable they were, it's still a screw-up on Dropbox's part. "You shouldn't have relied on this service" != "this service isn't doing anything wrong when it breaks." You should lock your doors at night, but the robber who just saunters in to steal your stuff is still a badguy. Also, since this is HN, let's talk about how we build software, as in, put yourself in the position of the Dropbox developer and instead of just the end user. Most of us, I imagine, build software used by non-developers. I hope your attitude towards these things isn't "fuck it, if they were a competent developer like me, they'd have known better", and instead, "damn, I really need to go bulletproof my software so it doesn't delete people's data like that." In that context, there's plenty to criticize and learn from in Dropbox's mistakes here. Edit: grammar
- jacquesm 14y ago
  > And Dropbox isn't specifically marketed towards developers. Dropbox for teams is specifically marketed towards businesses.
- robomartin 14y ago
  That's wonderful, except that this thread is about a developer being added and then removed from teams while working at a startup and this triggering data loss. This isn't about grandma storing her pictures of the kids. Grandma ain't gonna join "teams". That's for developers. Did you read the article this thread is about? You could, of course, take the approach that Dropbox should be there to protect everyone from themselves. Fair enough. I have, in other comments, given the example of my own usage, which guarantees that no data can ever be lost by Dropbox. It's simple and it works. I've been constructive here. If you implement my approach you should be safe. Still, don't take my word for it, implement and verify. That's engineering. I have also, in another comment, posted about a feature request that might help insure that this does not happen to casual users: Dropbox, if possible, should modify their client software such that files can only be copied in and out of Dropbox folders and never moved. For the adventurous, they could make this an option that is set by default but can be disabled. A huge warning about the potential for data loss would accompany the act of disabling this feature. In that regard, I've been as constructive as one could be in this thread. In the end, you can't protect everyone from their own mistakes, incompetence or carelessness. And, no, I don't think everyone is stupid. We all make mistakes. I had a very painful data loss event in college, so I learned my lesson very early on. I have never lost valuable data since. I am not going to blame a service for something that is the responsibility of the user. Engineers, in particular, have no excuse for data loss. A 2TB external hard drive is about $100. Please. You could also argue that business users in this day and age cannot be computer illiterate. Being "literate" does not mean being able to open a browser and push a mouse around. If a business owner is not capable beyond that they ought to be smart enough to hire a qualified IT service to help them manage and secure their systems. If they do have in-house IT then data backup and security ought to be one of their top functions. Private users are a little bit of a different story. There's a huge chunk of them that, today, could loose every digital asset they own and have no way to ever recover it. This is still a business opportunity for a startup somewhere. Services like Carbonite and others abound: https://www.google.com/search?q=online+backup https://www.google.com/search?q=online+backup At one point you have to point your finger at the data's owner and say "You, and only you, are responsible for your data". I can guarantee you that if you read the TOS of any online data backup service there's a clause there about the potential for accidental loss. There is no way in hell that an attorney would advise anyone not to have that clause there. And, no matter how good of an engineer you might be, there is no way you would risk it all to offer some kind of an absolute no-loss guarantee. The test is simple: Would you, personally, be willing to be sued into absolute poverty for issuing that guarantee? Probably not. So, we can sit here in righteous indignation for me daring to suggest that users are ultimately responsible for their data and lie to each other or accept the reality that the reality, developer or not. Down-vote away, but I am right. If we go back to the very original article that this thread is about, the programmer who joined the startup team seems to have not had any explicitly-created local backup of the data in question. He got lucky. He said "The client left all the files on my machines, so I didn’t lose any personal data - it wasn’t a catastrophic failure.". That's luck, that is not planning. So, he did OK, he talks about having to re-upload some 2GB of data to a new account. He was off and running after that. I can bet you that, unless he isn't very smart, he now has private local backup of his data in case something like this happens again. And that's the right way to handle it. Don't trust anyone with your data unless you can independently verify the ruggedness and reliability of their solution. Period. If you did not do that, engineer or "civilian", total data loss is on you, not the service.