nous

While true and some will do it for that reason, I bet most do it simply because the friction to forking is so low.

Some might have an intention to work on it but then don't or might start looking at it in detail then give up or get to busy or lose interest.

Others might just click it to save it for later.

And don't forget all the people that click it by accident.

It's not like it is a big investment to click the button.

Probably something to do with their main package deleting the pacman lock file so it can run a nested pacman update command... Which means two pacman instances running at the same time and nothing stopping other ones after that nested one has completed.

If everything is highlighted, nothing is highlighted.

Kinda ironic given the whole site looks like someone attacked it with a highlighter.

I have more then once gave up on pressing up, hit ctrl + c to reset only to see the command I wanted briefly flash up as I am hitting ctrl + c

Important part from the article, not all VPNs are equal:

Instead, the authors recommend using paid VPNs, which are generally considered to be more reliable and secure. For example, no serious privacy or security issues were found with Lantern, Psiphon, ProtonVPN or Mullvad.

VPNs are not a magic bullet. They are at best a transfer of trust from your IPS - which in a lot of cases you have little to no control over and also very little trust in.

Picking a well trusted VPN can improve things, picking a bad one can make your situation worse. And there are more important things that you need to worry about first before a VPN will really help at all.

I personally hate global menu bars. They do not work with focus follows mouse. The way menus currently work is fine for me and I would not want to lose that to, IMO, a much worst system. Any global menu implementation would need to be able to be disabled and better to have it off by default. And I would rather see effort in developing other features personally - though mostly as I would never use this feature.

* in your commands is expanded by the shell before tar sees them. It also does not expand hidden files.

So when you do admin/* the shell expands to all non hidden files inside admin. Which does not include admin/.htaccess. So tar is never told to archive this file, only the other non hidden files and folders. It will still archive hidden files and folders nested deeper though.

In the second example * expands to admin and the other does which are not hidden at that level. Then tar can open these dirs and recursivly archive all files and folders including the hidden ones.

You can see what commands actually get executed after any shell expansions if you run set -x first. Then set +x to turn that off again.

Here is an example using ls:

$ set -x; ls -A foo/*; ls -A *; set +x
+ ls --color=tty -A foo/baz
foo/baz
+ ls --color=tty -A foo
.bar  baz
+ set +x

You never want build artifacts to be committed. You don't want to have everyone working on your project to need to setup their own gitignore for every project. So it makes sense to have a common commited gitignore for files the project produces that should never be tracked by git.

I dislike when people put in editor files in the gitignore though. People should setup global ones for their local tooling.

What are you talking about? Capitalists love the free market. It lets them do any underhanded tactic they want to crush competition and form monopolies. Capitalists have always been the ones pushing for a free market. The 'free' is free from regulations. That is not something good for consumers.

There are quite a few downsides to what the author proposes as well that they did not consider. If you store code in an intermediary format then every tool that needs to interact with that code needs to understand that language. Back when ada was out that might not have been a big issue. It has a dedicated IDE, lots of languages did. There was no real source control either, at least not like today.

To do that today, does not matter if the source is some binary format or minified it would need to be understood and processed by so many different tools. Just the source control alone, GitHub, bit bucket, gitlab, etc, all editors and idea, simple cli tooling like grep and sed. All would be much more of a pain to work with.

IMO it is much nicer to just work with a nicely formatted code to start with. And have your editor auto format things so you don't need to think about it. Then all downstream tools don't need to care about or understand the language you have chosen to use.

When there is a gold rush, be the ones selling the pickaxes. If the companies behind the models could make a profit using their models then why would they be selling them so freely?

It also lets you checkout, cherry-pick, rebase or merge work on other branches without needing to sync between the local clones.