poolpOrg

plakar developer here, thanks :-p

All I can say is that I'm flattered you considered my cat blurb to be a poem, I might revisit my career

Thanks :-)

I may be biased but the OpenBSD approach with pledge() and unveil() have been my favorite sandboxing mechanisms of all time due to their simplicity: pledge has really understood that as a developer I want to whitelist an intention, not a specific set of syscalls and options, and unveil is chroot on steroids <3

Oh !

An ISC-licensed implementation of several Content-Defined Chunking algorithms in Golang at https://github.com/PlakarKorp/go-cdc-chunkers

Whenever you have redundant data you want to store / transfer, this library lets you perform fast content defined chunking

We will publish a comparison but I'm cautious as it can easily look like an attack over what others do and I feel strongly about not being hostile to other open-source projects :-)

Long story short: we provide multi-source/multi-destination/multi-storage (ie: backup S3 to disk, restore to SFTP), we have a nice UI, we reimplemented our own database over CAS allowing us to have a virtual filesystem + a ton of nice features on top of the snapshots, + an archive format of our own and other nice features.

All of this is in the free version, what's going to be paid is plugins to backup commercial services, enterprise features like multi-user support, ACLs, or compliance related features (ie: GDPR / sensitive data detection, ...), backup orchestration over a pool of machines, and more.

Working on `plakar` (https://github.com/PlakarKorp/plakar) an opensource backup utility and all of its related libraries and tools :-)

We've recently released a new archive format called ptar, it can be found on HN if interested :-)

Thx

oh, that's not meant to stay that way.

first, we're going to release pre-built binaries for various platforms with our next stable release which will remove the need to install a go runtime as you'll have a standalone native executable for plakar / ptar.

then, the format is open and we'll publish a friendlier documentation should someone want to implement their own builder/reader.

finally, it's likely we'll publish a library + standalone executable in C, so that people can easily implement a binding to their favourite language and/or have a small executable in a language that traverses the decades :-)

Author here, plakar is a single binary, unsure I understand what it is you’d prefer, a ptar specific executable?

Sorry, removed the article because it was a draft not meant to be published yet, I didn't think someone would spot my drafts directory... :-)

Will finish and republish in a few days.

IT architect, lead unix system dev, R&D

  Location: France
  Remote: full
  Willing to relocate: no
  Technologies: BSD, Linux, C, Python, Go, SQL, ...
  Résumé/CV: https://github.com/poolpOrg/resume/blob/master/resume.en.pdf / https://www.linkedin.com/in/gilleschehade
  Email: gilles@poolp.org

Hello,

Main developer from the OpenSMTPD project here.

I also wrote an article a few weeks ago about running your own mail server which is located here:

https://poolp.org/posts/2019-09-14/setting-up-a-mail-server-...

I'm an opensmtpd developer.

As far as opensmtpd is concerned, it is production ready and has been used in high volume environments sending mails to millions of recipients daily, handling multi-million queues.

The project was started in 2008 so when it comes to being run in production environments, I think we can claim that it's ready :-)

Now as for the what you would gain, I won't do proselytism, we have published a couple presentations on our website which describe how it works and some of the technical details behind it. You will also find lots of technical details on my blog where I post mostly about OpenSMTPD internals.

If you have a running Postfix, I suggest you don't shift but keep your working setup. If you intend to setup a new MX, you should definitely give a try and see how it goes for you.

It is useful, it helps fund the infrastructure, it helps fund hackathons, it helps hosting hackers during the events, it helps bringing developers who would not make it because they wouldn't afford the transportation, it helps getting hardware needed to write new drivers, etc, etc, etc...

As far as I'm concerned, a single week of hackathon achieves far more than months of individual work on the side, and the hackathons take place because the foundation can bring many developers together in the same place at the same time thanks to the donations it receives :-)

I need to stop with the padding, it's going to evolve into a nasty compulsive disorder at some point :-)

No, he didn't.

As much as he'd like to make it like we don't fix bugs, our public bug tracker is one click away and shows that out of the 25 open issues and the 493 closed issues, none mentions even remotely a pending crash that he is experiencing. He does have some feature requests and bugs though, with many handled already, so it seems that he does knows where to find it when he needs to.

As for his concerns, yes he did tell me, he sent me 16 mails yesterday, including the one with the trace. Unfortunately, he sent it past midnight, at about the same time he made it public because he just couldn't wait until morning to disclose.

As an OpenBSD/OpenSMTPD developer, I feel I should ask:

What makes you think that if I wasn't spending _MY_ spare time working on projects I like, I'd spend _MY_ spare time working on projects _YOU_ prefer ?

I work on projects because I need them and want to work on them, not because someone else feels I should do it. You say that you suspect a developer wrote code because it could be done and you disagree with that attitude, but I'd argue that there's much more to be said about the attitude of people thinking they are entitled to decide what _VOLUNTEER_ developers should do with _THEIR_ free time...

I'm biased but as far as SMTP is concerned, you can hardly find something simpler than OpenSMTPD: pretty much any configuration can be described in less than 10 lines of config.

Here's my configuration on this desktop:

listen on all

accept from any for domain debug.poolp.org deliver to maildir

accept from local for any relay

thanks ;-)

It is already available as a package on various Linux distros: Gentoo, Arch, Fedora, ... as well as all BSD variants.

That's not quite right.

I've had an intensive use of CVS for years, followed by an intensive use of SVN for years.

During my CVS years, I never ran into an issue. ever. We can all agree it lacks many useful features but it's also as easy as it can get and it does not corrupt repositories. Calling it "broken" is far from truth.

During my SVN years, I can recall two repository corruptions which no matter how they occurred, just should not have. I think one was related to a bug in the db(3) backend, the other I dunno as I was not in charge of the repository. So... "superior" is debatable.

Nowadays I mostly use Git and CVS, both for different purposes and both making sense in their own purpose. I would not be so affirmative about technologies because you only know so much from your experience and use-cases ;-)

currently, the only way to achieve this is through a dkim-proxy or an experimental filter in OpenSMTPD-extras.

we have recently finished an API for implementing filters and we're working on stabilizing the interface before making it public.

so there's a bug if someone is tempted to modify it and break otherwise correct code ?

i'd be tempted to say that we can apply the same logic to about 100% of code ever written.

and still, it was totally worth it and I would do it again :-)

I agree it's not that difficult and prior to OpenSMTPD I've been a user of Postfix for 10 years, so I know the software is good and far easier to setup than the big S. ;-)

However, here's a better example of a configuration that is simple with OpenSMTPD and slightly more complex on others:

    listen on em0 tls cert "mycert" enable auth
    map "vmap" { source plain "/etc/mail/virtual" }
    accept from all for virtual "vmap" deliver to maildir
    accept for all relay

That is a fairly basic setup that quite a lot of people use, yet the effort required to achieve similar setup on other software can range from just "slightly irritating" to "extremely painful". Here it's done with 4 lines that are almost readable by someone who has never used the software.

Some other features like relaying through remote MX that require auth; tagging; forcing secure channels; allow more complex setups while retaining the same simple syntax.

/!\ warning: as a major contributor to OpenSMTPD, I'm biased ;-) /!\

nope, by default rules have "safe" implicit behavior:

accept for all relay -> accept from local for all relay

to create an open relay one has to explicitly:

accept from all for all relay