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.
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.
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.
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.
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.
This looks great, and I look forward to finding time to try it soon.
However, I believe it's misleading to call it "open source". The SPPL license is not generally considered to be an open source licence by any meaningful definition, and in particular does not meet the OSI definition and is incompatible with most licences that do.
I understand the need these days to protect against aggressive cloud providers, but there are other ways to achieve that without becoming completely non open source, such as the BSL
I disagree that encryption is political. Fundamentally, it's a privacy and security mechanism and on its own it's no more political than locks, safes, paper shredders or curtains.
Because of the complex, un-intuitive nature of encryption, it mixed particularly badly with politics, and we're still suffering from the fallout of that now. (crypto wars 1)
Firefox and other application vendors who use those standards do end up being unavoidably slightly closer to politics (as demonstrated in this particular issue now), but I think Mozilla would do well to keep their goal simple - Protect user privacy where they can and explain to users when they can't.
A notice to the user like "You are using a key known to allow access to third parties" is just a fact and no more political than "the site you are visiting uses weak crypto standards" or similar.
I always hear people warn about these things, but haven't seen it in practice at all, as long as those who write the systems are also responsible for operating them and not subjected to inappropriate external interference.
Of course, letting someone write whatever and then move on and leave it to someone else is a problem, but that's a problem regardless of whether they used bleeding edge tech or not.
For example, I've personally seen more tech-debt sins in more traditional monolithic Java + rdbms applications than I have an any of the Go based micro-services + nosql/etc I've seen over the years. I'm not trying to prove that "bleeding edge" is therefore better because it's not. I'm saying it's irrelevant.
The problem of leaving behind unmaintainable crap isn't about the tech, it's about the management, the team processes, the prioritisation process etc.
The concrete value doing such things add to our business is happy staff (which you mentioned), which means the best people don't leave, and stat excited and productive for the long term. Also, when hiring, because it helps us get the best people to join us in the first place.
It's not just about "bleeding edge", it's about giving dev teams the freedom to do that if they want to. Some do more than others, but the point is, if they get it wrong, things break and they get called at the weekend or whatever and they soon change track.
There are plenty of companies who have released their source code but don't support it in the same way a typical community driven project like other open source projects do.
This is especially true for certain privacy and security focused applications. For example, Signal release their code, have quite a lot of users, and don't report an unmanageable overhead due to having released their source code.
It's not just a matter of trusting their intentions, it's a matter of knowing that their code matches their intentions. I trust OpenSSL (mostly, these days) and I always trusted the intentions of the developers, but if their code was not open it would not be half as secure today.
Both are in Rust and both mention Unix in their descriptions.