zegerjan

The EU Banning inefficient vacuum cleaners had a similar effect. Though I'm not aware who is responsible for the policy.

I'd not be surprised if that would lead to job with REMOTE (US EXCEPT WA) soon.

Whats wrong with the Slack version? It's on-par UX for me for recording, and wins just because it's already in Slack?

Thanks for calling this out, I've updated this in the article.

What’s not quite clear from the wiki page: was Yahoo too early? With the related tools on the page being so successful it seems that way.

Azure to GCP was right after GV became an investor. Again, credits was the reason to change over. Not the poor Azure performance.

Interesting take, especially if you factor in action on climate change. The US is unable to get anything done, while the EU has a track record of getting results.

As retail investor there's great downsides to market makers too. The prime example; the true price of the underlying is obscure when executing an order. Where the whole point of the market is to create price efficiency. When anyone creates a limit order in the middle of the spread it's often filled instantly, but not market moving. Other investors now do not have the same information as the market makers have who filled the order. So either they should publicly log each trade so all brokers can show what the true last price was and change in positions with that, or PFOF creates information dissymmetry. Markets should be transparent, and if you make money through obscurity that's against what the market is for.

Another problem is that market makers tend not to provide liquidity when it's most needed; when markets are most volatile and unpredictable. The GME spreads for example were very wide. When the market is very volatile they tend to increase the spreads until the market is predictable (as far as they can be) again. Effectively they're like bad insurance companies: When you need them they're nowhere to be found, when you don't they'll gladly take your money.

It's for everyone involved, except ones that make money of PFOF plus the market makers, probably better to have transparent inefficiency in pricing, then have defuse pricing which in some cases might be in your favour.

Partial clone is currently support at least by both GitHub and GitLab. While still maturing, you could filter for example all large blobs for local development, or only fetch certain sub trees. See also the Git docs: https://git-scm.com/docs/partial-clone, or GitLabs docs: https://docs.gitlab.com/ee/topics/git/partial_clone.html

GitLab will continue to make investments in it for at least the next year as it's a big issue especially for gaming companies.

Full disclosure, currently a GitLab employee.

The issue tracker I think is a better place for such a feature request.

Last time I worked on the attachment code, there wasn't a persistent database relationship for uploads and notes. Which would make this feature hard to implement, it would be a great feature though!

As a hiring manager at GitLab, I'll tell you that these questions are surprisingly effective in filtering candidates. I'm sorry it feels painful to you, however, it's for good reason.

I'm saying the blob was in a new repository, you had no control over. You couldn't have removed it, you could only make sure it doesn't get referenced in _your_ repository. Which is what you did.

The reason you couldn't delete the blob, is because someone forked your repository and GitHub uses git alternates for deduplication of fork networks.

I think you could ask GitHub if you can recreate your repository without the offending blob, and you should be good again.

Adyen not even getting mentioned, very surprising as it handles most payments for Netflix and Spotify.

The additions GitLab has expand on Markdown. For example, if you comment with a string of hexidecimals larger than 8 characters, GitLab will try to link to the commit if it finds one. For issue 1, the reference pattern in #1. This is convenient in cases where you want to cross reference merge requests, snippets, and others, without copy pasting the links. The docs explain it better than I could: https://docs.gitlab.com/ce/user/markdown.html

But in general, GitLab supports Markdown, with a few extensions.

I've used it a couple of times now not to develop, but to incorporate review discussions and minor other fixes. But from my perspective the true value is for non developers, or when you're starting with Git. No need to worry about remotes and what you did or didn't sync. Or if the branch is even there and you need to set the upstream. Concepts one need to get now are branches and commits. No cloning, fetching, pulling or pushing. When starting, branches and commits are hard enough.

Than, when the new user is comfortable they can work their way up.

The Gitaly server has a Ruby component, but also a Go component. The Ruby server uses Rugged[1] and Gollum-lib[2] which both use libgit2.

The Go component doesn't have libgit2 binding yet, although we're looking into adding that later. That or maybe go-git[3]. But for now Gitaly is mainly focussed at migrating all git calls from the Rails monolith. Not introducing a new component now reduces the risks this project has.

[1]: https://github.com/libgit2/rugged/ [2]: https://gitlab.slack.com/archives/C027N716H/p151695430400026... [3]: https://github.com/src-d/go-git/

Generally companies try to settle fast before the IPO so there are less concerns to invest.

No domain knowledge btw, just seen it happen a couple of times before

Also PRs will be imported, milestones, labels and more: https://docs.gitlab.com/ce/user/project/import/github.html#o...

Why only to android? I thought it was an device agnostic technology?

A few weeks ago I had to travel to Berlin from Amsterdam, flight time about 1 hour. I took a 6 hour train instead because I would have internet (roaming is really cheap now in Europe), and all the reasons you mentioned.

The train was even a bit more expensive, but worth every euro.

Except they've rewritten their Mac app in Swift now. So there must be a reason they moved away from that.

I've opened an issue, as I couldn't find another. https://gitlab.com/gitlab-org/gitlab-ce/issues/29861

If we have it profiled we can give it the right priority.

Used Gnome for a while now, like it a lot. However, at times it feels quite bloated and that the bloat will mean some apps don't get attention they should.

Night light is nice, though. Will try it as soon as it hit the repositories on Arch.

That is the internal one, Sid meant to link to the public monitoring, located at http://monitor.gitlab.net/. It doesn't have the daily overview dashboard, but the fleet overview might be an indicator too (http://monitor.gitlab.net/dashboard/db/fleet-overview).

Cool, thanks for stressing this! I'm fine with not choosing Semver, but a date holds not guarantees on backwards compat, nor any other useful info. But I do get you'd like to version components the same to stress those are meant to be used together.

This seems to carefully avoid making any promises about the future. Where SemVer _does_ make promises.

Also, picking a date for versioning is weird as it doesn't contain any information other than when the Changelog was set in stone. Too bad this decision was made, and Docker choose not to value the stability of SemVer.

> Rust 1.15 sees an extremely eagerly-awaited feature land on stable

Hoped to read incremental recompilation there, what a tease ;)

I still insert `!g` in about 25% percent of my searches. Loved to see a metric on how many people do the same or append it on the search box after seeing the results.

I like DDG a lot, but I feel that Google knowing so much about me prevents it from showing ruby gems over ruby lang search results. Must say, this has improved greatly last year, but I don't trust DDG just yet fully.