martingxx

I wonder how this compares to tau https://tau-agent.dev/ ?

Both are in Rust and both mention Unix in their descriptions.

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.

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

(See license.https://opensourceforu.com/2019/06/cockroach-labs-changes-it... )

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.

provides little concrete value to the business

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.

Why not release anyway (for transparency) but with explicitly no support?

And Azure is backed by Microsoft, GCP is backed by Google, so if "Bezos loses his mind" there will be other alternatives besides Kubernetes.

You missed the point that moving from AWS to GCP or Azure is going to be _extremely_ complex and expensive if you have used all those shiny AWS platform features. It is very easy if you are using k8s.

Running k8s in AWS (and gcp, and on-prem) is exactly what we do and we're really happy with it and have avoided lock-in. We recently moved a bunch of k8s-in-AWS hosted stuff to gcp and it was seamless.

Can you elaborate?

I disagree with you and I have been using both (as well as gcp) in production for years.

They are both platforms that you write an application stack against. One is portable and can run in any cloud, the other only works in AWS.

Just because one is ALSO a cloud provider doesn't make them incomparable.

what can k8s do to AWS SaaSes (e.g. RDS, SNS, etc...)?

k8s has allowed us to not use RDS any more because we now host PostgreSQL inside k8s instead. It's a bit more overhead, but we're now portable and run in gcp too with the same k8s manifests and almost no porting effort.

So yeah, we escaped the lock-in.

And now we're not just tied to the AWS stuff and we're experimenting with cockroachdb and other products that aren't there "natively" in AWS, so beyond escaping lock-in, we're more ready to experiment with newer stuff.

Its 2019 and people still confuse the different kinds of "free" when talking about open source software.

(Also, yes, I open source as much of my work as possible, and I'm paid to write it)

Also, AWS is BUILT on open source, they just don't open source the extra bits they added on top. Just like how Microsoft took an open source tcp/ip stack and open source web browser, added some stuff, and called it their own.

The `fmt` packages is described as being for "formatted i/o". It seems that ordered maps, while not "i/o" is reasonable to describe as "formatting", so it's fine to do it in this package I think.

`fmt` has always made things look prettier, that's part of what formatting is about.

You could equally argue that `fmt` should not round floats or pad numbers with zeros or spaces.

Can you explain more about why you re-wrote?

You seem to have said you rewrote from Go because it has poor polymorphism, into C which is equally bad in this regard.

If you find some language feature important, surely you would not rewrite into a language that doesn't have that feature?

Correctness (and any other kind of change in behaviour) is easier to achieve if things are simple.

Changes are not necessarily easy or even possible to make safely if things are correct but not simple.

"Simple" is a proxy for "can be changed safely" and so IMO is the most important quality to have.

Even with those reasons, I believe the risk outweighs the potential benefits. It's not just about trusting the intentions and assurances of the company, but also their competency and knowing they're not being compromised etc. Hackers don't care about paper trails. These are things you typically can't measure.

If you have untrustworthy employees, you have bigger problems than you can solve with by MITM attacking everyone.

These apps are mostly microservices and the Java ones are mostly only a year or two old. None of them use things like spring. Some use Dropwizard. Would you consider dropwizard modern? If not, what would you use instead?