TimWolla

> Why is that the case [...]?

This is explained in the "Encryption" section: https://borgbackup.readthedocs.io/en/stable/internals/securi...

The important part is the part about avoiding re-use of the AES CTR value.

> Simultaneous updates happen quite often.

Personally I created a dedicated borg repository per machine I want to backup, because that avoids sharing passphrases across machines. This comes with the drawback that I cannot deduplicate across machines, but that is acceptable to me, because the data is mostly unique-ish anyway. I only backup the user data, not everything (e.g. /bin/).

The author uses a systemd timer to schedule their backups. For backups going to a remote host I prefer adding a little bit of variance to the execution time to avoid consistently hitting some hotspot.

From the timer I use to backup my server using Borg to rsync.net:

    [Timer]
    OnUnitActiveSec=24h
    RandomizedDelaySec=1h

This will run the backup script every 24 hours with a random delay of up to 1 hour, so every 24.5 hours on average. This causes the job to nicely rotate around the day.

I previously used Tarsnap, but I moved to using Borg on rsync.net. Borg can do all the stuff Tarsnap can do and comes with 'borg prune' included. In fact for Tarsnap I would have needed to write a custom script to perform regular pruning.

By relying on rsync.net's automated ZFS snapshots I get the same or similar protection compared to Tarsnaps's write-only keys.

For my personal use case cost wasn't an issue, though. It's less than 10 GB of data stored.

> and it’s a small but growing segment

They could have grandfathered the existing accounts into the 2000 minutes. Then the segment would no longer be growing and stay small, no?

The SMTPUTF8 RFC to support non-ASCII local parts is from February 2012 and thus fairly new [1]. Postfix supports it since July 2014 [2] and to the best of my knowledge Dovecot still does not yet support SMTPUTF8 for LMTP.

Personally I did not enable SMTPUTF8 support in my Postfix due to the lack of Dovecot support.

[1] https://tools.ietf.org/html/rfc6531 [2] http://www.postfix.org/SMTPUTF8_README.html

They are not based on X.509. I recommend taking a look at the CERTIFICATES section of the ssh-keygen man page, because I am unable to find a good reference on the web right now.

I gave my reasoning back on the HAProxy 2.0 announcement: https://news.ycombinator.com/item?id=20198232

Oh hi! That was me [1]. I'm a community contributor, but I'm equally impressed by the speed patches get merged on the mailing list.

[1] https://github.com/haproxy/haproxy/issues/123#issuecomment-5...

And the best thing is Cyril Bonté’s configuration.txt to HTML converter: http://cbonte.github.io/haproxy-dconv/

In fact AppArmor was only "recently" enabled by default in Debian starting with Debian Buster: https://www.debian.org/releases/stable/amd64/release-notes/c...

> huh how well does that work with individual downloaded *.deb packages?

You can `apt` to install `.deb` files on the local file system using:

    apt install ./path_to_the.deb

Duplicate of this: https://news.ycombinator.com/item?id=22366280

They appear to have change something in the past few minutes. When I first opened this HN thread it showed me Google's homepage. Now I'm also seeing that redirect.

The 'Y' is mentioned in this blog post: https://lars.ingebrigtsen.no/2016/09/06/gmane-alive/

I can second Hetzner. In my case with their dedicated offering, though. Been running mail servers there since at least 2013 with next to no problems.

Google sometimes put mails into the spam folder, though not in recent times. Microsoft tends to block unused IP addresses by default, there's a Wiki page on how to request an unblock: https://wiki.hetzner.de/index.php/Microsoft_Blacklist/en

I sign all my emails using DKIM and have good domain reputation.

> I believe most clients renew certs ~10 days in advance.

The recommendation and the time certbot uses is 30 days.

Yes, exactly. Here's an example for a repository hosted on my server and in Keybase Git. Pulls / Fetches will use the repository on my server. Pushes go to both.

    [timwolla@/s/xxx (master)]g remote show origin
    * remote origin
      Fetch URL: git@git.example.com:xxx.git
      Push  URL: git@git.example.com:xxx.git
      Push  URL: keybase://private/timwolla/xxx
      HEAD branch: master
      Remote branch:
        master tracked
      Local branch configured for 'git pull':
        master merges with remote master
      Local ref configured for 'git push':
        master pushes to master (up to date)

Tags are going to be ugly, but branches can simply be merged like any other.

Alternatively you decide the one of the repositories is the primary one, set up a remote called `mirror` and set-up a `post-receive` hook to:

    git push --mirror mirror

Now just ensure no one pushes into the mirror directly. Of course this only works if you control the primary repository.

You mean like?

    git remote set-url --add --push origin git@github.com:Foo/bar.git
    git remote set-url --add --push origin git@gitlab.com:Foo/bar.git

:-)

see: https://git-scm.com/docs/git-remote#Documentation/git-remote...

I already noticed that after the workspace selector looked different Slack was no longer being regularly killed by the OOM killer. Finally.

see: https://news.ycombinator.com/item?id=20499070 and https://news.ycombinator.com/item?id=20498983

see also: https://news.ycombinator.com/item?id=20498983

see: https://news.ycombinator.com/item?id=20499070 and https://news.ycombinator.com/item?id=20498983

Or the status is automatically being updated once a certain percentage of requests fail in e.g. the last 5 minutes, thus introducing a bit of delay.

Not all repositories / profiles are affected for me. And for repositories not all pages are affected.

e.g. https://github.com/typeorm/typeorm/ is accessible, but the commit list at https://github.com/typeorm/typeorm/commits/master is dead.

GitHub is sending 500's on repositories and user profiles as well: https://github.com/DefinitelyTyped/DefinitelyTyped / https://github.com/TimWolla

> in which case is there your own registry where you maintain docker images ?

Please note that I'm a community contributor. I am not employed by HAProxy Technologies and I cannot speak for the open source project in any official capacity either.

You probably remember the nbproc [1] setting which indeed is multiple, unrelated processes. There's proper threading now (since 1.8).

[1] http://cbonte.github.io/haproxy-dconv/2.0/configuration.html...

> As of RIGHT NOW, haproxy has not updated it's official docker image and has 6 day old docker images which docker hub flags as having vulnerabilities (screenshot at https://imgur.com/a/SiYoZzc). So I'm a little hesitant at calling this release "Cloud Native"

1. The “official” Docker image is not maintained by HAProxy itself. “Official” refers to being blessed by Docker. See: https://github.com/docker-library/official-images#what-do-yo...

2. The vulnerability scan of Docker Hub is bogus: https://github.com/docker-library/faq#why-does-my-security-s...

3. There's a pull request created by me to switch from 2.0-rc to 2.0: https://github.com/docker-library/haproxy/pull/89. I created it immediately after learning about the release. Any further delay is caused by the Docker Official Images team.

Disclosure: I'm a community contributor to HAProxy and I help maintain the issue tracker on GitHub. I also maintain a few “official” Docker images and by that I know the process.

Apart from a few new warnings for long-deprecated options it is compatible. HAProxy 2.0 is not a major version. Willy apparently just dislikes two-digit versions in the second place.