Seems kinda pointless to compile most packages unless there are specific performance optimizations or non-default features that can be enabled. I think the way I would use this would be to do binary by default and build only on the occasional instance there is a tangible benefit.
The optimization might just be the rather large battery. Usually laptops with U-series processors have 40-60Eh batteries, the spec sheet shows a 73Wh battery in there.
It was originally designed for massive storage servers (“zettabyte” file system) rather than personal laptops and desktops. It was before the current convergence trend too, so allocating all of the system resources to the file system was considered very beneficial if it could improve performance.
The phoronix forums are insanely toxic. Everything is bad. Gnome = kid’s toy. systemd = written by Satan himself. Every programming language = too slow. Anything vaguely interested in fostering a diversity, equity, and inclusion = true colors come out in full force.
It’s so toxic yet I subject myself to it every now and again. There’s absolutely no moderation going on and it shows.
On that page you linked, they say “So far, the EU’s reach has not been tested, but no doubt data protection authorities are exploring their options on a case-by-case basis.” So it hasn’t really been tested yet it seems. It’s true that there are extradition treaties and interpol that aid in cross-border prosecution, but that tends to be used primarily when the alleged crime happened in the prosecuting country’s jurisdiction, or the alleged crime is handled similarly in both countries. A GDPR violation by a US company wouldn’t be considered a crime at all in the US, so it’s entirely possible that they might decline to assist in prosecution.
That’s a really interesting point, has it been tested in court? The article is about US companies and US websites so I figured EU law was irrelevant, but I am curious to see if the EU can claim jurisdiction for actions foreign companies take outside the EU, regardless of if they have any official EU presence.
Subpoenas are tools the government uses to compel a private entity to provide information. This isn’t that though, this is one private entity asking another private entity to just give them data. It’s not a legal case, and because of our non-existant privacy regulations in the US, Reddit is free to just hand over this information, or not if they want. No crime has to even be alleged, Reddit can just hand that information out.
It’s not quite the same though. With a custom android ROM, you can be pretty confident that everything kernel-and-up is not spying on you. On iOS and macOS, you don’t have the same level of verifiability, as the OS could just circumvent any VPN/firewall you might have configured. They might pinky promise not to, but without running another external firewall it’s not really verifiable.
I agree, and GitHub allows choosing how to merge each PR individually if you need to do something different for a specific PR. Large PRs like that are at most 1% of our total PRs, and we review those more per-commit and use a merge commit instead of a squash. By default we optimize for the other 99%.
I think the idea here is that reviewing individual commits is irrelevant if the plan is just to squash it all down. Each PR corresponds to a single change on the main branch in the end, the fact there was a main commit followed by a half size “fixed typos” and “fixed bug” commits doesn’t actually matter since it will be blown away in the end. The process results in the same clean history with good individual commits on the main branch, just as if the user squashes those commits locally before pushing it up to the code review platform.
Well squash and merge isn’t default or pushed in any way. It’s an option, and we chose to enable it ourselves because that’s what works best for us. It’s what works well for many other projects too, which is why many choose to enable it instead of the default merge commit.
GitHub has an option when merging a PR to “squash and merge”. This option squashes all of the commits on the PR branch into a single commit and cherry-picks it on top of the base branch. We use this by default in our open source projects at work. Most people are not gonna go through the effort of making a well defined patch series the way it would be required for a Linux kernel contribution. Most changes aren’t that big though and so it doesn’t really matter. Send as many commits as you want in the PR, I’ll just review the diff as a whole and squash it when I’m done. Workflows should adapt to user preference, not the other way, and this is a good example of that.