ralphm

Well, most of western Europe stayed on CET after World War II. Initially the Nazis forced this upon The Netherlands, Belgium, Luxembourg and occupied France in May 1940, including DST. Double summer time! As The Netherlands was on Amsterdam time before the war, it went from +00:20 to 02:00 in one go. Spain followed as a gesture of political solidarity. DST remained year round until 1942.

After the war DST was abolished again, and then reintroduced in 1977 because of the energy crisis.

There has been talk about having permanent (double) summer time again, but the problem is that in winter, sunrise would be around 10 am.

Besides what MattJ100 wrote above, by itself this is also not true. You can tell Android to not optimize Conversations and allow it to run in the background. It will work just fine with a (usually idle) TCP connection. But for the typical user, having to instruct them to do this is cumbersome, and integrating with Firebase is easier. It does come with its own concerns w.r.t. privacy, both for the payload as well as metadata exchanged.

I expect it is 27W to support 9V 3V, not because of tolerances per se. (Source https://www.sparkfun.com/products/23583)

Because wages are non-Gaussian, standard deviation doesn't mean anything in this context.

Hence the suggestion for PagerDuty. It handles all this, because responders set their notification methods (phone, SMS, e-mail, and app) in their profiles, so that when in trouble nobody has to ask those questions and just add a person as a responder to the incident.

Why every time? Isn't this a user config that overrides whatever default there is?

Except that Luna in Slavic and Latin just share the same ancestor in PIE.

As far as I know, Facebook Messenger's XMPP support was only exposed to clients (c2s), not to other XMPP servers (s2s). Microsoft's Lync (now known as Skype for Business) supported XMPP federation until 2019. WhatsApp's client protocol was originally based on XMPP. I'm reasonably sure that both AIM and Yahoo had XMPP server-to-server support ready around 2008, but can offer no proof.

In this Dutch article (https://www.rtlnieuws.nl/nieuws/buitenland/artikel/5191916/d...) it is suggested that they didn't use two-step verification because it would be cumbersome for his campaign team.

Whether or not this is true, Twitter definitely needs to start having multi-user functionality. Beyond TweetDeck Teams.

If services are indeed doing, or moving to, end-to-end encrypted media, there's nothing the server can do here.

Yup, and the old bridge will keep working locally, still has an open API, and there was an upgrade program when v2 was introduced, with a 33% discount. Four or so years ago.

Google Search used to have such a feature. I used it to blacklist w3schools. Of course, the feature is no longer there.

How so? That page says Marseille Soap is made from vegetable oils, whereas the recipe in the article uses animal fat.

Earlier:

https://news.ycombinator.com/item?id=16964112

https://news.ycombinator.com/item?id=16802079

Blendle has stopped pay-per-article, moving to subscriptions entirely.

The original article (https://www.washingtonpost.com/nation/2019/07/26/it-snuck-up...) includes links to some interesting background information, including the event leveling a huge forest area. And it correctly uses square km/miles instead of "square acres".

Yeah, I considered this a feature. As mentioned elsewhere in these comments, we should have a way to limit the scope of corporate certs.

I hope they pin on the key, not the certificate. For a mobile app I worked on, I had it pin the public key on the leaf certificate and indeed it would fail to connect in this scenario.

For mobile apps, though, you can bootstrap HPKP with a key built into the app. I worked on an app doing this, and it would certainly fail to connect in this scenario.

I think the point here is that if you use semantic elements, you don't need to use classes to differentiate.

For U2F there's nothing to be in sync: each key is added individually, and you don't have to add all of them at once. I.e. if you register the key on your keychain at work, you could later add the backup key in your home vault.

For storing TOTP keys on your YubiKeys, those must be the same, so you probably have to add them at the same time, or take a picture of the QR-code before you complete the registration.

The desktop version of Yubico Authenticator (yubioath-desktop) allows for storing TOTPs on YubiKeys in Linux and OS X, too.

I like having TOTPs stored this way, as you can use them with any device, including over NFC on Android, just by installing the Authenticator app.

Is this not a valid approach then? The issues of ossification and strict allowance for just known protocols appear to be big enough to cause things like SCTP to not have a viable, widespread use in their future.

You misunderstood what's happening here. A rogue server can request the client to read any file on the client's file system, and the client will comply without validation that the client actually requested this.

Back in the early 90s, I learned the vi movement keys through hunt(6) from the BSD Games collection. Can't find a good link for the package, but here is the man page: https://www.unix.com/man-page/bsd/6/hunt/

RCS is a standard on which development started in 2008 and was built upon the core of another standard called IMS, which started development in 1999. The same year the jabber.org project was announced.

The battery argument is just misinformed. The real reason Google dropped XMPP was not a technical one. Yes, Google claimed it was not "cloud ready" at that GoogleIO. The same one where they announced Google Cloud Messaging, based on, wait for it, XMPP.