First of all and mostly, we could never exactly figure it out what was going wrong.
This was a few years ago and I don't remember all the details. We just had occasional issues with stopping/starting and especially restarting processes when pushing a new version out or when a process crashed. I do remember it could occasionally report a successful restart and still leave the old process(es) running.
All my developers became very familiar with supervisord, and it was number 2 on the troubleshooting list (1. Did we introduce a bug in a recent commit? 2. Did supervisord do something weird again).
After we switched to runit, only devs that touched ops knew about it at all. And we all forgot it was there. That's what you want in an ops tool.
I don't code much in Go but the thing that bothers me the most is the way variable types come after the variables names. What is surprising is nobody talk seems to be bothered by this at all....
That's actually the more 'normal' way of doing it. In type theory (or mathematics in general), you almost always write value: Type. (For instance F: A -> B.)
This is how it is done in ML, Haskell, Erlang, Rust, Smalltalk, etc...
It's mostly just C-like languages that do it the other way.
As dayjob C coder, I just find the way types are written in C complete nonsense (especially when you start declaring pointers to functions), and no modern language should force that horror upon developers.
Go types syntax is well done, IMO, even though I'm not into Go language that much (I rather Rust).
The good thing about how things are structured in Go is that you can read your types from left to right, while in C, you need to use a more intricate way of reading types... http://c-faq.com/decl/spiral.anderson.html
On the first couple pages, yeah. Skip 10+ pages and you get stuff like "nigger stole my bike" etc.
As a side question, shouldn't it be fairly easy to flag those repositories and then sort through those who have it as an offensive word list and those who are just being derogatory?
I don't understand why they don't filter it on upload stage ("push"). "git push" > "sorry, can't push because of words: [list of words here]". Is it more difficult than later disable whole repo because of one stupid joke?
Isn't the name "git" (and therefore "github") itself considered pejorative? IIRC, Linus did name the tool after the British slang word.
"Git is a mild pejorative with origins in British English for a silly, incompetent, stupid, annoying, senile, elderly or childish person. It is usually an insult, more severe than twit or idiot but less severe than wanker, arsehole or (redacted)."
Those aren't typically derogatory descriptions of people, though. Profanity isn't necessarily an issue; derogatory language is. I'd expect Github to take down repositories containing slurs of any kind, while leaving up things like https://github.com/nvbn/thefuck/
That doesn't explain why they were seemingly allowed to replace "retards" with "gits" which is obviously still being used with the same derogatory meaning.
And it would take you another 2 to report them, and github a few moments to act on it. They don't necessarily proactively search for it, they act on reports.
A feature I miss in GitLab and Github is an issue tracker across multiple repos. For example, our project has 5-10 repos but they are all part of single release/milestone.
Currently, we have to create milestones in each of the repos and assign issues to those milestones. It's really a hassle. We cross reference commits a lot in the issues and this is the reason why we don't create a "empty" repo simple for common issues. Unless there is some way to say something like "Fixes commonissuetracker#43".
We do the same thing as you, create the same milestone in each of the repo's and then use the group milestone view to see an overview.
It would be nice to have a create milestone at the group level that creates the milestone in all projects, would you be willing to contribute that?
Mentioning issues or merge requests in other projects can be done with the cross project reference, found in the right hand side of every issue and merge request, for example gitlab/organization#260
I just looked at the pricing page on Gitlab.com and was genuinely interested in trying it out. But the pricing language and structure on the page turned me off instantly.
I thought to myself: "$3.25 per user per month? Sweet! I can throw $6.5 to try it out without the hassle of setting up yet another VM. Charged yearly? Eh, seems to be a bit of a commitment. Oh wait, in multiples of 10? that's $390 upfront with 8 extra licenses for a year!"
They list the monthly price first but they actually bill hourly. It seems more honest and upfront to tell me what I'm in for.
I understand that you're competitive compared to Github enterprise, but I think that page needs some work to make it more trustworthy and less salesman-pitch-y. Even Github lists that they start from $2500 upfront, not $3.25 + read the fine print.
Best of luck to you and congratulations on the funding.
Edit: And I just noticed that's actually for the on-site EE and that Gitlab.com is free. Oy vey.
Thanks for your thoughtful comment. We had yearly prices before but most people expect a price per month (our prices are pretty low so many people assumed our yearly price was our monthly one). I agree that now it is hard to make out the minimum order size, you need to do x10x12. Would it be an improvement if we add '$390 per user pack' to the list of items below the price to save you this calculation? BTW If you want to try it out we do have a money back guaranty.
Thanks for your reply. Price x12 like you said is standard, it's the x10x12 that caught me off guard.
I think some language and price listing adjustments like you suggested would be a great improvement. Even if it's as simple as $32.5 per user pack per month (charged yearly).
But you _charge_ per user pack, do you not? Can we purchase 17 licenses? How about 23?
We have around 20 Backblaze licenses that we pay a bit over $1000 per year for. It makes sense for them to advertise the price per user because they charge us that way.
This is akin to Pepsi sticking a huge sign over their 24 pack at the department store saying "NOW ONLY 99 CENTS PER CAN!" minimum 24, in increments of 24.
Anyway, like I said, the way the pricing is advertised turned an interested/potential customer away.
it would be great if you would change it to something like "monthly subscription" "per user pricing". Which means I could start with 2 users, add 10 and pay for them and maybe then I will kick two in the next month and will pay for 10. Paying on demand is something that I think would be really really good. AWS style.
Your current pricing model is fine. If someone needs GitLab, they'll pay for it. If they don't pay for it, they don't need it. $30-60/year is cheap, even for a hobbyist project.
I think you may have validated what the OP was saying :-) It's $3.25 per user per month, but the minimum order is 10 users. So the minimum price is $390 per year.
We aren't hobbyists, we are just a small company 5+-1.
And sometimes we hire people for a small amount of time, which could exceed 10. So for that time we would need to have a bigger license?!
If you exceed 10 non-blocked users you would need a bigger license. If you can block certain users at certain times you would be able to use 1 user pack (the users are not named).
I think the real angle of this feature should be to abstract the concept of "project" so that it is no longer synonymous with "git repository". And the migration path is pretty straightforward: every repo becomes a project containing a single repo, and then users can merge existing projects to create multi-repo projects (at which point you'd probably have to re-number every issue, pull request, etc. to avoid collisions).
We use gitlab at PacketZoom too and are mostly happy with this. But yes, I second the request for either:
a) Creation of a project independent of git repos.
OR
b) At least a way to attach issues across projects. Issue management is probably the weakest part of gitlab and one of the big reasons is this fragmentation of issues across git repos. It's trivial to see that issues can and will cut across git repos in any reasonably complex product. Another "nice to have" feature would be an ability to create "dependent" issues.
That seems pretty reasonable, maybe even preferable. Having issues attached to specific repos but synchronized to cross-repo common milestones sounds like it would work well.
I like this way of organizing. At my last company we had a very, vary large project that had about 70 git repos (and that was after combining quite a few of them). A project view would have made that so much easier to manage.
This is a feature of ZenHub (zenhub.io). I'm not a customer, though I may sign up in order to be able to get a 'dashboard-like' project management overview of issues across client projects.
You can do exactly that with github. org/app PR with the first line "Fixes org/tracking#43" will link the PR to the tracking repo's issue. Merging the PR closes the issue.
Still no user namespace support? I don't get how one can use for production websites without this. Especially if your run arbitrary containers from the docker registry. Or this not the suggested model anymore?
Do any other container projects support user namespaces? I'm curious about what the implementation would look like. Several things change when a user namespace is added to the mix, such as the container not being able to create new device nodes. Would it be possible for unprivileged users to create containers that had network access or is a daemon running as root still necessary?
I have heard of pflask. It's been a great resource for learning how containers really work, but I haven't been able to figure out how the user namespace stuff works. A container may have N users, root and a bunch of others, do they all needed to be mapped to users on the host? I just don't know how to manage it. Enlightenment appreciated.
pflask author here (I'm a bit surprised to see it mentioned here really).
To answer your question, no, you don't need to map all the users inside the container to users on the host.
pflask user namespace support is quite limited right now: with the --user option you tell pflask to map the outside user that is running pflask, to the inside user specified by the option. Let's say you run something like:
$ sudo pflask --user=some_user ...
Since you are running pflask as root (sudo ...), pflask will map the "root" user outside of the container to the "some_user" user inside the container.
The whole point of this feature was the possibility of running pflask as non-root, so you could map a normal user on the host to the root user inside the container and still be able to call mount() (although there are several limitations), so it's only possible to map one user right now, however it shouldn't be difficult to add another option to map additional users (feel free to open a GitHub issue if you need this).
Thanks! I've been writing my own container implementation for the GNU Guix project and your code has been a wonderful reference. Guix allows unprivileged package management, so I was hoping that my container tool could offer unprivileged containers via user namespaces.
We have implemented user namespace support in runC, which we announced today :) https://runc.io
Integration of user namespaces into the developer-facing tools is ongoing, but there is an design discussion to finish on how to best handling uid mapping without breaking shared volumes.
TLDR: if you want to customize your docker install to support user namespaces today, you should try runC.
