3 ms·
Yup, it's never the fault of a person, always of the system. Once we get this resolved we'll definitely look at ways to prevent anything like it in the future.
by connorshea 10y ago
Yup, it's never the fault of a person, always of the system. Once we get this resolved we'll definitely look at ways to prevent anything like it in the future.
- deleted 10y ago[deleted]
- duncan_bayne 10y agoWishing you the best of luck partly out of sympathy, and partly as an active user wanting my account operative again :)
- wereHamster 10y agoAt some point you have to blame the person. If the person did it wilfully, deliberately, ignoring the checks and safeguards. Or because there's already so much system that having any more of it would place severe restrictions on everyday tasks. I'm not saying that's the case here, because it does seem that GitLab has systemic deficiencies. But "never" and "always" are such strong statements. Prosecutor: Mr. Accused, here is evidence that you murdered that other person. Accused: It's not my fault, but the systems'. Judge: Oh, ok. You are a free man.
- DanHulton 10y agoThe law and a "no fault" postmortem are entirely different things and you conflating the two doesn't help the discussion. Let's assume a bad actor in a company. It still doesn't help improve the situation to allow blame to rest with the bad actor. Definitely, there should be penalties applied (likely the termination of their position), but it doesn't help your company at all to stop there. Did they delete data? Why is there no secure backup system in place to recover that data? Why was there such lax security in place to allow them to delete the data in the first place? Why are we hiring people who will go rogue and delete data? Did they "turn" after working here for a while because of toxic culture, processes, etc? Hell, if the law worked this way, we might actually have less crime because we'd look further into the causes of crime and work to address them instead of simply punishing the offenders.
- kefka 10y agoThe reasoning for that was to prevent reducto ad absurdum and "It's YOUR fault". "You should have KNOWN that erudite command was going to fail." "You should have known that our one-off program had issues you did not account for." "You should have known that the backups were not properly tested elsewhere for known good state." "You should have ....." In reality, some disasters were caused by idiotic things like "rm -rf /opt/somedir ." You just hosed the system, or a large part of it quickly. And we could say that your malfeasance of including the "." started wiping / immediately. But we can also say that rm should be aliased to prevent accidents like that, or that rm should do some minimalistic sanity checking on critical directories before executing them. People can, and will mess up. These computers are nice, in that they can have logic that can self-correct, or at least loudly alert errors.