On the other hand, many things attributed to chance are actually the aggregate effect of other people's choices. If we make choices based on not just what's best for ourselves but what's best for all of us, we will all suddenly become more "lucky". And vice versa, if we only think about ourselves that luck will diminish.

I was thinking something very similar as I read the letter and hear people talk about luck in a similar way. I think attributing things to luck, while seemingly humble, can be dismissive and/or simplistic. Yes, we're all lucky to be in our situations -- living in this time, fed, privileged. Though, whether this luck is experienced positively or not is entirely subjective. Also, to ascribe our given situation to luck dismisses the concerted efforts of all living things of this time and past that have guided us to our current situation -- once again, without qualifying it as good or bad. It is almost disabling in it's message. The flip side is that many things happened that were dreamed, planned, intended, and carried out to land us in our situation. This to me feels more empowering, hopeful, appreciative, and also responsible than casting off as merely luck.

I prefer the word opportunity in a lot of those situations.

Sure there's luck in whether or not you get an opportunity but spending the whole day on twitter complaining about _ isn't going to give you any ....

I was searching for what to answer people who attribute everything I’ve done to luck. There’s the classic “It’s strange because the more I work the more I’m lucky”, but that’s very condescending. Thank you for offering me a positive alternative. In a sense it makes me owe work to my society.

I think it's more correct to attribute what you receive to luck, rather than what you give.

On the other hand, if you received nothing in return for your work, would you do it?

Again, this is the filthy accusation that people have scammed their way.

You’ve written one reasoning-in-absurdum, now write the opposite side.

No, it is not an accusation.

If you accept that the world is not "just" (just-world-fallacy), then you will also believe that rewards are indeterministic. It follows that rewards are attributed to luck, while effort and results are (by definition) not.

There is no accusation of dishonesty in this argument, and no need to feel accused of scamming.

(One point is that people who persist longer, receive more awards because the "area" under their luck-curve is larger. And people who have lots bad luck in the beginning get discouraged and stop trying ...)

That's a nice point. A society where everyone makes everything just a little bit better for the next random person will be a society full of nice surprises, rather than nasty ones.

So an answer to the prisoner's dilemma would be a shared belief in doing good? Interesting.

Western Europe (not only) social system is based on such belief. It kept working till a lot of immigrants from pretty bad corrupted countries came in, abusing the system in ways it wasn't planned for.

So it works, sometimes, on limited populations.

It certainly helps when you all look alike and share other similar values.

> not just what's best for ourselves but what's best for all of us

One can paraphrase the Summary of the Law (Luke 10:25-37) as, Seek the truth; face the facts; seek the best for others as for your self.

Couldn't agree more. Many (most?) of our opportunities are afforded by the family, community and society in which we grew up. Of course individual talent and choices make a difference, but it's my feeling that many people wildly underestimate how much their external life circumstances contribute to their success or happiness. In fairness, it goes against our sense of self-efficacy.

Like a lot of things recently, it reminds me again of Timothy Snyder's book On Freedom. I think the world would be on a much better path if more people took its core message to heart: that your "freedom" in how to lead your life is not just an absence of oppression, but something made possible for you by an entire society collaborating on giving others these opportunities, by maintaining infrastructure, education, emergency services, etc. etc.

I like the thought experiment of considering how much of your current life's comforts and liberties you would still have if you lived as a hermit in the woods. Nobody tells you what to do there, but you'd quickly find out how much your luck depended on society.

Being able to buy my food at the supermarket instead of having to go hunt and forage for it every day gives me a lot of additional energy and time to exercise other freedoms.

You're lucky to have that perspective.

What are you trying to say with this, that you disagree, or that it's an intelligent perspective afforded to those who are not hopeless? I don't see how anyone can disagree that the aggregate actions of your parents, your locality, your culture, your nation, play the largest role in the cards you are dealt from the beginning.

> If we make choices based on not just what's best for ourselves but what's best for all of us, we will all suddenly become more "lucky".

I personally know handful of extremely lucky people who spent their entire lives doing the exact opposite of this

I think the point is that this only works in the aggregate. Individuals in a group/organization/society can make small positive decisions that improve the likelihood that any individual in that same group will get "lucky".

There's a sort of "freeloader" problem, though, which is that the ones who get "lucky" don't themselves have to be making positive choices. In fact, being a selfish individual in a group of generous ones can be an easy way to get ahead - as long as you can get away with it without being noticed or punished.

The point is not that individual luck plays no part. It's about what your environment offers you as a baseline, not accounting for individual luck.

I don’t disagree but there is also an immense impact of random, pure luck outside of any environment that plays a huge part in many lives

I read it as in alignment with the previous definition of luck; meaning that a number of previous conscious decisions have created a world where they could come to this understanding of luck

I think it's hard to put into practice, but the veil of ignorance is an interesting philosophy for this

And AFAIK there is still no upload progress with fetch.

Nice to only have to push the layers that changed. For me it's been enough to just do "docker save my-image | ssh host 'docker load'" but I don't push images very often so for me it's fine to push all layers every time.

Yes, it is because of NATO. They've been thinking about it for some time, but NATO tipped the scales.

Please do share some links to these events, because this is the first I hear of it.

Sure, but TOTP still defends against password leakage. So it’s still more secure than only using a password.

Why are they using any language at all? Why not just let the app maker open the payment screen directly?

Same (perceived) reason my bank and brokerages (and I think even my kid's school website does this) pop up a warning every time I click on a link that will take them outside their website.

I think there's a valid reason to think "if it's OK and common for banks and brokers to do it, it's OK for me to do it" and also to think "this will help protect users from being scammed by other apps who might pop open random links without any notices".

There is probably nothing whatsoever the judge could have done about this action by itself. The issue is the conversations around it, which established intent. The chat logs provide hard evidence that it was done in bad faith and with criminal intent.

Now that I think about it, I wonder how much of the current backlash against remote work is to avoid this exact situation. Face to face conversations don't end up in evidence. Written conversations do, and video chats are increasingly being summarized and recorded by AI.

But in this case, it's not taking the user out of Apple's website. It's taking them out of Epic's app into Epic's website.

You and I both know the underlying reason Apple wants to do this.

The fig leaf reason is “it’s an app we approved and we need to protect our customers.”

From a positive point of view: so that app makers can't open up malicious payment screens. Of course, I don't think there's anything stopping them now.

From a more negative point of view, so Apple knows how much it happens and gets to have some influence over it.

Because users will then blame Apple when they get scammed.

There are a lot of websites that give you a warning when you click on a link outside of their control.

But this is from a non-Apple app. You’re already on a page outside of Apples control.

I have my parents use iOS because they couldn’t help themselves from downloading malware on Android. It wasn’t from Google, but it didn’t matter, because the whole Android system’s reputation was reduced because of it.

Allowing third party payment systems does not mean they have to be less strict in the rest of their app vetting process.

> Performance is a frequently cited rationale for “Rewrite it in Rust” projects. While performance is high on my list of priorities, it’s not the primary driver behind this change.

Is performance a frequent rationale for rewriting C applications in Rust?

No - unless the rationale was taking better advantage of multithreading, which Rust does make easier.

But that's at least partially a maintainability argument, not just a performance one. Rust can make achieving higher levels of performance easier and less risky than doing so in C or C++ would have, but you do still have to work for it a little, it's not going to be magically faster.

I think that's only generally true for the period of time where the new tool has yet to achieve full functional parity with what it replaced. As that functionality gap is closed, the performance increase usually declines too.

One counter example:

    $ curl -LO 'https://burntsushi.net/stuff/subtitles2016-sample.en.gz'
    $ gzip -d subtitles2016-sample.en.gz
    $ time rg -c 'Sherlock Holmes' subtitles2016-sample.en
    629

    real    0.099
    user    0.063
    sys     0.035
    maxmem  923 MB
    faults  0
    $ time LC_ALL=C grep -c 'Sherlock Holmes' subtitles2016-sample.en
    629

    real    0.368
    user    0.285
    sys     0.082
    maxmem  25 MB
    faults  0
    $ time rg -c '^\w{42}$' subtitles2016-sample.en
    1

    real    1.195
    user    1.162
    sys     0.031
    maxmem  928 MB
    faults  0
    $ time LC_ALL=en_US.UTF-8 grep -c -E '^\w{42}$' subtitles2016-sample.en
    1

    real    21.261
    user    21.151
    sys     0.088
    maxmem  25 MB
    faults  0

(Yes, ripgrep is matching a Unicode-aware `\w` above, which is why I turned on GNU grep's locale feature. To make it apples-to-apples.)

Now to be fair, you did say "usually." But actually, sometimes, even when functional parity[1] has been achieved (and then some), perf can still be wildly improved.

[1]: ripgrep is not compatible with GNU grep, but there shouldn't be much you can do with grep that you can't do with ripgrep. The main thing would be stuff related to the marriage of locales and regexes, e.g., ripgrep can't do `echo 'pokémon' | LC_ALL=en_US.UTF-8 grep 'pok[[=e=]]mon'`. Conversely, there's oodles that ripgrep can do that GNU grep can't. For example, transparently searching UTF-16. POSIX forbids such wildly popular use cases (e.g., on Windows).

I've been using ripgrep for years now and I'm still blown away by its performance.

In the blink of an eye to search a couple of gigabytes.

I just checked and did a full search across 100 gigabytes of files in only 21 seconds.

The software is fantastic, and moreover it goes to show what our modern hardware is capable of. In these days of unbelievable software waste and bloat, stuff like ripgrep, dua, and fd reminds me there is hope for a better world.

w00t!

I don't think rg speed can be attributed to Rust.

ripgrep gains comes from a ton of brilliant optimizations and strategies done by it's author. They wrote articles about such tricks.

> I don't think rg speed can be attributed to Rust.

I didn't say it was, and this isn't even remotely close to my point. The comment I was replying to wasn't even talking about Rust versus C. Just new tools versus old tools.

> ripgrep gains comes from a ton of brilliant optimizations and strategies done by it's author. They wrote articles about such tricks.

I know. I'm its author!

oh hi burntsushi! Good thing I applauded your skills to... yourself, without realizing. haha

I was replying to this:

> Is performance a frequent rationale for rewriting C applications in Rust?

But I now realize your message was much more specific so I stand corrected with regards to context. Your point was indeed different.

:-) <3

Not necessarily so. Sometimes a better architecture and addressing long-standing technical debt give large permanent gains. Compare yarn vs npm, or even quicksort vs bubble sort.

It's also easier to do things in parallel in rust that might otherwise not have been considered in a C version.

And using more efficient algorithms or data structures that are painful and/or difficult to use in C.

Is that because of the Rayon lib?

It can be, but just plain multi-threading in rust is a lot easier to work with (correctly) than it is in C - just using stdlib and builtin features of rust.

No. It's normally memory safety and/or ease of tooling/coding/whatever.

It might be a rationale for a rewrite and rust is just the language the people doing the rewrite wanted to use.

I think it's often a rationale for choosing rust over other languages once you've decided to rewrite.

No I don’t believe so

But vscode doesn’t just let you edit files on the remote, it runs everything on the remote: extensions, terminal commands, etc. If you’re working on a web project, it forwards ports so you can still visit localhost in your browser, even though your dev server is running on the remote host.

Yeah it's like fully virtualized to run the same familiar environment completely on a local machine. It's not even remotely comparable. Extremely necessary in many cases like thin clients for machine learning

Where is the Remote SSH extension code? I always thought that was closed source?

Edit: The reason I think it is closed source is because a StackOverflow answer says so[1]. I’d be very interested in seeing the code if you could link to its repo!

[1] https://stackoverflow.com/a/55979526