PieterH

31 ms·

271.
by PieterH 11y ago
Honestly, accidental discomfort is part of being grown up. To try to regulate that is IMO both patronizing and counter productive. We need some level of friction to socialize. A CoC that lets well-meant actions become crimes is worse than n
272.
by PieterH 11y ago
The protocol I describe is almost entirely about procedure. Was that not clear, or not detailed enough? Removing incentive and opportunity means recognizing what creates risk for participants, and reducing that. Which I also did try to cove
273.
by PieterH 11y ago
We all make mistakes. Yet if we're talking about safety, then we're talking about danger, and that means something specific. Social impairment makes people awkward, it does not make them dangerous. Taking offense at such awkwardne
274.
by PieterH 11y ago
I think we agree that is the intention. However it's more like putting up a sign on a hotel saying "Murder and mayhem will not be tolerated." If there is a real risk of murder and mayhem, the sign needs to read, "If some
275.
by PieterH 11y ago
I've a large building and we've hosted many parties here. Almost always, people are great, even when drunk. Alcohol does not make good people turn bad, in my experience. Every now and then an event deteriorates. I learned that som
276.
by PieterH 11y ago
I'm a large contributor, yet not the creator of the original library. That would be Martin Sustrik. The project today consists of hundreds of projects, and a large community which I've steered since the start. So in that respect I
277.
by PieterH 11y ago
Yes, you get people fixing each others' typos. This is rather wonderful... rather than demand perfection from people, and punish them for making mistakes or not having all the right knowledge, it turns this to advantage. People complem
278.
by PieterH 11y ago
The problem is that even small libraries end up with multiple public contracts that evolve independently. Trying to identify these with a single version number doesn't work. Allowing major version numbers to define interoperability is
279.
by PieterH 11y ago
So yes, you'll want (a) good tests and (b) patches for e.g. the USB3.0 implementation. (I realize that's not how it works for hardware, so it's an analogy). What you don't want is a new release that may change X things b
280.
by PieterH 11y ago
You're right. The essay is out of date. In fact the "don't break stable contracts" rule has made life much simpler. It took a while for that to work through. I've corrected the text. Thanks for pointing it out.
281.
by PieterH 11y ago
I don't confuse these. This distinction is precisely the point of the article. You can test external APIs and contracts. You can't test internal versions. You can design systems to be 100% testable via their external contracts. A
282.
by PieterH 11y ago
Fundamentally, a software package implements multiple contracts, that is, protocols and APIs. Each contract has versions. It's like your laptop implements USB3.0, Bluetooth 4.1, m-SATA, etc. You care a lot about the versions of the con
283.
by PieterH 11y ago
Citation needed. If you have an example of problems caused by forwards compatibility, please provide it.
284.
by PieterH 11y ago
"Quality" is a false goal. Remember the first arguments over Wikipedia and article "quality"? It is exactly the same here. You need people, contributors, eyeballs. Get that, and quality will emerge smoothly over time. Lo
285.
by PieterH 11y ago
It hurts a lot when your assumptions are challenged. The process we use in ZeroMQ is successful beyond all expectations. See http://hintjens.com/blog:93 . What I'm doing with these "Top 10" articles is documen
286.
by PieterH 11y ago
It wasn't relevant to the article and I'd rather avoid rabbit holes. One has to pick one's fights. You can read my views on software licensing on my blog (How to Capture an Open Source Project), or book (Culture & Empire,
287.
by PieterH 11y ago
It's a problem in theory, not in practice. The notion of throwing away old data (or coalescing new with old) is relevant to slow queues. It turns out to be irrelevant with ZeroMQ. First, message rates with ZeroMQ are often hundreds of
288.
by PieterH 11y ago
True, and perhaps Nano was inspired by this. However look carefully and you will see that we never, ever, criticized RabbitMQ. I know the team that built it, they are friends, and we both invested crazy amounts of time in trying to keep AMQ
289.
by PieterH 11y ago
Discovery is one of those problems with dozens of answers that depend on your context. For many cases, UDP broadcast/multicast is perfect. For others, a broker can help a lot (ZeroMQ has a broker, called Malamute, that is easy to use f
290.
by PieterH 11y ago
Yes, it does not describe the current security mechanisms. I've written articles on my blog to explain those; they need to be reworked into a new Guide text. Version 4.0 is stable; there's a pending 4.1 update.
291.
by PieterH 11y ago
That's kind of cool. It's a full, large book complete with examples with full syntax coloring. And still fits into less than 1/100th of a cent of disk space.
292.
by PieterH 11y ago
We've stopped using "ØMQ" in text and now just use "ZeroMQ" in most places (like in the Guide). The original choice was to annoy people into remembering the name... it kind of worked though got tiresome after a few
293.
by PieterH 11y ago
Ah, indeed, thank you. This is encouraging and I'd like to see more of this. We need spaces for experimentation and competition, and the more libraries attack this "NoBroker" space, the better. I do wish Nano would stand on i
294.
by PieterH 11y ago
Thank you for this, I appreciate it. The Guide took a long time to write, around a year. It was the first ZeroMQ project where I merged all pull requests without code review. The results were amazing: most of the examples are now in many la
295.
by PieterH 11y ago
The original codebase used asserts rather poorly, for error handling rather than internal sanity checks. Four years ago we had fixed most of these problems, and had a "futzing" project to try to crash the library. Over time we&#x2
296.
by PieterH 11y ago
The two approaches are very different. RabbitMQ centralizes and uses a fairly heavy asymmetric protocol (that I originally designed, so I know this pretty well), which makes the server a major hub, and clients rather stupid and slow. There
297.
by PieterH 11y ago
Nano is excellent in many ways, though it's not a successor, that's just bombast from its author. ZeroMQ is far more than a library. It is a large community and hundreds of projects, e.g. independent ZeroMQ versions in Java, .Net,
298.
by PieterH 12y ago
The racketeering of the "protect your inventions" system really makes me angry. It's been ten years since the European Parliament rejected patents on software. And the EPO just won't give up.
299.
by PieterH 12y ago
I never claimed to create ZeroMQ. However, ZeroMQ is a community of hundreds of projects and thousands of people, not a single library, and I'm one of the main contributors even to that original core library.
300.
by PieterH 12y ago
Do your ZeroMQ test branches fix that (pathological) design of opening a new TCP connection for each message? An alternative to making a fully distributed ZeroMQ topology would be to use the broker based design that the RabbitMQ driver uses

More ›