YouTube design changed almost every year until 2020! Wild.

"empathy" "right" "help" "hope" "same"

None of those words appear in the article. I can deduce that the author of this article would never return a wallet. If they are this perplexed at the good deeds of others, and need to turn to science for a reason, they are as dense as a brick.

Reasons:

- because kind strangers have empathy

- because kind strangers want to do what is right, and help others

- because kind strangers would hope the same thing is done when they lose their own wallet

You would likely enjoy Myst: https://www.gog.com/en/game/myst_masterpiece_edition

Related HN thread: https://news.ycombinator.com/item?id=18058991

Are you testing performance with pgbench or something more custom/advanced?

I briefly searched and couldn't find it either - here is the IMDB for others to reference: https://www.imdb.com/title/tt0605181/

Lines with actual code changes aren't a problem for me, it's the automated IDE indent/spacing/bracketing that really drives me up a wall and fatigues the hell out of me.

But this might only be a problem with those of us working on legacy codebases. The kind of PRs I see in OSS projects I could review 1000 lines at a time - it's so clean!

Split the reformatting and real change. Make the reformatting change first and have a policy of merging those change fast.

Some teammates agreed to do this, but it's not known what files will be edited ahead of time, so a large job often has formatting edits anyway.

Yeah, it's really something that you have to get buy-in for.

You could always make a commit that just has the reformatting when you do start editing a file. If it turns out you didn't need to edit that file after all, then you can revert just that commit easily. And if you did, you can collect up all the reformatting commits into a PR as a first step.

The flip side of this is making minimal surgical small changes, and then doing the refactoring after the change. The key message though is split them.

Refactoring doesn't change behavior, so refactoring efforts should be judged only on "tests exist that cover the functionality, those tests continue to pass, the code is easier to maintain". It's when you add "changed functionality, so we changed the test" to review at the same time, that this becomes a hassle.

Better than commenting "paywall blocked" is to provide an archive link: https://archive.is/vH7vF

I liked “like magic it is unlocked” better ;)

they messed up by blocking icloud relay in an ill guided vpn spam prevention implementation, archive.is useless

And yet when I click the link, I can read the article.

Oh it’s not an infinite recaptcha loop anymore, ok glad the implementation is a little better

That was a DNS problem with cloudflare.

It bit Mozilla users harder because Mozilla uses "DNS over HTTPS" to cloudflare itself, ignoring your system DNS. There's a setting to change that but you have to enter "DNS" in the "setting search" to get it.

I too can click the link and read the article. It’s only useless if I close my eyes.

I imagine some OSS authors don't consider someone visiting the GitHub readme before visiting their website. I can't fathom thinking like that, but it must have never crossed their mind.

Here's the screenshots: https://stellarium.org/screenshots.html

The PDF is worse, so there is no simple answer to this: https://arxiv.org/pdf/2312.12907v1.pdf

At least the HTML version pairs each author with their affiliations, instead of the PDF which has all the names on page 1, and all the affiliations on page 2. That's completely unreadable.

The PDF is better because I'm trained to scroll past the author list. That takes forever on the html version .

You can click the "Introduction" anchor on the left side and it scrolls for you past the author list

well it skips the abstract too, but yes, you can scroll back up to see it.

Yeah, its a bit weird that the abstract doesn't have a link on the left

Probably because \abstract{ } is treated differently than \section{ }, I guess...

For me the PDF is much better. It's compact and clean, if I really need to see an affiliation for a particular author, it's really easy to do so in the PDF, not so in the HTML.

It's highly unlikely anybody will read an entire author list this long; typically you would read the first two or three names, or check if some particular name is on the list. So the compactness of the list and being able to quickly get to the article contents is important.

Any advice/ideas/articles/references on using kustomize efficiently?

I love the idea of using a tool bundled with kubectl for zero dependencies, but their examples and tutorials are horrible. I can't figure out how to use it correctly to have 1 copy of YAML that would deploy to 5 different environments. It seems I would need multiple copies of kustomization.yaml in multiple folders, if I have multiple namespaces/pods/etc...

The model is base yaml with patches applied to it results in final yaml that get sent to the api, so the typical structure for us is to have the base yaml live with the service source, be maintained by the service owners and include all environment-agnostic properties. We then have one folder per targeted environment for that service which includes any patches and the kustomization.yaml manifest. Basically in line with what other replies have mentioned.

Thanks everyone that replied, I thought I was doing something wrong!

Not a kustomize expert - but yes, you likely would have a folder for each thing you target.

It wasn't bad once I got through the docs / examples. They just assume so much existing knowledge I didn't have.

We use kustomize with multiple copies of kustomization.yaml and I don't know if there is a way to do it without that. Basically, there's a base kustomization.yaml and then there's test/kustomization.yaml, prod1/kustomization.yaml, prod2/kustomization.yaml, and so on.