sudo is not GPL3. It is not even GPL2. It is an old license that is just as permissive as the MIT license. It has never had any big problems with that being the case. I don't think that coreutils being GPL has really done anything to force companies to contribute back to it. It is mostly fixed in its function and does not really have much room for companies taking and modifying it to a point where others will favor the closed version over the open on. And what it provides is fairly trivial functions overall that if someone did want to take part of it then it is not terribly hard to rewrite it from scratch.

GNU Coreutils is not the only implementation of those POSIX features - just the most popular one. FreeBSD has its own, there is busybox, the rust ports and loads of other rewrites of the same functionality to various degrees. None of that really matters though as they dont really add much if any value to what coreutils provides as there is just not that much more value to add to these utilities now.

And it is not like the GPL license of coreutils affects other binaries on the system. So if you dont need to modify it and it does not infect other things there is little point in trying to take it over or use an alternative.

MacOS does not use a later version because they cannot. But also they don't care enough to even try to maintain their own.

GPL is important on other larger/more complex bits of software. But on coreutils/sudo IMO it does not matter nearly as much as people think it does.

Anyway, yeah why would I watch someone else play a game when I can just play it myself?

I think some of it is watching people do things you cannot do. Competitive play, in both sports and gaming, is quite a different thing to watch people with skill vs what you could do yourself. Plus I suspect there is a lot of the psychology that goes with routing for a team and the feeling of being part of something bigger or something.

Personally I don't really get it myself but I can see why people would. IMO it is not much different from why so many people like watching sporting events rather than going out and playing themselves.

For games I haven’t played yet, I would spoiler it for myself. Games I’ve already played… well, don’t need to watch that anymore, right?

That is true for single player games, but not for match making/competitive ones. I suspect that people are more so watching competitive ones than single player story driven games.

The only other major thing for repairability/upgradability would be less glue on the battery and threaded inserts, which doesn’t add size.

The glue was reduced on later versions and especially on the OLED version which also got threaded inserts. So those are already done and I doubt the next version would regress in that regard.

Functions do something, while properties are something.

This is my argument against them. Computed properties do something, they compute a value. This may or may not be cheap and adds surprising behavior to the property. IMO properties should just be cheap accessors to values. If it needs to be computed then seeing a function call can hint the caller may want to cache the value in a variable if they need to use it multiple times. With properties you need to look it up to know it is actually doing work instead of just giving you a value. That is surprising behavior which IMO I dislike in programs.

Or wait for rust to support the extra languages. With LLVM adding new architectures or projects like gccrs. But all of these options are a way out and rust will remain device driver only for a long time I suspect - it is still experimental after all. I would hope that as rust in the kernel matures so do the available architectures that rust supports.

People said the same thing about tweet when twitter first came out.

What? Microsoft have written and released and contributed to many open source projects - they created vscode for one. They are even one of the top contributors to the Linux kernel.

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.

It is not that tricky if you shift your perspective. Rather than thinking about files importing files (like you would in other languages), think about the crate as a tree of modules. Then the rules are simple. main.rs and lib.rs are the entry points to the crate and define the root module. Other modules are nested under this and may exist in a file that matches the modules path in the tree. So a module at crate::foo::bar::baz can live in either foo/bar/baz.rs or foo/bar/baz/mod.rs. Or be defined as a inline module in the parent module (which may also be defined inline in its parent).

This also means if you know the file path you know where it will exist in the tree, a/b/c/d.rs will be at the crate path a::b::c::d.

Why look at overall statistics when you can cherry pick single instances to prove your point. /s

https://appdb.winehq.org/objectManager.php?sClass=application&iId=128

It is not rated well on winedb, although those look like old versions?. I would not have much hope in it working for professional needs . You would be better served by learning one of the more open or Linux friendly alternatives instead. Quite a few are quite good now for different needs. You would need to try them out your self to see if they meet your needs though. Which you can typically do on windows to minimise the disruption to your work flows. But be warned it can take some time to relearn them.

Yes, but this takes time and still has to work with applications that dont support it. Where Anrdoid can just force everyone that wants to create an app to use their API. So it is harder for flatpack to encourage everyone to adpot it.