bartbes

Sure. Here's one: https://godbolt.org/z/vWl4NE

Easily solved by just keeping some state:

    /^=====/ { inentry = !inentry; next }
    inentry

Possibly without 'next' if you want the marker lines too.

You can go to terminal-normal mode using ctrl-w N, and then you can select and yank as usual. To paste, you can use ctrl-w " <register>. Also see :help terminal.

You can load your .profile into your current shell using either '. ~/.profile' or 'source ~/.profile'.

The "key" in that sentence, the one that gets padded, is the (RSA) private key, not the AES key.

Sure, but you can revoke them without changing your password or revoking other app passwords, making it much easier to recover if they do leak.

I was honestly surprised to see all this gpg setup, yet no mention of application-specific passwords. I've been using email clients with what google now calls an "App password" for years.

Looks like it only supports the english wikipedia: https://github.com/muffinista/gopherpedia.com/blob/master/fe...

I think they mean "remove the last digit".

Thanks, I'll give those a go!

I see a lot of replies on the mail side of things, but I don't really see anything detailing solutions for calendars.

Any recommendations on "the rest": calendar, notes, contacts?

I've looked at owncloud before, but that's a fairly large-footprint php project, are there any decent self-hosted alternatives, either as a suite or as separate programs?

Something that kind of mimics the C64 experience is load81: https://github.com/antirez/load81

That was a really interesting talk, thanks for sharing!

It sounds to me like the OP is actually looking for SRV records, which are basically generalised MX records.

Why would they be blocking it? Google promotes 8.8.8.8 as the primary dns server, and, as far as I know, as long as it keeps answering, clients won't fall back to the secondary 8.8.4.4.

I just started using it (for nothing serious). I'm going to have so much fun when I rediscover this in a year or so.

As much as the keys contain public data, I wouldn't consider (but it apparently is) the list of keys with access to my github account public data. Github willingly reveals information about pseudonyms, etc.

This is a data vs metadata thing, the data is public, but who it belongs to, and what one can do with it need not be.

The rest of the blog post seems to imply the application needs to be aware this is happening anyway, so it can clear the backlog, so it may as well be in charge of this. Conveniently, this also means (setuid) root is never involved at any point, whereas it would be for your iptables solution.

A few years ago I put a tiny game in a data uri in a QR code, unfortunately I lost the QR code, but I thought it was a neat concept.

Should probably resync the title to the article, I'm guessing the guardian realised a "near miss" is a hit.

Except that doesn't change the way 'spew("hello")' is parsed, as far as I know. The 'proof' given for perl actually means you can't fully parse the file without also running it.