ash

2 out of 3 meerkats look in the same direction. Enough for consensus.

It is harder to maintain two networks instead of one. Potential problems double. Hacks like RFC8305 "Happy Eyeballs" become a must.

Unfortunately, individual actions would never be enough to solve the IPv6 chicken and egg problem. See djb's "IPv6 mess" article:

https://cr.yp.to/djbdns/ipv6mess.html

Yes, it is old, many examples are outdated, but the main points still hold. Decades later his suggestions for making IPv6 succeed are still not implemented.

Have you tried "Smaller binaries" instruction? https://tailscale.com/kb/1207/small-tailscale

The article by Ory's Aeneas Rekkas perfectly describes OAuth / OIDC problems. The only thing it misses is the suggestion for the alternative protocol for first-party auth. It does suggest that it's preferable to use simpler systems like Ory Kratos. But OAuth / OIDC is a set of protocols, not an implementation. Is there an a effort to specify simple auth protocol, when third-party auth is not needed?

Less secure that HttpOnly cookies, which are not accessible by third-party JavaScript. LocalStorage also doesn't have automatic expiration.

Cool project!

OAuth-based auth providers are nice, but they can have a weakness. When you have just one app, OAuth can be overkill: protocol is complex, and users suffer jarring redirects¹.

This is not surprising, because OAuth / OIDC is fundamentally designed for (at least) three parties that don't fully trust each other: user, account provider and an app². But in a single app there are only two parties: user and app itself. Auth and app can fully trust each other, protocol can be simpler, and redirects can be avoided.

I'm curious what OpenAUTH authors think about it.

¹ Except for Resource Owner Password Credentials (ROPC) grant type, but it's no longer recommended: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-secur...

² In addition, OAuth is mostly designed for and by account providers, and follows their interests more than interests of app developers.

Thank you! The video is a criticism of that article.

As someone outside of the field I don't follow your argument. The author stated that the problem is not just in the analog nature of quantum computer, but in the impossibly large amount of analog parameters to process and also to correct errors in.

Interesting observation about the maximum lifetime of a bubble:

I believe that, appearances to the contrary, the quantum computing fervor is nearing its end. That's because a few decades is the maximum lifetime of any big bubble in technology or science. After a certain period, too many unfulfilled promises have been made, and anyone who has been following the topic starts to get annoyed by further announcements of impending breakthroughs. What's more, by that time all the tenured faculty positions in the field are already occupied. The proponents have grown older and less zealous, while the younger generation seeks something completely new and more likely to succeed.

That IEEE published this surprises me

I find your reaction to be a positive sign. The sign that IEEE is willing to push envelope of knowledge (as of 2018). One can't push it without taking a risk of publishing something wrong, possibly very wrong.

I don't have any opinion on this topic, it's not my field of expertise. However, it's the first semi-technical article about quantum computing that I can follow along and understand.

f-strings are great, except for the `=` debugging operator

What's wrong with `=` debugging operator in f-strings?

there are hundreds of users hundreds kilometers away, all working via Tailscale

Do you require your users to install Tailscale?

I don't find it persuasive. First of all, people are not going to start writing and saying wildcards. Second, there is an established convention to say "2000s" and mean 2000-2009.

The article does not really resolve the ambiguity with 2000s which usually means 2000-2009, not 2000-2099.

That said, in Finnish language people never count centuries. It's always "2000-luku" and "1900-luku", not 21th and 20th.

In the article Dyson retells the story from Pupin's autobiography. This 1923 Pulitzer-winning book is now out of copyright and freely available: https://www.gutenberg.org/ebooks/66886

It’s too much. I want my stuff to always work, without weird “Fix me” buttons.

Very good article! One of the gems from it:

If you buy an NVIDIA GPU, you do not get a document explaining the instruction set. It, and many other parts of the architecture, are secret. If you want to write code for it and don't want to use NVIDIA's toolchain, you are expected to generate PTX, which is a somewhat portable intermediate language that the NVIDIA drivers can consume. This means that NVIDIA can completely change the instruction set between GPU revisions without breaking your code. In contrast, an x86 CPU is expected to run the original PC DOS (assuming it has BIOS emulation in the firmware) and every OS and every piece of user-space software released for PC platforms since 1978.

What's TC?

This line is only triggered for /hide action.

does auth contains a CSRF token?

Yes, it looks like it does. Also, the vote auth param is different for every link.

What is the logical fallacy here?

The 2017 law changed the way software development expenses are counted for tax purposes. 2023 taxes are the first taxes this rule affects.

Details:

https://www.onlycfo.io/p/new-tax-rule-is-terrible-for-softwa...

The author does cover this point, further in the thread.

An example:

A company has $1.2M in revenue; and $1M in costs (let's assume all costs are employing devs fulltime).

Before 2022: the profit of the company is $200K. Pays corporate tax on this.

In 2022: the profit of the company is $1M (of the $1M in salaries paid for devs, this needs to be amortized over 5 years: so $200K can be amortized for the year). Need to pay corproate tax on this. But the business might not have this much cash on hand, and so needs to borrow at a high interest rate. MASSIVE change!

... and so now companies are incentivized to have as little R&D expenses as possible (aka fire fulltime devs doing R&D, unless they can front the 5-year spread).

https://twitter.com/GergelyOrosz/status/1735037956438523984

Fines are often gamed: lobbying, legal defence.

I would argue big companies care more about losing customers. Сompetitive pressure is more effective than laws and fines. And laws are not without downsides, including becoming barriers to entry into competition.

Yes, in the context of JSON handling by JavaScript. I meant string keys that can be interpreted as non-negative numbers. Those are traversed first, the rest of the keys are coming in insertion order. For example:

    > JSON.stringify({'one': 1, '3': 3, 'two': 2, '2': 2, 'three': 3, '1': 1})
    '{"1":1,"2":2,"3":3,"one":1,"two":2,"three":3}'

SQLite JSONB does maintain order: https://news.ycombinator.com/item?id=38547254

There are situations where keeping order is useful. For example, human-editable json config files.

I also gave an example of two implementations that are compatible for a useful subset of keys. By the way, SQLite JSONB keeps object keys in insertion order, similar to Python: https://news.ycombinator.com/item?id=38547254

What about SQLite JSONB? Does it maintain order?

UPDATE: I think SQLite JSONB does maintain order. For example:

    select json(jsonb('{"a": 1, "b": 2, "c": 3, "d": 4}'));"
    -- {"a":1,"b":2,"c":3,"d":4}

    select json(jsonb_insert(jsonb('{"a": 1, "b": 2, "c": 3, "d": 4}'), '$.e', 99));
    -- {"a":1,"b":2,"c":3,"d":4,"e":99}

Javascript environments ... guarantee that they'll preserve object key order when JSON is evaluated

Yes, but only for non-integer keys.