Thanks for doing this. I mean, copying the article.
1,353 karma · joined July 29, 2008
There are other manufacturers that do the same kind of model.
Just avoid HP and (in my experience) Canon. Laser is the way to go.
There are ways to deal with that, e.g. force small patches that solve well-identified problems; use CI to test; involve projects' users in testing; and above all, to have other maintainers in the project who can catch such behavior and help you fix it. By yourself, you're rather vulnerable.
Ideally you have a core of 2-4 people you trust from previous projects, and then you can bring unknown people in little by little.
There is no tradeoff as such, but you do need to be more sophisticated than "here are full commit rights."
In practice you build services which are internally composed and scaled using threads and processes, and which talk to each other over plain (unencrypted) protocols, e.g. TCP between boxes, IPC between processes on the same box. And when you need to talk to the outside world you build bridges that can speak any protocol you like, such as HTTP, or ZeroMQ's encrypted TCP protocol (CurveZMQ). From the developer's point of view, it's mostly transparent. Obviously you need security infrastructure, e.g. key/certificate management.
You can build entire ZeroMQ applications using only encrypted TCP and they will run on public infrastructure. You can develop and test the same apps on a laptop. You might run the same code using IPC on a laptop, and CurveZMQ over the Internet.
So though ZeroMQ definitely uses TCP as one of its transport protocols, it's not a replacement for it.
Which means that doing things like asking for the IP address of a peer make no sense. What's the IP address of a thread, or another process on the same box? If you need identity information, you should not use the transport protocol for that.
ZeroMQ "memory leaks and timeouts" wasn't the issue. Do you have a reference for that?
Salt's issues with ZMTP were performance; they wanted to multicast securely, and ZMTP does not support that. I'd complain once again that making their own custom protocol (actually, it seems to be largely just CurveCP) rather than working with us to extend ZMTP was poor form. Also, Salt wanted a pure Python stack.
In the end the whole point of ZeroMQ was to build new protocols and APIs for decentralized messaging. My real disappointment with nano was that it made zero effort to build on existing work (mainly, ZMTP) and instead just started again, as if thousands of people hadn't spent years figuring out what a decentralized messaging protocol might look like.
It was worse than that, in fact. Nano launched itself on a wave of negativity. It makes good press, and poor everything else. Such hate for one's own history and knowledge base isn't healthy. If a messaging product isn't aiming at interoperability as a primary goal, it is worthless.
I'm not a fan of the "IETF or bust" approach either. That just doesn't work if you're a decentralized community. We needed and still need lightweight processes for RFC development. We use such a process (Digistan's COSS) in our RFCs. It wasn't random. I built Digistan and COSS over years after seeing AMQP swallowed up and destroyed by a committee. Why isn't nano using a process like COSS?
Without interoperable protocols, all we have is a bunch of software projects. And they die. And then all this is for nothing and the proprietary systems will rule the world and our dreams of making distributed software cheap again will die as well.
And this makes me angry: nano had the chance to push this forwards, and threw it away like old trash. What a stupid, petty waste of opportunity and goodwill.
- It is really seldom that a patch is reverted (that a patch is removed). As in, it only happens in exceptional cases, when someone has made an obviously toxic patch by accident on on purpose. It's far easier to move forwards with improvements to the patch. We encourage people to do this rather than provide opinions on the code in writing. What this does is interesting: it brings others in the project into the work, and creates instant mentor-mentee hookups. We see this really often and it is a wonderful thing. You make a patch, it's merged, someone sends a patch on your patch and explains why, and suddenly you have someone in the project who knows that area and can teach you.
- Large sweeping changes are sometimes the simplest way to e.g. refactor some code. It's usually a Really Bad Idea to make functional changes at the same time. It also depends a lot on the language. I'd disrecommend large sweeping changes to a C project, absolutely. The risk of introducing multiple bugs is just too high. In a scripted language, far less risk, and so it's safer. In general, functional changes appear to work better as many small testable steps, and refactoring can work as a single mass change.
- OM scales really well. It needs 2+ people in the project. After that, the limits are elsewhere. Projects with hundreds of contributors are probably too large in terms of internal structure. It means you get ad-hoc pseudo-projects inside a single repository which means poor internal contracts, etc. I'd say a project with more than 7-10 active contributors at any time is getting too large. IME a network of small projects works far better than larger monolithic projects.
- I use OM (the C4 protocol) on all projects, whether they are just starting (my first act is then to call for co-maintainers), or have been around for ages (like the libzmq C++ core library, with hundreds of contributors). We've never seen an issue of scale.
Cheers!
Copyright and patent violations fell under criminal law some years ago. There was a long battle in the EU to stop this happening. The movie industry won. In France the law was passed under Sarkozy iirc.
When you download a movie, this is now a criminal offense. However the sanctions are mild (warnings) for first time offenders, and only turn to jail time for those making a lot of money from it (I think, IANAL.)
In all cases however the rights holders don't sue, it's the state that sues. Big win for the content cartels as they get these cases prosecuted for free now.
Which is all kind of a shame since it would have been so nice to see a new C engine in the community. We have new engines in C#, Erlang, Java, yet the old core project is still that somewhat clunky C++ engine.
You cannot prevent this. The right thing to do is to learn to abandon old solutions when they're no longer economical, and to move rapidly to build new ones that fit the same APIs, yet know more about the modern world.
Hence your car seat is approximately the same API as a horse saddle, built on different technology.
Read my longer comment in this thread about the C4 process and imagine: you send a patch, and it's merged onto project master within half an hour, and you can then depend on it being available to you forever, as long as you invest in some documentation and tests (if it's a new feature).
Yes, absolutely. Read https://rfc.zeromq.org/spec:42/C4/.
We developed the C4 contract (in the form of an RFC) precisely to teach maintainers how to welcome new contributors while keeping quality high. It took many years to refine this approach. By formalizing it, it becomes really simple for projects to adopt: all you need in your README 'Contributing' section is a license (we recommend MPLv2), a link to this RFC, and later a style guide to ensure consistent code style.
The thing about C4 is that it teaches people to make small testable patches, and to trust new contributors. We know from experience that it's users of a project who keep it alive. Original authors and core maintainers burn out, get full time jobs, start new projects. As long as you have users, though, you have potential contributors.
Small patches, merged immediately, with reviews and improvements made asynchronously over time. This style is lovely to work with, kills bike shedding (we argue with new patches rather than comments), and reduces the friction in the project to as low as possible.
More on optimistic merging: http://hintjens.com/blog:106
In terms of friction: we aim to get a patch live on master within a few minutes. If that breaks master, we fix it either with a new patch, or a revert. Anyone can submit a patch, anyone can revert or improve previous patches. You can't merge your own pull requests. We work straight on master so new code is pushed aggressively towards users capable and willing to use it (those who build off master). We use CI heavily to test backwards compatibility, i.e. that existing APIs and protocols haven't broken.
There is also a whole theory of how incremental testable patches remove the need for "intelligent design" and thus the dependency on brilliant key individuals. That's another story which I cover in my book "Social Architecture". Free to read online if you want it.
Best of all, this process works. We know because we've been using it quietly and successfully in the ZeroMQ community for years.
Of all the things I've done in open source, I consider this my most important work, as it solves the really essential problem raised in TFA, which is how to keep open source projects alive over the long term.