martingxx

I've always thought that Nagle's algorithm is putting policy in the kernel where it doesn't really belong.

If userspace applications want to make latency/throughput tradeoffs they can already do that with full awareness and control using their own buffers, which will also often mean fewer syscalls too.

I spent around 15 years doing Java exclusively, and after discovering Go (around 2012) I couldn't wait to adopt it and have never looked back since. I don't think Go is perfect, but I find it a much better default pick for most things I've worked on compared to Java. Of course Go has limitations, especially in the type system and error handling, but rather than go back to Java for those cases where it matters most to me, I tend to choose Rust these days. It shares some of the advantages of Java (compared to Go) and also comes with its own set of other major advantages too.

The title says "open source", but the license says otherwise.

I agree about the discussion / issues aspects. I suspect doing that interoperably would be hard or impossible because of the vastly different feature sets on different hosts.

All I am looking for is a few interoperability features for the repositories themselves. In fact, if I were to describe the most important single feature, it would be something like this:

I am able do some work in my repo hosted on host A, which was originally cloned from a repo on host B, and offer it back to the author on host B to merge if they wish. I'd like to be able to do this by notifying them (in a way integrated into my workflow) with the same kind of information that `git request-pull` generates. Importantly I would not need an account on host B for this. Possibly this might need some one-off setup on the original authors side, perhaps adding my repo as an remote.

The use cases I have in mind here are mostly occasional contributions or minor changes. I don't think this would work well for people who are frequent major contributors - they would really need the discussion / issues aspects to collaborate effectively.

I just interpret this whole thing as "developer realises their preferred set of trade-offs matches host A more than host B, so they are switching hosts". This happens fairly frequently in various directions for many different reasons.

Slightly off topic, but related: I wish we could focus less on which git host is "best" and more on figuring out workable interoperability between them. Sadly, it seems less of a technical challenge and more a question of motive.

The UK government almost seem to be deliberately passing multiple pieces of legislation that they know will be overturned due to ECHR, because they believe such rulings would strengthen their argument for withdrawing from the convention.

I think "scam" is a bit strong. It maybe offers less value in some scenarios that people assume, so perhaps offers a false sense of security. People have been saying for many years that ticking the "encrypt at rest" box in your cloud console only protects against things like people breaking in to their data centre, and they are right. On the other hand, it's easy to do, and while arguably not helping much with actual security, it can be a cheap way of meeting policy requirements.

For some newspapers it _is_ working, so clearly it can work.

If some newspapers haven't figured out how to make open access work, but that's a problem with those newspapers, not with open access.

Although I am fortunate enough to be able to afford to subscribe to almost anything I might want to read, I don't like the idea of paywalls in general.

I believe they exclude the less fortunate from access to important resources, so I refuse to give my money to companies that use paywalls, because I see that as rewarding bad behaviour.

Instead, I always pay for sites I find valuable that don't have paywalls (e.g., guardian.co.uk)

I realise this isn't the same view that everyone has, which is fine. Vote with your money.

Everything about this screams satire, except it just doesn't have the typical humour element (to me at least), so I'm not even sure now.

Thanks for your reply.

Yes, I was talking about deploying to our existing cluster. Pretty much the only requirement for software that we run is that it must run in our cluster.

Ironically, it's often harder to deploy applications that offer their own k8s deployment approaches because they often have their own opinionated ways of using it that don't match our policies.

Thanks. Maybe I will try that.

I really like that there is a focus on being able to deploy in k8s. Nice work!

However, some teams (ours) already run their own k8s clusters and would probably want to deploy gitlab in a namespace in there.

I hoped there would be simple example k8s manifests for doing this, but last time I checked I could only find helm charts. We don't use helm and don't want to use it.

If anyone knows some k8s manifests I can cut and paste to get started I'd appreciate it. Otherwise, it's going be be a job of creating it all myself, which right now is what's stopping us evaluating gitlab properly.