Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Data Loss at GitLab

blog.2ndquadrant.com

Post reply on HN
Print view View original

121–130 of 236 posts

Re: Data Loss at GitLab

#121

Post by E6300 »

thewhitetulip wrote: post #111
deckar01 wrote: post #101

Earlier quoted context omitted.

> GitLab cost everyone a day GitLab isn't popular because of the stability of its cloud platform. It's popular because you can install your own instance for free practically anywhere with minimal effort. I run GitLab CE on a box in my server closet for projects that involve livelihoods.

>It's popular because you can install your own instance for free practically anywhere with minimal effort. If that is the reason why you use Gitlab, then why not try gitea or gogs? gogs is written in Go and provides a docker image or a drop in binary

Gogs is pretty sweet. After hearing about it here I installed it on my old home server with constrained memory because I couldn't meet Gitlab's (IMO) obscene memory requirements. It's perfect for my needs as a hobbyist and I even use it as a secondary Git server from work. It's also way, way faster than a self-hosted Gitlab or any public Git server, so even though my current server has more than enough memory to run Gitlab, I still use Gogs.

The only (minor) issue I've had with it was when I tried to push the OpenCV repository to it, just for the hell of it, on a heavily constrained VM (Debian with 256 MiB of RAM). The poor thing just couldn't handle it without crashing until I upped the memory to a couple gigabytes.

Re: Data Loss at GitLab

#122

Post by juskrey »

bbcbasic wrote: post #108
juskrey wrote: post #106

Earlier quoted context omitted.

The one who erred (and recovered) once is more valuable than the one who never made mistakes.

There is no basis for that assertion.

This is basic risk management. What matters is error survival, not absence of errors. Moreover, total absence of errors means accumulating dangerous risk. See NN Taleb, for example.

Re: Data Loss at GitLab

#123

Post by shakna »

bbcbasic wrote: post #108
juskrey wrote: post #106

Earlier quoted context omitted.

The one who erred (and recovered) once is more valuable than the one who never made mistakes.

There is no basis for that assertion.

A well known library like curl, has had CVEs.

A not known library that also addresses the same circumstances as curl might have none listed.

Which would you prefer to use?

Re: Data Loss at GitLab

#124

Post by VintageCool »

Thaxll wrote: post #66
nicpottier wrote: post #58

Earlier quoted context omitted.

I think you are confused. The best thing to happen to OSS is GitHub, not GitLab. GitLab is just a fast follower and likely wouldn't even exist without the former. I for one am happy to throw money GitHub's way for their role in so dramatically changing how we code.

You code differently using Git vs SVN? That's an interesting concept. It doesn't change the way you code it just changes the way we share code.

A few months ago I was developing for a breaking change and realized that I wasn't committing anything. That's very much an SVN mindset where merging is so painful that you culturally just avoid it altogether. Git's emphasis on being distributed and branching and merging constantly meant that, once I pulled my head out of my ass and started committing locally, I was able to enjoy the benefits of source control while developing my breaking changes without affecting anyone. And later, when I merged my branch into the master, it turned out to be completely painless.

Re: Data Loss at GitLab

#125

Post by pzh »

Does nobody else find the report cringeworthy? Apparently, there are some junior engineers fumbling around and committing serious errors, but where are the senior ones and the process/failsafes to prevent all this?

Re: Data Loss at GitLab

#126

Post by VintageCool »

patmcguire wrote: post #39
sgarman wrote: post #35

Earlier quoted context omitted.

Seems like confirmation bias. I always think of nosql databases when I'm thinking about terrible data loss stories, I especially remember the couchDB one. Postgres has been nothing but amazing for my uses.

If you delete your data directory, you're going to have a bad time no matter what your stack is.

Yes, it's probably an outage event, but then you flip over to your slave MySQL instance and keep going on your merry way.

Re: Data Loss at GitLab

#127

Post by dredmorbius »

lsh123 wrote: post #114

Many years ago in 96 or 97, my colleague tried to upgrade Oracle DB by running "sudo /path/install.sh" from the root folder. Little did he know that the script did "rm -rf *" on one of the first lines :) The day was saved by the fact that Oracle stored data on a block device directly. There were no data loss and we just had to restore the machine itself. Since that day, I never run any scripts in /, /etc/, ...

I've always despised the practice of vendor-provided installation scripts for much this reason.

Use local installers. Or tarballs.

Re: Data Loss at GitLab

#128

Post by dredmorbius »

cptskippy wrote: post #23
marricks wrote: post #20

From their blog post, > So in other words, out of 5 backup/replication techniques deployed none are working reliably or set up in the first place. We ended up restoring a 6 hours old backup. That must be _terrifying_ to realize. I mean, thank goodness they had a 6 hour old back up or they'd be in such an awful spot.

I would counter that they're still in an awful spot because this announcement reeks of incompetence and isn't something you want to hear from the guys you're entrusting with keeping your code safe. It would be like Boeing or Airbus announcing all the safety features on their airliners were non functioning.

BOAC Comet.

Re: Data Loss at GitLab

#129

Post by yorwba »

JonathonW wrote: post #115
dkural wrote: post #95

Earlier quoted context omitted.

My pizza joint does not prevent or block open source development either. Apple has open source projects that they've made available. Many people use Visual Studio and Azure for open source projects, or software development in general. I find it very easy to use. I hope Github makes a lot of money from enabling open source. Who knows, maybe Microsoft will buy it. More seriously: Github is a business focused on turning…

Meanwhile, GitLab is also a business focused on turning open source community ethos into hard $$$-- part of their core product may be open source, but they're not a non-profit. (One might even say that Gitlab is even more focused on turning open-source community ethos into hard $$$, because GitLab takes open-sourced community contributions to GitLab CE and rolls them directly into their paid, closed-source GitLab EE.…

> GitLab takes open-sourced community contributions to GitLab CE and rolls them directly into their paid, closed-source GitLab EE

Just FYI, the GitLab EE source code is available at https://gitlab.com/gitlab-org/gitlab-ee/. You're right about the "paid" part, though.

Re: Data Loss at GitLab

#130

Post by problems »

thewhitetulip wrote: post #111
deckar01 wrote: post #101

Earlier quoted context omitted.

> GitLab cost everyone a day GitLab isn't popular because of the stability of its cloud platform. It's popular because you can install your own instance for free practically anywhere with minimal effort. I run GitLab CE on a box in my server closet for projects that involve livelihoods.

>It's popular because you can install your own instance for free practically anywhere with minimal effort. If that is the reason why you use Gitlab, then why not try gitea or gogs? gogs is written in Go and provides a docker image or a drop in binary

GitLab is a lot more feature packed than Gitea/Gogs. Gogs is lightweight, good for personal projects, but if you're looking for something to deploy company wide with integrated everything, Gitlab is the way to go.
Post reply on HN