It refers to a technique also known as "port knocking" which consists of leaving a port closed by default and opening it upon receiving a message by another channel (in this case, a UDP packet).
It was mostly in use when TLS hadn't made it's way into most common protocols
No, that’s not what this is referring to, since that doesn’t involve blocking IPs. This page[1] provides some detail:
> A recent change goes a step further and sends a UDP packet to my OpenBSD firewall containing the IP to be banned, and a small Ruby server running there adds the IP to a pf table, immediately blocking all further IP access from the bot.
We still intend to publish the successor to Pithos at some point, it has seen a large overhaul in terms of how metadata is handled and relies on a in-house system for blob storage.
This is great news. At Exoscale we are now using Clubhouse but keep tracking product descriptions and design documents + ADRs outside of it. Tying these to the in-flight epics would be a very welcome change.
One can only hope it will remain engineer friendly and allow for reviews and good text formats.
Thanks for looking into the service. We're certainly not the cheapest in terms of pricing but I would also warn against using RAM prices as the sole way to gauge a service.
To drive low prices a lot of VPS providers tend to have a very liberal way of playing with overcommit, which we don't do. The same goes for CPU.
Our instances should be considered to higher-end families such as the C3 and here you'll see we're playing in the same field in terms of prices.
Exoscale sits in the middle between AWS and Digital Ocean. It has a much narrower catalog than that of AWS but essential services needed to drive cloud application.
DO relies on KVM which OpenBSD has supported for a good while. If you are interested in something similar - including price-wise - to digital ocean with support for OpenBSD, I encourage you to try https://exoscale.ch
This is an important move for the Clojure language. As with all dynamic languages, and exarcerberated by the fact that it encourages relying on data first - as opposed to say, classes in other languages - Clojure puts the onus on the developer to catch errors in data.
The clojure community as a whole embraced prismatic's schema as a way to provide occurence typing for data. Since library authors often tend to reduce their dependency surface, most libraries do not ship with it though.
With the inclusion of this in clojure core, it will now be possible to provide occurence typing at the edge of functions instead of tracking malformed input deep inside apps.
The racket-type contract notation is also a very welcome change from other similar approaches in my opinion.
Agreed that this is a big step, but what is being included in core is very distinct from Prismatic Schema. For example the way keysets vs values are handled is intentionally different from schema.
Yes, I've read and see the difference from schema.
The huge advantage with this, is that even though the approach is different, it supersedes schema's abilities and it will be a require away for every library and application author.
We also owe the OpenBSD team OpenSSH, which greatly benefits from their attention to detail and commitment to small improvements towards better security.
Of course software is never perfect, but it's nice to know the (small) subset of OpenBSD developers working on OpenSSH are still working on keeping the proverbial doors locked.
Yes, the OpenBSD team's willingness to roll up their sleeves for software that I consider core to a functional Internet is pretty remarkable. Even though the last OpenSSL vulnerability also affected LibreSSL, in the past others haven't.
EDIT: Morning brain made context shift unclear. They do OpenSSH and now LibreSSL. Also pf and more too.
It was mostly in use when TLS hadn't made it's way into most common protocols