Hacker News Reader

Comment by Xylemon | Hacker News Reader

Something like this with Steam happened to my friend not too long ago. It was very saddening because he literally lost years of files (including personal projects) and salvaged what he could. That was with the Steam Beta and I caught Steam doing this myself (after he told me what happened). I was lucky to stop the script and switched out of the beta. At the time he reported this to Valve themselves and said they were "investigating the issue and knew of it". Seems to still be here, sigh.

I know the morale here is keep your files backed up but come on, this is a ridiculous issue Valve still hasn't fixed.

View on HN

That is quite frustrating, and consumer vendors should be mindful of creating life-changing experiences.

Also: backups. I know it sounds cliche, but look, if it has a mechanical hard drive, the manufacturer could have slightly mis-calibrated one of the mechanical assemblies, and this could have happened because the nature of digital storage is that it is essentially ephemeral.

Protect yourself from things outside your control. You don't need the most sophisticated solution, just an external usb drive.

Or if you're on a Mac you don't even need any extra hardware.

Just ARQ and an AWS Account [or google drive, or dreamobjects, or SFTP, or...].

Your backup is client side encrypted and completely painless. Take half an hour to set it up and then just forget it till it saves your ass.

Not affiliated, just a fan: http://www.haystacksoftware.com/arq/

But if that external usb drive is mounted at the time (as in the case of the user this thread is about), then all data on that drive will be deleted.

For this reason, the recommened way to use things like rsnapshot is to have your backup directories owned by root and with permissions masked to something like rwxr--r--. If you then want to read your backups easily, you do things like mount it under NFS as read-only.

A (RAID6) fileserver running ZFS with filesystem-level snapshotting. It's really, really good.

Btrfs snapshots, and then cp --reflink from the snapshot to the current tree whatever files or directories are missing; i.e. no need to rollback to a snapshot.

I think Valve should be sued over this, and lose. Sure, there will be clauses in their EULA stating that they aren't liable, but morally, those clauses should not be valid in any licensing agreement. Their commercial software caused damage to people, and they should pay through the nose for it.

There are several problems with your ideas. The most important one is that programmers only call themselves engineers until it comes time to take legal responsibility for their work; then suddenly they're artists creating works for hire. Programmers have worked very hard through the years to create the current liability-free environment; people die because of health care programming bugs, pilots crash because of avionics bugs, and people lose fortunes -- or welfare checks -- because of finance programming errors, but programmers just throw up their hands, and say that programming is hard.

The other problem here is the concept that commercial software should be held to some higher standard of liability than noncommercial software. If some random group of strangers build a bridge, which then collapses and kills someone, they're still very much open to lawsuits. So far, the programmers of the world have fended this off by shouting in all-caps about warranties express or implied -- but eventually (I hope) the world will get sick of their shit and hold them accountable for failure. When that happens, whether or not the software is sold should have nothing to do with damage liability (outside of any sale contracts that my apply).

A man can dream.

>Programmers have worked very hard through the years to create the current liability-free environment; people die because of health care programming bugs, pilots crash because of avionics bugs, and people lose fortunes -- or welfare checks -- because of finance programming errors, but programmers just throw up their hands, and say that programming is hard.

Yeah, we've all noticed the rampant mass deaths of millions because of software issues...

/sarcasm

So you're telling us that accidental death is okay as long as it isn't in the millions? How did you decide on that number? Where is the line drawn?

>So you're telling us that accidental death is okay as long as it isn't in the millions?

Yes, of course. We take such decisions everyday. Cars lead to deaths from traffic accidents, and still we are ok with it as a necessary evil, since we want the benefits they provide.

If we restricted technology to "things that can cause absolutely no deaths" we would even have used fire (tons of people die every year from it). Heck, houses too can collapse in an earthquake etc -- we should make sure noone builds one until its 100% safe house (that costs some millions to build).

But my sarcasm was directed at the parent blowing this "deaths due to software" thing out of proportion, and making it sound like someone dies every minute from a buffer overflow.

Good points. But the reason why software being sold should have a higher standard of liability is because in the case of open source software, that's generally just posted on some website and anyone can download it, modify it, and run it on any platform. The authors don't have any control over what anyone does with it, and never received any money for it in exchange for their liability. With many open source projects, there's a feeling that it was created for the author to use themselves and anyone else being able to see the source and possibly get some benefit from it is just a bonus.

With a bunch of random people just making a bridge that collapses, then unless it's on their own property, they know that other people will use it and expect it to not collapse and so liability is justified there. (If it's on their own property, then morally there shouldn't be any liability unless they invited someone to use it, but legally is another matter.)

If this was ANY product other than software, there wouldn't even be a question of Valve being liable, and that's just disgusting to me.

I don't know. I think the main problem with the parent idea is '...and lose'. Perhaps they should be sued (presumably as a class-action), but whether or not they lose is TBD. The parent wants them to be sued only so that they necessarily lose.

What are you whining about? Why would anyone desire for a company to be sued and have them win?

There's just no sense in telling a hobbyist what to do with his personal time. That means its no longer a hobby, it's a charity exercise.

I think the problem is EULAs. Foss Eula's are pretty straight forward - no warranty: use at your own risk. Corporate software takes the same approach, and I think that's cowardly and underhanded because they are a profit driven entity which, if not incentivized properly, would literally rob you blind.

Corporations are profit driven. No profit, no corporation.

If your going to profit off of selling me something which then burns my house down because it was cheaper for the vendor to not build to standards (best practices), shouldn't they be held liable?

If someone made a lamp for themselves that wasn't up to standard, and then left it out on the curb for garbage pickup when you came along and took it home, plugged it in, and burned down your house, who's fault is that? They didn't sell it to you. There was no purchase.

Your analogy is flawed. What is happening instead is someone is making a lamp, and then putting a sign on it says "LAMP is a lamp that lights your home! It's compatible with electricity and is under no warranty, express or implied!" and offering to let you take it home.

And you seem to have missed the part where I explicitly said that both commercial and noncommercial software should be exposed to liability lawsuits. EULAs are a waste of everyone's time: anything distributed in an executable format should expose the distributor to liability suits for damages.

Hm, that's fair.

For what it's worth, I didn't miss that part, I just disagree with it.

But let's explore the idea that anything distributed in an executable format should expose the distributor to liability.

How do you define executable? I mean, what about languages which are optionally compiled, or python or ruby packages for example? And when you say distributor, do you mean distributor or do you mean author? Eg, is Github responsible because they hosted/distributed my code?

No, what is happening is someone making the instructions on how creating a lamp public and saying "I use this lamp in a controlled environment where using it cannot hurt anyone. If you try to use it outside of a similar controlled environment it may explode in your face, create a black hole and/or anhilate the universe. I don't really know, since I did not test it in that environment. Use it at your own risk." Then people go and use it outside that controlled environment, maybe making other people pay for using the lamp created following the instructions.

And now the creator of the instructions is liable for damages? Wait, what?

There is a real an unavoidable distinction between throwing stuff up on github and distributing software packaged for easy insertion into your operating system. If it's so incredibly difficult to test, why provide binaries?

Can anyone design a safe and reliable bridge with a span of indeterminate length across unpredictable geography?

Which leads back to the number one reason why software projects go bad; not knowing what you're meant to be building because you didn't get clear requirements. The number of times the requirements gathering has ended up with questions genuinely being answered "we don't know what we want" makes me want to hurt myself.

This is precisely why I hate comparing building software to building bridges. Nobody builds bridges without knowing exactly where that bridge will be standing, but it happens all the time with software - furthermore same piece of software usually must fit all kinds of "unpredictable geography". As such, yes, I do think that building software is a problem far more difficult than building bridges.

I think that would impact the viability of open-source software in a way that would change the whole world for the worse.

By a lot.

No one sane would put a pet project out in the open, and we'd all have far fewer kernels from which great things could grow.

(Unless you're specifically talking about closed-source software, in which case I just might largely agree with you.)

It's a bit tricker than that though.

In software, if I build a toy, and release it to the world, many people may find it useful. They might trust it with their most personal data, or vital business documents. But, it is still a toy.

If I build a toy bridge no-one tries to make it span the grand canyon. They see it for what it is - its faults are obvious. They try to cross my toy bridge and it easily collapses under the weight of their foot without costing the lives of anyone. And, if they somehow managed to string along my toy to the point where it could span the grand canyon, do you think anyone in their right mind would find me liable as the toy maker?

Ultimately, this is where the differences are huge. People are building toy bridges, pet bridges, foot bridges, bridges for single cars and bridges for 10 lanes of traffic. It's very difficult to accidentally substitute a bridge built for 1 person into a spot you need a bridge for 10 lanes of traffic.

But it's trivial in software to put a "toy bridge" or "pet bridge" where you need something like the golden gate bridge.

So, when someone takes my toy and tries to use it as the golden gate bridge, whose at fault?

Reply on news.ycombinator.com