mivok

It includes the flannel network plugin by default (although you can change this) and a basic service load balancer (technically not an ingress, but providing the same functionality). From the README:

> k3s includes a basic service load balancer that uses available host ports. If you try to create a load balancer that listens on port 80, for example, it will try to find a free host in the cluster for port 80. If no port is available the load balancer will stay in Pending.

Hue forces updates on you every time you go into the app if there's one available, and you can't use the app until you've updated. Granted this isn't ideal if you primarily use your light switch or an amazon echo to control the lights, and fully automatic updates would probably be better, but it comes pretty close to aggressively pushing updates.

A lot of the comments here are complaining about the last point in the article (the n00b), asking how on earth you get started if you have to have presented before in order to present. The article is telling you exactly how to do that:

- Speak at local user group meetings. Most of my local meet ups are constantly calling for speakers, and it's an excellent way to get practice at presenting in a lower stress environment. It's not always small audiences either, I've seen and given talks with 50 or more attendees at a local meet up. As for getting accepted, organizers are always in need of talks, and organizers are not getting 6 submissions per month, they're usually lucky if they can fill every month with a talk, so you're much more likely to be accepted.

- Maintain a blog. Writing articles on your blog is practice for writing a talk, and gives you a steady stream of ideas that can be turned into a presentation fairly easily.

I'm going to add a couple more:

- Give a lightning talk at conferences you attend. As well as giving you practice, you are also visible to all the attendees, including people who will be selecting talks at future conferences you submit to.

- Submit to smaller, more focused or more local conferences. You can't expect to be accepted at huge popular conferences speaking in front of hundreds of people on your first try. Submitting to more focused conferences gives you a better chance of being accepted.

These steps aren't going to make it so that you're immediately accepted at large conferences, but they give you the start the article is claiming you need. And finally, if you're rejected, don't give up. Conferences do take chances on new speakers (although probably not all new speakers who submit a talk), and being rejected doesn't mean your talk is bad, or that your skills are bad, just that you didn't get it this time.

Micro HDMI. You have to go to the technical details tab to see it mentioned.

Even shorter/easier to remember version of the command (you don't have to specify the filename twice if you don't want):

    curl -T ./filename transfer.sh

Make it support PUT instead of POST with a file form field and the command becomes simplified to:

    curl -T filename http://curl.io/send/abc123

If the clients trust the npm CA, can't they just sign the digicert CA with that CA and include it in the certificate chain provided by the server? That way the chain would be:

    npm CA -> digicert CA -> any other intermediates -> server cert

Clients that only trust the digicert CA (and other standard CAs) will see that and accept it because they trust the digicert CA, and clients that trust the npm CA will trust the cert also, allowing both old and new clients to work. Once (almost) everyone has upgraded, the npm root CA can be removed from the chain presented by the server. Am I missing something here?

Edit: It looks like what I'm missing is that you'd need the private key of the digicert CA to generate the request to sign with the npm CA. I was thinking about how CAs have been migrated in the past (e.g. equifax to geotrust global CA). It looks like it won't work in this case.

Edit2: Actually, it appears to work after all. I just tested with the openssl ca command, and you give it -ss_cert instead of -in for the certificate to sign a certificate instead of a request.

Then the receiver reports to the sender that the link didn't work. The sender, not knowing if the password was compromised or if it was a situation you mentioned above, changes the password/revokes the key and generates a new one. This time, the receiver doesn't access it at closing time in Starbucks/doesn't switch tabs, and gets the new password correctly.

Unexpected behavior doesn't happen every time.

As an optimization, if you have a self hosted service of this sort that gives proper logs, you can probably verify that the link wasn't intercepted by looking at the source IP and comparing to what the user reports (if they're able to do that, if not, you fall back to assuming it was compromised), and if so, skip the revocation/regeneration procedure.