> The ARM reference design offers a guarantee that such side channels don't exist.

Nonsense. All modern CPUs have speculative execution side channels by nature. The only way to protect against these attacks is to change how we write software to insert speculation barriers in security-critical code paths.

The difference is that Intel doesn't just have speculative execution side channels, they had a pile of critical *security domain crossing* speculative execution side channels. All CPUs can leak data in speculation from your process into the side channel (which might be monitored by another process), but Intel has a pile of bugs which can leak data from *a completely different, innocent process*, or even the kernel (meltdown), or a VM hypervisor (L1TF). Those aren't inherent in CPU design, those are a result of what is clearly a major culture issue inside Intel.

> Spectre and Meltdown bed to differ.

Spectre and Meltdown are not covert channel issues. Spectre is a collection of speculative execution *side channel* issues, and Meltdown is a privilege domain crossing speculative execution *side channel* (the only one that hit other CPUs as well as Intel IIRC; other than Meltdown I think Intel has a monopoly on goofs this bad, e.g. L1TF). Covert channels are not the same thing as side channels, as they require cooperation from both sides.

Not only that, 0% of the effort has to do with the GNU part. The article title is accurate in using the term Linux. You get the kernel to run, then you grab a binary userspace from your favorite distro. Linux is what matters. The rest follows automatically because it is barely hardware specific if at all.

You only port GNU/Linux once to any given architecture. After that, all devices using the same architecture only require porting Linux to them.

Jesus, how did I manage to fuck up the links so badly. Link, link, link. And some bonus stuff.

Yes, because when I put Linux on a PS4 I certainly didn't spend several months figuring out how to write hardware-specific Linux components for the PS4.

Oh, wait, I did. I also happened to reverse engineer the Radeon GPU microcode instruction set. So now every AMD Radeon user can benefit from being able to understand what their GPU firmware is doing, which they couldn't in the past.

But hey, I guess GitHub is some shady website that serves shady black box binaries, and implementing kexec as a hot-patchable module for the FreeBSD kernel is a decidedly shady technique. Right.

Little ARM and AVR chips almost always have embedded Flash memory, and high-performance chips like x86 CPUs and mobile phone SoCs almost never do. It has to do with silicon technology. It is not practical to put Flash memory into a cutting edge silicon process for a bunch of technical reasons.

So yes, it's ROM. Mask ROM. Not writable.

IANAL, but as far as I know there is no such "exemption". You're probably thinking of Sega v. Accolade, where Sega used a trademark system to require games to have the string "SEGA" in them. That was chiefly about trademarks, not copyright. You're probably also thinking about the DMCA exemption for reverse engineering for interoperability purposes, but that is about anti-circumvention, it doesn't mean you get to distribute copyrighted data/code.

If you actually read the DMCA request, you'll see it's about data, not code. A game server needs data to know the allowed actions in the game, the entities in the game, the rules for interaction, the locations, etc, in order to maintain a common understanding of the world with the clients. It is this data that was copied from the WoW client and incorporated as a SQL database (into otherwise presumably bespoke server code).

You could make your own completely new game data (and somehow insert it into the Blizzard client too), but then the game wouldn't be WoW any more, just something else built on the same engine and with the same graphical assets.

That's because most Android phones do *not* do this and then succumb to the sudden death syndrome. That's what my Nexus 10 started doing after its battery went kaput. It would run for ages on standby or with the screen brightness on low and not doing much, but instantly die as soon as It tried to play back a video (but would boot right back up and the battery voltage shot up to near fully charged levels after shutdown). Internal resistance.

On the other hand, I have heard anecdotal reports from friends with some Xiaomi phones that the performance increased after a battery replacement, so I suspect those do in fact have this feature.

This isn't about making the battery last longer. It's about making the phone work at all. It has to do with battery chemistry.

Old batteries don't just "last less". They also have an increased internal series resistance. That resistance actually limits the amount of power you can pull out of it. The more current you draw, the more energy is wasted as heat, and the lower the output voltage. As internal series resistance increases, it becomes physically impossible to get more than a certain amount of power out of the battery, and this limit also decreases as the battery drains during a given discharge cycle. It's a hard physical limit. The I-V curve just never hits your power target. If you try, your voltage sags and then the phone shuts down. This is what triggers a common syndrome in old devices, where the battery meter shows 30% but then you try to open up a CPU-intensive app and the device immediately shuts down. Chances are that's not the battery meter being wrong or miscalibrated: there really was 30% charge remaining in the battery. It just wasn't capable of handling that much power draw at that charge level. There's 30% charge remaining and there's a hidden limit as to how fast you can drain it.

It's almost certain that what Apple did here was start throttling phone performance when battery voltage sags below a critical threshold, to prevent hard shutdowns. On older batteries, this would appear as a performance limit as the battery empties. But it was never about making the phone last longer. It's just a physical limitation. The alternative is your phone shuts down. That's obviously not good.

The right solution, of course, is to have a notification or something that tells users when this is happening. Something along the lines of "Your battery cannot supply enough power to keep your device working at full performance. To maintain optimum performance, a battery replacement is recommended.".

Meanwhile here I am, running Gentoo, with init scripts that have had real dependencies for over 15 years (as well as a bash-based but much nicer scaffolding to write them), with simple to use admin tools and fully based on text files, with cgroup-based process monitoring (these days), and I'm wondering why everyone else didn't get the memo and suddenly decided to switch to systemd instead and bring along all the other baggage it comes with. Debian and Ubuntu had garbage init systems, and yet it seems *nobody* ever took notice of how Gentoo has been doing things right for a decade and a half. You can also use systemd with Gentoo if you want, because user choice is a good thing.

Everyone* switched to systemd because everyone* was using something that was much, much worse. Traditional sysvinit is a joke for service startup, it can't even handle dependencies in a way that actually works reliably (sure, it works until a process fails to start or hangs, then all bets are off, and good luck keeping dependencies starting in the right order as the system changes). Upstart is a mess (with plenty of corner case bugs) and much harder to make sense of and use than systemd. I'm a much happier person writing systemd units than Upstart whatever-you-call-thems on the Ubuntu systems I have to maintain.

The problem with systemd is that although it does init systems *better* than everything else*, it's also trying to take over half a dozen more responsibilities that are none of its damn business. It's a monolithic repo, and it's trying as hard as it can to position itself as a hard dependency for every Linux system on the face of the planet. Distros needed* a new init system, and they got an attempt to take over the Linux ecosystem along with it.

* The exception is Gentoo, which for over 15 years has had an rc-script system (later rewritten as OpenRC) based on sysvinit as PID 1 but with real dependencies, easy to write initscripts, and all the features you might need in a server environment (works great for desktops too). It's the only distro that has had a truly server-worthy init system, with the right balance of features and understandability and ease of maintenance. Gentoo is the only major distro that hasn't switched to systemd, though it does offer systemd as an option for those who want it. OpenRC was proposed as a systemd alternative in the Debian talks, but Gentoo didn't advertise it, and nobody on the Debian side cared to give it a try. Interestingly Poettering seems to be *very* careful to *never, ever* mention OpenRC when he talks about how systemd is better than everything else. I wonder why. Gentoo developers have had to fork multiple things assimilated by systemd (like udev) in order to keep offering OpenRC as an option.

What matter are the circumstances behind the vote. If you boycott a perfectly legal, organized, supported referendum, then you're an idiot. But what people are "boycotting" here is a referendum that has been ruled illegal, that is being haphazardly organized, unilaterally pushed, and basically being used as a political weapon.

Actually I had a thought experiment the other day. Why not let the Catalan people decide on who gets to decide? Polls show that ~30% of the Catalan people actually do think other Spanish people should have a say in their independence. ~50% don't (the rest is no answer/invalid).

Hold a referendum that asks two questions in Catalonia: whether the rest of Spain should get a say, and whether Catalonia should be independent. Hold a referendum everywhere else that asks whether Catalonia should be independent. Scale the answers to the first question to 100% - if it's 50/30 (20% blank/invalid), that's about 62% vs 38%. Now weigh the results based on that: Catalan people's vote accounts for 62% of the outcome, while all of Spain's (this includes Catalonia as well) accounts for 38% of the outcome. So if, say, 70% of the Catalan people but 20% of all of Spain want independence, the outcome is 70% * 62% + 20% * 38% = 51%, a win for independence. If only 60% of the Catalan people voted yes, then that's an overall no.

This way, the rest of the country gets to vote too, but only as much as Catalan people think they should.

Because they're not random unweighted Internet polls, I'm referencing an official poll conducted by the very government that is pushing the referendum. An official poll that they themselves, of course, never bring up.

The difference in outcomes we're talking about here is much, much larger than the error in the US polls. This isn't a "the polls are wrong" situation. This would be as if US polls predicted a 55% win for Hillary and then Trump won 80% of the vote. That's not polling error, that's a much bigger effect, and it can be readily explained by more detailed polls that ask people both what they think and whether they'd vote at all, which show a very large bias in participation towards "yes" voters.