71–80 of 280 posts
The biggest lesson here is that backing up your files is extremely important. Both local backups and remote backups. I like the 3-2-1 rule: At least three copies, In two different formats, with one of those copies off-site. Software is written by humans who will undoubtably miss a corner case and not think of every possible environment.
>In two different formats What does this mean?
# Scary! rm -rf "$STEAMROOT/"* Anybody who writes a line like this deserves their software engineer license revoked. This isn't the first time I've seen shit like this (I've seen it in scripts expected to be run as root, no less); it makes my blood boil. Seriously. "xargs rm -df -- EDIT: I shouldn't be so harsh, if it weren't for the comment admitting knowing how poor an idea this line is.
Is there proof that the comment was committed with the line of code? Of course once it was a identified a concerted effort could have been made to rectify the situation. Sometimes a problem is identified working on some unrelated aspect of the software and the developer does not have time or scope to change the offending piece of code but wants to place a red flag. Of course this example does not appear to be systema…
Earlier quoted context omitted.
It seems like the direction Linux is going (albeit slowly) is to use selinux instead of different users for this type of isolation.
Yes, however linux supports this sort of security right now and has for many many years, and properly used would have prevented these mishaps. More than backing up their data, I blame the users for being incompetent users of computers in general.
The biggest lesson here is that backing up your files is extremely important. Both local backups and remote backups. I like the 3-2-1 rule: At least three copies, In two different formats, with one of those copies off-site. Software is written by humans who will undoubtably miss a corner case and not think of every possible environment.
>In two different formats What does this mean?
Earlier quoted context omitted.
Yes, however linux supports this sort of security right now and has for many many years, and properly used would have prevented these mishaps. More than backing up their data, I blame the users for being incompetent users of computers in general.
Linus supports selinux right now, the only issue is that applications ship with policy about as often as they create their own user (actually, maybe a bit more often).
This seems like yet another good example of why robust application-level access control would be a helpful thing to build into modern operating systems, in addition to the typical user-based controls. This may have been both a rookie mistake and a regrettable failure of code review processes, but in any case it simply shouldn’t be possible for an application running on a modern system to wipe out all user data withou…
I think OS X (and mobile app development in general) shows both that this is great in theory and a net improvement over not having it, but that there are some common pitfalls to address.
First, there are a handful of apps where this model doesn't work so well -- e.g. text editors, FTP clients, etc. So you're inconveniencing quite a few legit apps which need broader access.
Second, as a corollary of the first, that means you're going to have a lot of apps that legitimately need to ask users to approve broader access. And as the number of apps asking for approval goes up, the more likely users are to simply ignore the warning and approve all. This is especially problematic since we can assume the average user is a good judge of which apps need which access.
Edit: One way of reducing user acceptance fatigue might to introduce greater granularity into the requested permissions and then tier the permissions requested -- e.g. commonly asked vs. uncommon. E.g. an app may legitimately need permission to write to any file in your home directory, but it's highly unlikely they'll need permission to write to more than X number of files per second. Or at least they shouldn't be able to do so without the OS throwing up lots of warnings outside of the app.
This seems like yet another good example of why robust application-level access control would be a helpful thing to build into modern operating systems, in addition to the typical user-based controls. This may have been both a rookie mistake and a regrettable failure of code review processes, but in any case it simply shouldn’t be possible for an application running on a modern system to wipe out all user data withou…
Something like Windows Store apps, but which ideally wouldn't require the use of a specific store? (Only Entreprise apps can bypass the store from what I know)
This seems like yet another good example of why robust application-level access control would be a helpful thing to build into modern operating systems, in addition to the typical user-based controls. This may have been both a rookie mistake and a regrettable failure of code review processes, but in any case it simply shouldn’t be possible for an application running on a modern system to wipe out all user data withou…
The truth is that they are too hard for even your average Sysadmin to configure & manage, let alone your average desktop user.
setenforce=1 (yeah, right).
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…
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 you…
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/
Earlier quoted context omitted.
There's nothing wrong with that line as long as you know "$STEAMROOT" contains a directory that you wish to nuke. The issue is that this particular script did not set up $STEAMROOT correctly.
The thing is, there are so many ways for STEAMROOT not to be set correctly in Bash. Just one typo in some future edit can bork everything if it's not tested thoroughly. Sure, you could somehow check that STEAMROOT is set to something resembling what you want to delete. But manifests are much more simple to get right. EDIT: Alternatively , pick a well-known UUID, and put everything under a directory with that name und…
Shell scripting seems tremendously overused. It makes some things a bit easier, but it's so crazy it makes PHP a look like a pinnacle of good language design.