Since closed-source is frowned upon in the Linux world
Indeed, this is a root cause of the problem. But it is a problem. The Linux community needs to get off its high horse and make distribution of binary programs (which may or may not be open source) work properly.
Snap and Flatpak are definitely a step in the right direction at least.
Right but in practice nobody really uses the Windows store, and winget, chocolatey etc. are only used by geeks. For normal users it's always
Download .exe or .msi
Double click it.
Follow the instructions.
On Linux you have:
apt, dnf, etc. - pretty reliable but only really work from the command line (I have yet to use a "friendly" store frontend that actually works well), and you almost always get an outdated version of the software.
Snap or Flatpak - the idea is there, but again I have yet to actually use one of these successfully. They always have issues with GUI styling (e.g. icons not working), or permissions, or integration or something.
Compiling from source - no Windows software requires this but it's not uncommon on Linux.
Also it's relatively common for Linux software not to bundle its dependencies. I work for a company that makes commercial Linux software and they bundle Python (yes it's bad), but that depends on libffi and they don't bundle that. So it only works on distros that happen to have the specific ABI version of libffi that it requires. And you have to install it yourself. This is obviously dumb but it's the sort of thing you have to deal with on Linux that is simply never an issue on Windows or Mac.
Reliable hardware support. Especially on laptops - as far as I know it's still basically impossible to get battery life as good in Linux as in Windows/Mac.
Sane software distribution method that actually works reliably.
All settings accessible via the GUI. The terminal is still the default for most things. For example google how to disable SELinux (something most users should probably do). You have to edit /etc/selinux/config which is really quite complicated for "normal" users.
I think those are the main things. I think it would also help if KDE were the "default" desktop environment instead of Gnome. It's much better, with one caveat - they seem incapable of good visual design! Don't get me wrong, it's a lot better than when KDE 5 first came out, but there are still very obvious spacing issues, and Gnome never has those.
Really tempting but you can get such good computers second hand these days. I got a Ryzen 9 3950X (a few years old but 16 core and still awesome), with 128 GB of RAM and a 1TB SSD for £325. No way I'm paying 6 times that for a new machine that's 50% faster at best.
lib.rs has a special surprise when you search "twitter"
Yeah also calling anything where you raise your hand a "Nazi-like salute" is dumb af. Musk does enough real shit without having clutch at straws like this.
The only rule you need is: preserve history that is worth preserving.
99% of the time, that means you should squash commits in a PR. Most commits should be small enough that they don't need more fine grained history than one commit.
I will grant a couple of exceptions:
Sometimes you have refactorings where you e.g. move a load of files and then do something else.. Or do a big search and replace and then fix the errors. In these cases it's nice to have the file moves or search/replace in separate commits to a) make review easier, b) make the significant changes easier to see, and c) let git track file moves reliably.
Sometimes you have a very long lived feature branch that multiple people have worked on for months. That can be worth keeping history for.
Unfortunately, if you enable merge queues on GitHub it forces you to pick one method for all PRs, which is kind of dumb. We just use squash merges for everything and accept that sometimes it's not the best.
I don't think anyone disputes that, it's just that nobody has come up with anything better.
Take home exercises were a potentially better option (though they definitely have other big downsides) but they aren't a sensible choice in the age of AI.
Just taking people's word for it is clearly worse.
Asking to see people's open source code is unfair to people who don't have any.
The only other option I've heard - which I quite like the sound of but haven't had a chance to try - is to get candidates to do "live debugging" on a real world bug. But I expect that would draw exactly the same criticisms as live coding interviews do.
I don't have a particular story. A lot of industries use "competency based questions", you know "tell us about a time when...".
They're awful. If you don't know what I'm talking about count yourself lucky.
Which would you rather, "write some code to filter off numbers from a list", or "tell us about a time when you worked with someone difficult. How did you win them over and subsequently become best friends?".
Some bad interview questions are like that, sure. But they're supposed to be things you are very unlikely to have done before and can reasonably figure out. It's not too hard to come up with simple questions like that. (Though I will grant many people don't seem to bother.)
IMO this is not a helpful way to put it. They measure skill under stress. Stress may have a large effect on skill level for some people but highly unlikely that it's so large that performance is completely random.
Yeah I've seen Nix and Guix suggested but they seem like a huge extra layer of complexity.
Also, strict backwards compatibility in APIs is totally worth it. It makes developing larger systems so much easier.
Usually not for first party code. It adds extra maintenance burden for little benefit.
For example suppose you want to add an extra parameter to a function. In a monorepos you just do that and fix all the compilation errors. Send one PR through CI. Job done.
With submodules... You have to add a new function so it's backwards compatible. Deal with a default value for the old call, maybe add a deprecation warning. Oh and you need to version your library now. Then good luck finding all the places that function is called and updating them...
You have to tediously git submodule update --init --recursive every time you checkout a commit. There's an option to do it automatically but it's super buggy and will break your .git directory.
Switching between branches that have different sets of submodules doesn't really work. Git won't remove/recreate the submodules like it will for normal directories. Worst case is changing a directory to a submodule or vice versa.
If you're working on a feature that spans several submodules you have to switch branches in all of them instead of once.
Making co-dependant changes across submodules is a nightmare.
If you're using submodules for first party code (not uncommon), it basically creates a new public interface where you didn't have one before. Now you have to worry about backwards compatibility and testing becomes much harder. Monorepos don't have that problem.
The list goes on... Some of them depend on exactly what you're using them for.
The slightly frustrating thing is that there isn't a great answer for what to use instead. Git subtree has its own problems. Language-specific package managers do too. There aren't any good languages agnostic package managers I know of.
I'm really hoping Jujutsu will come up with a better solution because it is possible. But it's hard, and they are constrained by Git compatibility so I won't hold my breath.
Phoronix has notoriously dumb commenters. I don't know why exactly but it's really notable.
Hackaday too. Again, not sure why. They're both significantly worse than Reddit, HN, Ars or here. Maybe even worse than YouTube comments...