And other browsers can be configured to do the same. Though that is not ublock origin doing anything with the cookies and these settings can be enabled wtihout ublock (though you likely want ublock if you are enabling them).

I don’t think it does anything with cookies directly. It just blocks connections to domains and removes elements from pages that match patterns you give it. Removing the cookies/privacy banners does just that - removes the banner. This SHOULD opt you out of tracking as the laws generally require explicit permission, so not clicking the accept button should be enough. But if the sites follow those laws or not is a completely different matter.

Third party tracking cookies are normally blocked by their domain - when a tracking pixel is on the screen it reaches out to a known tracking domain which logs this visit and drops a cookie for that domain on the page. By blocking that domain the tracking request is never made and thus no cookie is dropped and so there is nothing to track you. Most tracking is done like this so it is quite effective. But it wont stop a first party cookie from being dropped or tracking done through that or any other data you send.

Note that the laws don’t require permission for all cookies. Ones that are essential to the sites function (like a cookie that carries login info) are typically allowed and cannot be opted out of (you can always delete cookies locally though, the laws just cover what sites can use). And not all sites will respect these laws or try to skirt around them so none of this is 100% perfect by any means.

This does not work for everyone. A lot of people will try to switch, but find one tool they are used to they cannot now use and are not used to the alternatives so feel frustrated when trying to use them for real work. Then get pissed off at Linux and switch back to windows.

This advice is more for people that are thinking about Linux but have some professional or semi professional or hobby workflow on their computers that they need to be productive in. It can be very hard for them to switch os and tooling they are used to with no way to fall back to what they know when they need to.

You will find most people don’t rely on these tools and they can doba quick check and decide to switch straight away. But ignoring this advice for the rest can make transitioning to Linux easier.

We need to stop pretending that switching tools that you rely on and have spent decades learning to be proficient in is a trivial task for everyone.

This is an absolute terrible post :/ I cannot believe he thinks that is a good argument at all. It basically boils down to:

Here is a new feature modern languages are starting to adopt.

You might thing that is a good thing. Lists various reasonable reasons it might be a good thing.

The question is: Whose job is it to manage that risk? Is it the language’s job? Or is it the programmer’s job?

And then moves on to the next thing in the same pattern. He lists loads of reasonable reasons you might want the feature gives no reasons you would not want it and but says everything in a way to lead you into thinking you are wrong to think you want these new features while his only true arguments are why you do want them…

It makes no sense.

But no one actually pulls that rule through, do they?

They do though. Loads of new people to programming read that book and create unreadable messes of a code base that follow all of his advice. I have lost count of the number of times I have inlined functions, removed layers of abstraction and generally duplicated code to get a actual understanding of what is going on only to realize there is a vastly simpler way to structure the code that I could not see until all the layers and indirection are removed. Then to refactor again to remove redundant code and apply more useful layers again that actually made sense.

And that is the problem we have with his book. People that need it take up as many bad habits as they do good ones leading to an overall decline in their code quality. It is not until years of experience that you can understand the bad bits and ignore them. So overall his book is a net negative on the programming world. Not all his advice is bad, but if you can tell that then you likely don’t need his advice.

But on the layers of abstractions specifically, he takes this too far. Largely because of the 4 line limit he has. There is a good level of abstraction and I generally find more than 2 or 3 levels of abstraction is where I start to loose any sense of what is going on. He always seems to jump on abstraction as soon as he can, but I find waiting a while and abstraction when you need to to lead to fewer and vastly better layers of abstraction overall.

And adding more abstraction does not help the people of people doing too many things inside a function - they just move it to sub functions rather than extracting the behavior for the caller to deal with. I have never seen him give advice on what that is appropriate, only keeps the functionality of the original function the same and move the logic into a nested function instead and that only covers up the issue of the function doing too much.

But I feel like Uncle Bob is leaning more towards that if a task requires 100 different operations, then that should be split into 100 different functions. One operation is one thing. Maybe not exactly, but that’s kind of vibes I get from his examples.

Oh yeah he defiantly does. He even says so in other advice like a function should be about 1-3 lines. Which IMO is just insane advice.

I kinda disagree with him on this point. I wouldn’t necessarily limit to one thing, but I think functions should preferably be minimal.

I do actually agree with him on that point - functions should do one thing. Though I generally disagree on what one thing is. It is a useless vague term and he tends to lean on the smallest possible thing a thing can be. I tend to lean on larger ideas - a function should do one thing, even if that one thing needs 100s of lines to do. Where the line of what one thing is, is a very hard hard idea to define though.

IMO a better metric is that code that changes together should live together. No jumping around lots of functions or files when you need to change something. And split things out when the idea of what they do can be isolated and abstracted away without taking away from the meaning of what the original function was doing. Rather than trying to split everything up in to 1-3 line functions - that is terrible advice.

One of the big problems with this is there is no global shortcut for copy and pasting. At most there are the primary, secondary and selection buffers which applications can copy into and paste from. But each application handles the copy/pasting functionality in their own way. Or rather they typically let the toolkit they are using deal with it.

Klipper, the kde clipboard manager comes close to something like what you want. You can CTRL+C multiple times and it stores a history of everything, then you can assign shortcuts to cycle through the entries and paste them out again. All it is really doing is reading the clipboard when it changes, saving that value than essentially copying from that saved list when you cycle though it. So it would be possible to write something similar that has specific numbered buffers - but you would still be saving/loading into the primary clipboard which applications can then paste from rather than creating a new set of shortcuts to paste from each buffer directly into an application.

I did not find it very had to relearn the difference in bindings. Quite a lot are actually the same but one big difference is the selection before action rather than vims movement then action. Which IMO I find the helix way nicer after using it for a while. Never really lost the ability to use vim either and I can switch between them with relative ease. Though I do miss the helix way of working when I am forced to use vi input on things.

Not in any bothersome way. But if you really want to reinstall often that is valid as well. You can very easily script the arch install process to get you back to the same state far easier than other distros as well. Or you can just mass install everything except base and some core packages and reinstall the things you care about again which almost gives you a fresh install minus any unmanaged files (which are mostly in home and likely want to keep anyway).

Any major Linux distribution has a system for building packages

I have built packages for all the major ones. Non arch packages are a pain to build and I never want to do it again. In contrast arch PKGBUILDs are quite simple and straight forward.

How can you trust code with root access to the system just because it’s in the aur repository?

Because you can view the source that builds the packages before building them. A quick check to not see any weird commands in the builds script and that it is going to an upstream repo is normally good enough. Though I bet most people work on the if others trust it then so do I mentality. Overall due to its relative popularity it is not a big target for threats when compared to things like NPM - which loads of people trust blindly as well and typically on vastly more important machines and servers.

I use it precisely because it doesn’t break all the time and is less restricting… Don’t know where you got the idea it is not.

I’ve tried NeoVim but I really don’t want to waste time doing text-based configuration and messing with extensions just to get some basic features working.

This is the reason I switched to helix. Comes out the box with what you would expect so you dont need 10s of plugins and 100s of lines of config to get a base line experience.

What non-profit company did you get the computer you are currently using to type these messages from?

By “forever” they mean you will be paying them forever for the privilege of using the mouse. Unless you break it that is, or they feel like they no longer want to support it at which point it will likely become a forever brick.

You can have backups of physical books. Just copy the text from one to the other. Yeah it is manual work but so is writing the first one in the first place. You can then store the second copy in a fire resistant safe or at a friends or family members house (maybe inside a safe as well).

That should not break things though. Maybe get a merge conflict that you need to sortout at worst. This is essentially the constant state of working with other people on a project.

And cherry-pick commits done on different work trees without syncing them first. Or rebase or mergeworkk done on one work tree with others. Or check commit logs or diff them.

I have started using work trees recently as well, but have a different flow to the author and everyone else. I typically use two work trees, one on main that I do all my work on. That is work and create commits directly on the main branch.

But then to push I have another clean work tree that I use to create and switch branches on then use that to create working sets of changes by cherry-picking from master into different branches to push and create PRS from. And never edit files on this work tree so that I never have to stash anything.

Then just git pull --rebase=interactive origin/master to remove merged commits from master as they get merged upstream. This let’s me build on pending PRs or switch to other tasks at will and just sort them into separate PRs as required.

I like this as when working on a feature I often find a refactoring I need to do, so can isolate that refactoring and create a PR with only that change while continuing to work on the feature on top of the PR.

Or have some temp debugging stuff locally that I want to use across changes that will end up in different PRs without having to copy paste them between branches.

I have never had git get into a state I cannot get out of. Even if that is a reset, checkout or clean. And those are very rare. How are people breaking things so often.

Learn the tools you use daily, it saves you a lot of headache in thelong term.