bartbes

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

Easily solved by just keeping some state:

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

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.

It's always hard to read such light grey text, I misread it as "giving them our private keys".

Which is why certificate signing requests contain only the public key.

Bit disappointing that it mentions a script that produces a bridge, then never names it or links it.

That's 40 gigabit limited, I suppose.

The owner of HutHos does appear to be female, so that may be related?

It's really only relevant when specifying multiple targets, like 'make clean all', or the more common 'make all install'. It just seemed odd to me.

Then I'd like to bring to your attention that you can have the @ come from a variable too, which means you can have conditionally silent files too. That always seemed to me like the perfect middle ground between silent compiles and knowing what's going on if things do fail.

I realise their standard probably doesn't include all, but it seems like the obvious choice. Maybe I've just been conditioned by autotools, but I think it's standard practice to have all be your default target.

It's interesting how they list targets that have "practically become a convention", yet they're missing "all".

I'm also intrigued by their claim they used @ in the recipes, yet they never did.