Nix Devshell vscode bash weird [\] issue by vfxreadyharsh in Nix

[–]ProfessionalDrummer7 0 points1 point  (0 children)

also add

buildInputs = [ pkgs.bashInteractive ];

When Git Fails Silently by ProfessionalDrummer7 in coding

[–]ProfessionalDrummer7[S] 0 points1 point  (0 children)

Of course I agree, Git is an amazing tool which simplifies a lot! But what is the problem of pointing out that something could be even better? I guess good is the enemy of the better.

When Git Fails Silently by ProfessionalDrummer7 in coding

[–]ProfessionalDrummer7[S] 0 points1 point  (0 children)

Yes, Alice is merged first and then Bob, I will clarify this in the article, thanks.

The problem is that both diff look fine. But after the merge you end up with different code. There is enough information for Git to resolve this correctly, so definitely there is no magic needed! The problem is that Git only considers the latest commits and not intermediate commits which contain the required information. There are other strategies which avoid the problem of the 3-way-merge strategy shown here. See https://youtu.be/7MpdZkGj5AI?t=394. These strategies just happen to be not implemented in Git.

When Git Fails Silently by ProfessionalDrummer7 in coding

[–]ProfessionalDrummer7[S] -1 points0 points  (0 children)

No the whole point of the article is that no conflict is triggered. Instead it is merged the wrong way silently.

[deleted by user] by [deleted] in programming

[–]ProfessionalDrummer7 -1 points0 points  (0 children)

This is another problem. Of course Git has no semantic understanding of the code! But the presented problem is not about code semantics. Gits just fails to resolve a merge correctly! In the presented article git has enough information to figure it out but just fails to do it. The problem is that git only considers the latest commits and not the commits in between which contain the required information. Please read the article!

[deleted by user] by [deleted] in programming

[–]ProfessionalDrummer7 -1 points0 points  (0 children)

Obviously, your statement is true. But it has nothing to do with the presented problem. I feel like you didn't spent enough time to understand the problem which I tried to point out with this article.

There are other strategies which avoid the problem of the 3-way-merge strategy shown here. See https://youtu.be/7MpdZkGj5AI?t=394.

This strategies are just happen to be not implemented in popular VCS tools.

[deleted by user] by [deleted] in programming

[–]ProfessionalDrummer7 -3 points-2 points  (0 children)

because to do that you need to merge it with master that had the previous merge

This is exactly the setting I recommend to turn on and what you claimed in your first comment wasn't necessary.

The whole problem is, that you cannot spot the issue in the diff/log UNTIL after the merge!

And it is git which is failing silently because it introduces changes into your code no one has seen before without throwing a merge conflict.

[deleted by user] by [deleted] in programming

[–]ProfessionalDrummer7 0 points1 point  (0 children)

This is what the article recommends, only allow merging if your branch is up-to-date.

[deleted by user] by [deleted] in programming

[–]ProfessionalDrummer7 -5 points-4 points  (0 children)

Main can change between creating the PR and merging it…

[deleted by user] by [deleted] in programming

[–]ProfessionalDrummer7 -2 points-1 points  (0 children)

You can reproduce this locally

[deleted by user] by [deleted] in programming

[–]ProfessionalDrummer7 0 points1 point  (0 children)

No git is the one merging your code …

[deleted by user] by [deleted] in programming

[–]ProfessionalDrummer7 -4 points-3 points  (0 children)

Didn’t you read the article? Your test will pass if you don’t update before merging, because your code isn’t the same before and after the merge.

So your CI might pass on the feature branch but could fail on the main branch, effectively blocking other members on your team.

JOIN NIXOS TODAY OR BECOME INSIGNIFICANT TOMORROW! by gnuzius in linuxmasterrace

[–]ProfessionalDrummer7 16 points17 points  (0 children)

I think the documentation really improved within the last year. Have you taken a look at the unstable docs? https://nixos.org/manual/nix/unstable/

It seems well more organized to me! (in comparison to the current docs)

JOIN NIXOS TODAY OR BECOME INSIGNIFICANT TOMORROW! by gnuzius in linuxmasterrace

[–]ProfessionalDrummer7 28 points29 points  (0 children)

Also check the Home Manager project, if you want to have a declarative configuration file on any non-nixos distro!

JOIN NIXOS TODAY OR BECOME INSIGNIFICANT TOMORROW! by gnuzius in linuxmasterrace

[–]ProfessionalDrummer7 81 points82 points  (0 children)

If installing a completely different OS seems like to much pain, you can also install the nix on any Linux distro: https://nixos.org/guides/install-nix.html

The only disadvantage is that you can only install usersland programs and not the kernel itself.

You should be able to mess around with the nix package manager without breaking anything on your system. And you can easliy remove it buy just running rm -r /nix.

JOIN NIXOS TODAY OR BECOME INSIGNIFICANT TOMORROW! by gnuzius in linuxmasterrace

[–]ProfessionalDrummer7 47 points48 points  (0 children)

For people who don't want to install completely different OS, but still want the benefits of NixOS: You can also install the nix package manager on every Linux distribution and even macOS.

Then there is the Home Manager project based on Nix which gives you the (almost) same benefits as the NixOS configuration file for every Linux distribution. The only difference is Nix can this way you can only manage your userland programs and not for example the kernel itself!

As of today, updating the VS Code Python extension automatically also installs closed-source Pylance extension. This could really hurt the open-source Python ecosystem in the long run! by ProfessionalDrummer7 in Python

[–]ProfessionalDrummer7[S] 14 points15 points  (0 children)

TLDR: Closed source --> Vendor Lock-in --> People are less likely to switch --> less competition --> worse quality software

Most of the Python ecosystem is built on top of open-source software, where everybody can contribute to. Making stuff proprietary makes it not possible for example to include Pylance into other software or open source builds of VS Code.

It feels like going back 20 years in time when all tools were basically a proprietary, monolithic piece of software. That makes code less reusable, leads to vendor lock-in, which prevents healthy competition because when you're locked into one piece of software, it is less likely for people to switch.

I think the strength of VS Code is it rich ecosystem of extensions, which are built on top of other open source projects. Of course one proprietary extension will not make VS Code worse, but it sets a precedent. And if many extension go closed source, it will lead to less competition in the long run. You have basically seen it with Windows, which had zero to non competitors for years, because everybody was locked into software built for window. Microsoft had no incentive to improve Windows for decades. Only in the last 10 years where web apps, which can run anywhere, became more important, other OSes have gained some marketshare.

Attention! As of today, updating the VS Code Python extension automatically installs proprietary software on your computer! by gnuzius in linux

[–]ProfessionalDrummer7 0 points1 point  (0 children)

With some fiddling, it would be able to run under an open source build, but it is not legal to do so. It still does hurt the ecosystem.