pyritschard's comments

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

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.

Hey, Exoscale CTO here,

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.

I expect the situation to change over time, OpenBSD has invested a lot in working well with KVM which most providers are relying on now anyway.

OpenBSD also has cloud-init support now[1] which makes interaction with terraform and ansible much simpler.

While the big three do not have officially supported templates, a few providers do, including Exoscale (disclaimer: CTO there).

[1]: https://github.com/exoscale/openbsd-cloud-init

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

The code has just landed [1]. It's not a .cljc file yet, but fingers crossed this becomes a thing at some point.

[1]: https://github.com/clojure/clojure/commit/3394bbe616c6202618...

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.

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.

[1]: https://github.com/plumatic/schema

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.

This is something we struggled with at Exoscale, I took the time to do a small write-up of how we approach reset requests here: https://www.exoscale.ch/syslog/2016/04/13/i-lost-my-2-factor...

paper.li

The essential point the lengthy article makes revolves around debugging facilities for unikernels. While mostly true for MirageOS and the rest of the unikernel world today, OSv showed that it is quite possible to provide good instrumentation tooling for unikernels.

The smaller point about porting application (whether targetting unikernels that are specific to a language runtime or more generic ones like OSv and rumpkernels) is the most salient, it will probably restrict unikernel adoption.

For docker, if only to provide a good subtrate for providing dev environments for people running windows or Mac computers, it is very promising.

I co-founded it :-)

I'm very happy to see riemann featured here. I've been using it in production since early 2012 and contributed to it (intensively, at one point) as well.

It's been a breeze, rather worry free and its very good collectd support has enabled us to cover very interesting use cases at Exoscale.

You're a bit harsh, last one was 28 days ago :-). To be honest, except for the big chunk of work that signature v4 represents, the lack of commit/releases stems from the fact that it has been stable.

While not 100% necessary, header macros to implement lists, queues (and even trees, see: http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/sys/sys/tree.h?...) are common in C.

They first appear for kernel usage where the fact that they expanded to inline code in functions avoided creating too many stack-frames and provided optimization.

They do have the advantage of not relying on casting everything to "void *" or resort to callbacks for walking (see: TAILQ_FOREACH for instance).

hi mike, we actually do have mysql available and PG is on the roadmap. https://www.exoscale.ch/add-on/mysql/

hey, exoscale CTO here. As mentioned in another post, we are doing a special pricing for startups and SaaS businesses available here: https://www.exoscale.ch/pricing-target/ and we encourage you to try the service out with the WELOVEHN coupon for extra initial credit.