JelteF

I agree with the general gist if your post, but still wanted to call out the "git worktree" because that would solve the problem you're describing. It's pretty much a better version of cloning the repo twice.

ZZ is only 3 keystrokes as opposed to 4 for :x (shift + z + z = 3 and shift + ; + x + enter = 4). It also doesn't require timing the release of shift before the press of x.

Hold shift and press Z twice will also close and save. It's only three key presses instead of 4 for :x (shift + ; + x + enter)

Because then people with those allergies won't buy your product. And you want people to buy your product. So if you're sure that the allergens are not in your product, then why would you tell people with those allergies not to buy it?

If you're the sysadmin, then chances are high you can add this to the base image of all the systems you regularly touch.

Reading this gave me flashbacks to the time when I tried figuring out why my laptop keyboard was typing letters by itself randomly. Turns out the always-on-usb feature of the laptop was causing some short circuiting: https://forums.lenovo.com/t5/Lenovo-P-Y-and-Z-series-Laptops...

Honestly these are my favorite PRs to receive for my open source side projects. They are easy to review and approve. The smaller the PR the less time consuming it is for me to deal with them. Big PRs that add complex new features are also appreciated of course. But setting apart time to review them is often hard given other responsibilities that I have. And often I personally don't even need the feature that's being added.

I think simply having an image of what a solved network looks like would help a lot.

There's a way around this: Under "branch protection rules" in the settings for the repo, you can require certain "status checks" to be green before merging. This has as an added benefit that it works for allowing "auto-merge" (at the settings page of the repo).

(I work at Microsoft, but not at Github)

Making HA easier while self-hosting is definitely something that's high on our list of future improvements. I wouldn't be surprised if there will be some announcements regarding this in the coming year. One of the main issues (imo) is configuring HA for PG isn't easy, even when using regular PG. And this becomes even more complicated in the case of Citus, because you're effectively running multiple PG servers, all of which you need to configure HA for.

For my understanding about the multi-region DR capability you would want: Do you want to be able to write to the DR region all the time? Or do you want to be able to switch over to the DR region in case the main DC is down?

This is the release announcement with more details on the open sourced things and all the other totally new features: https://www.citusdata.com/blog/2022/06/17/citus-11-goes-full...

(sadly the accompanying HN submission got marked as a duplicate from this submission)

I don't think I agree that this is a duplicate of the commit that was submitted yesterday. The release of Citus 11 contains much more, than only the enterprise features that were open sourced. Also this post has a lot more details on what was actually open sourced.

This one surprised all of us on the Citus dev team, when we were reviewing what we were open sourcing. This "feature" was never intended to be Enterprise only and not having it in the open source repo was simply an honest mistake. If some open source user had asked for it I'm certain we would have also added it to the open source version. But so far no-one asked.

At least this mistake is resolved now, and no new ones like it should occur, since we will only commit to the open source repo now.

Yes, pg_dist_authinfo is an easier to use alternative to .pgpass.

And no worries about spoiling the announcement a bit. Seeing this on the frontpage of HN made my day!

Really nice seeing this commit, that I pushed this morning to Github, on the frontpage of HN a few hours later :) It's awesome that other people are just as excited about open-sourcing as we are. But if you like this definitely keep an eye on our blog[1] and/or twitter[2] for the upcoming "official" announcements. They will have a lot more info on this and all the other cool changes things that are part of Citus 11.

[1]: https://www.citusdata.com/blog/

[2]: https://twitter.com/citusdata

The "Annoyances" section of the "Filter lists" tab is where you can enable blocking of cookie banners/popups.

We have some users of Citus that are combining it with Postgis (Postgis is a big reason for many people to use Postgres). So it definitely sounds interesting to run this benchmark too. Thanks for sharing a link to the suite, I had not seen it before.

Maybe I'm misunderstanding the feature that you would like to have, but I think Citus columnar supports what you want. Citus columnar storage has projection pushdown, so it only fetches the columns that you requested in your query.

To quote from the blogpost[1]:

What are the Benefits of Columnar?

- Compression reduces storage requirements - Compression reduces the IO needed to scan the table - Projection Pushdown means that queries can skip over the columns that they don’t need, further reducing IO - Chunk Group Filtering allows queries to skip over Chunk Groups of data if the metadata indicates that none of the data in the chunk group will match the predicate. In other words, for certain kinds of queries and data sets, it can skip past a lot of the data quickly, without even decompressing it!

Disclaimer: I work on the Citus team at Microsoft, but have not worked on the columnar storage.

[1]: https://www.citusdata.com/blog/2021/03/06/citus-10-columnar-...

Pressing the "force-pushed" link works fine for me on private repos too. It could be that they fixed this recently, I only found out about this feature ~a month ago. If it still does not work on private repos for you, maybe try reaching out for support. It could be that there's some bug you're hitting.

tl;dr you can put commit hashes in the place where the parent comment put tags, and your exact use case actually has a dedicated link on the PR page.

The PR interface actually exposes this for force-pushes, but the UI discovery for this is horrible. It turns out that the "force-pushed" part in the little message in the github UI is actually a link. This link points to the diff between the old and the new HEAD of the branch.

As an example you can look at this PR:

https://github.com/JelteF/derive_more/pull/161

It has this little message somewhere down the page:

Monadic-Cat force-pushed the add-unwrap branch from e130dbe to 25235aa 4 months ago

If you then click "force-pushed" in that message you go to the "compare" page, which shows the diff between the two commits:

https://github.com/JelteF/derive_more/compare/e130dbe6b2a429...

Disclaimer: I'm a Micrsoft employee, but don't work on Github. I'm a daily user of Github though.

I've been using the following command to great effect:

kubectl apply --kustomize manifests/ --prune --selector app=myapp

It cleans up old stuff from the cluster and also allows you to split your manifests across multiple files.

European (or at least Dutch) debit cards are not Visa or Mastercard. They are either Maestro or V Pay.

These cards don't have a 16 digit card number and CVV that you can in online shops and pay with those. This has the advantage that these numbers also cannot be "stolen" and then used by criminals to buy things.

Debit cards are really just for physical payment, where you either use contactless payment or by using a PIN. For online shopping, the shops talk to the banks by using an OAuth-like API that can be used to either pay once or set up a monthly payment. There's a few different of these APIs throughout Europe, in each country usually only 1 or 2 are used. Some examples of these APIs are: Bancontact, iDeal, Giropay and Sofort

European webshops usually only support the ones in the country that they are located in, and for all others they either support credit card or bank transfers (which are free and standardized within Europe). American webshops usually only support credit cards, so that's the most common reason for people to have one.

> If your slice has a million entries, it's definitely a different story.

Searching through a map is much faster than you think. At 20 entries searching through a slice of strings is already slower than searching in a map. For ints this threshold is 100 entries. Feel free to test on your own machine, my benchmark code is here: https://gist.github.com/JelteF/1251f180966eb974d7732ea6c3d3b...

You can run it with:

go test -bench='.' -benchtime=1s slicemap_test.go

The benchmark code is based on the one from this blogpost: https://www.darkcoding.net/software/go-slice-search-vs-map-l...

After looking at that code though I didn't trust the results too much anymore, because of various issues with it. So I decided to fix those issues.

You can use Azure Arc[1] to run Citus on AWS EKS without having to manage everything yourself. Even though it's not quite as managed as Citus on Azure, it's still a quite lot easier than setting up a whole production cluster yourself.

1: https://docs.microsoft.com/en-us/azure/azure-arc/data/what-i...

You can add a small script to your project that you tell people to run the first time after cloning. Then with that script you can setup everything you want. Such as symlinks to git hooks also stored in the repo (so that they stay up to date), or set up the merge tool that you want.

For Transferwise the "Borderless account" is much cheaper then the "Send money" option. I get a price of ~46USD when I convert 10K USD to EUR (instead of the 81 when using the "Send money" calculator: https://transferwise.com/no/pricing/

Interesting post, but the code examples are completely unreadable on firefox + windows, because of the CSS color: #333 on .hljs class.

https://imgur.com/tUnlwWa

Have you tried one of the newest generation headsets? Supposedly the higher frame rates counter motion sickness quite well. I haven't had anyone mention motion sickness when playing on my Valve Index (only when looking on a monitor how someone else plays, because the screen shakes so much then).

(The price of the Index definitely doesn't make it mainstream though. Just trying to get a sense of this issue)

That effictively means the client cannot actually start processing the results before everything is received. Because you would have to undo everything you did with the data you received before. So basically this would simply be a non streaming version.

I think it actually might be the default. I can't remember changing that setting at least and for me it's on.