mjg59

17-bit distributed a lot of redistributable stuff - in this case it's listed as disk 1423 in their collection

Nor was it in the final versions of Maemo, if you want to be pedantic.

"The way Apple destroyed the competition was by creating so much hype around their product that they could demand concessions from carriers" is very easy to read as people buying iPhones because of hype and not because they were meaningfully better than the competition in ways that many people valued. Is that not what you meant?

The Maps experience on the iPhone was sufficiently better than on any other platform that it was justification in itself for many people to buy one. But you're also massively underselling the media aspect - iTunes integration was compelling enough that Palm implemented iPod imitation in the Pre so it would work with iTunes. Was the iPhone compelling to the niche enthusiast market that was on Symbian or Blackberry? Probably not, but that market was small and already saturated and the idea that the iPhone was unappealing in the market it was actually selling into is ridiculous.

Oh, come on. Yes, compared to any modern device the iPhone was a piece of shit (no cut and paste when shipped? No 3G?), but as someone who owned a high end S60 device at the time, the iPhone was a breath of fresh air - the Maps experience on its own was enough of an improvement to justify it. The problem Nokia and others had is that they were judging potential iPhone buyers against the people buying their smartphones, not against the market waiting for a smartphone that wasn't an absolute piece of shit from a UX perspective.

The N900 was never really intended to be a mass market device, more something to attract enthusiast excitement and serve as a reasonable developer platform - so in that respect it being kind of half assed isn't too much of a surprise. The problem was it taking another two years until the (in theory) mass-market hardware was ready and also there having been another basically pointless upheaval in dev experience (the shift from Maemo to Meego, which included changing packaging formats), and in that respect the experience was incredibly half assed.

And no multitouch.

GTK wasn't a first class citizen in Meego.

The N9 shipped when it did because the teams working on the successor project had been pulled back to support the N9, and Elop arrived to find a company betting its future on a new platform that had almost no existing third party support and which wouldn't have any follow-up hardware for another 2 years. Google has no incentive to work with Nokia rather than the existing vendors who'd staked themselves to Android, the other competing platforms at the time were basically all tied to a single vendor, but Microsoft wanted a recognisable brand name and would throw engineering resources at supporting them. With hindsight it obviously didn't work, but Meego as a competitive platform was already dead even without heading in the Microsoft direction.

It's funny that these conversations always focus on Elop and not all the decisions already made by the time he showed up. Maemo bring rebased on Qt at the insistence of the Series 60 team so there could be a transition story from S60 to Linux delayed software development significantly, and the merge with Moblin was ultimately entirely unnecessary churn.

It's a convenient story to blame Nokia's failure on Elop and Microsoft, but in the timeline where that transition didn't happen we'd still look back at the N9 as the last gasp of a giant that failed to adapt to the changing market fast enough. The N9 came out almost 4 years after the iPhone - the Pre had landed two years earlier and even so had failed to gain sufficient market support to survive, and HP killed WebOS a few months after the N9 shipped. In 2011 momentum was entirely with iOS and Android. If the N9 had shipped in 2009 they might have had a chance. Instead, the N900 was shipped in limited company quantities with woefully uncompetitive hardware.

It's 2011. Faced with an ecosystem that has changed massively in the past 4 years that's destroyed your high end market and is threatening your medium and low end market, and given the choice between an (absolutely beautiful!) in-house platform with no killer apps and two years before you can ship a successor, and the opportunity to tie up with a dominant OS vendor who'll prioritise your brand and provide engineering support and make it possible to churn out several new high end devices in that two year timeframe, which seems like the better choice?

The N900 shipped two years after the iPhone while still having a resistive touchscreen. In the story of Nokia resisting Apple and Android it's basically irrelevant - it's part of the history that led to the N9, but it's not until we get to the N9 that there's a meaningful response to the market shift they represented.

This gets you code execution in the kernel, at which point sandboxing is irrelevant.

My understanding is that it's not so much that the novelisation is of the director's cut, but that the people writing them are typically working from (at best) the shooting script (and at worst, an earlier version of the script). The book needs to come out at around the same time as the movie, and there simply isn't enough time to re-edit it and print it after the final editing decisions are made. You'll frequently find sections in the book version that only end up on-screen as a director's cut or in deleted scenes, and sometimes just never at all.

You say that, and also remote attestation is how Signal knows it's talking to a legitimate SGX enclave running the expected payload

Isn't that lower than a purely resistive heater?

As someone with experience (albeit almost 20 years out of date) experience of wet lab DNA collection and sequencing - this stuff is hard, you will fail a lot, and you will fail a lot more if you don't have an extremely clean environment to do this in. And once you have data, you should be asking yourself how accurate it is given the environment you collected it in, you should be looking at correlated sequence errors that are not taken into account[1].

But also: genetic counselling is a real thing that real people study. Please don't ask an LLM questions about what your genes are going to do to you without having access to someone who has the ability to contexualise the data and put you in touch with relevant experts. I have a PhD in this and I would not trust myself to be able to interpret data about myself in a detached and rational way.

(And: why is the link to Molecular Biology of the Cell to the 6th edition, when the 7th came out 4 years ago? Random fact: the first three editions were co-authored by my supervisor during my first PhD attempt, who went on to demonstrate that Roger Penrose's ideas about the importance of microtubules in chemotaxis in E. coli were absolute bullshit. Great guy)

[1] I spent a while analysing very early (by commercial standards) Illumina data in 2007, and being able to align stuff to reference genomes made it possible to identify certain biases. Nanopore technology is likely to have more of those, and if you don't have the ability to take those into account you may have a very bad time

We're talking about the equivalent of booting with init=/bin/sh, I don't remember kernel init on x86 ever being that slow

ARM isn't consistent in the way that the x86 platform is. Each vendor's SoC usually requires specific support.

"Quality" is maybe overloaded. Upstream requires the code to meet their sense of taste, and some of that is about quality, and some of that is about undocumented design concepts. It's not hard to meet the quality bar. Meeting the design requirements is extremely hard.

Linux tries to avoid special cases. That means that when someone shows up with a new driver that's either not something that fits into an existing category, or which sort of (but doesn't entirely) overlap with an existing driver, there's an extended set of design discussions about how to make this new driver fit into existing infrastructure in a way that's consistent with what's there and which also allows new things to exist.

That sounds great from a design perspective, but it can also lead to cases where people are attempting to design for utter unknowns - potential futures that may or may not exist, theoretical understandings of how hardware works, that kind of thing. It frequently prevents new drivers being merged without significant modification, and sometimes it results in a need to entirely rearchitect the relevant part of the kernel before the driver can even be considered (and also now you need to split that driver into three parts). Upstreaming is hard.

If you've ever been developing software for a Mac for any length of time and searched for a weird error, there's an extremely high probability you've ended up on a post written by Quinn that gives you a pointer to how to fix it.

My coworkers like to complain that searching for anything they're working on leads them to either old blog posts written by me, or (if they're currently working on MacOS issues) posts by Quinn. It's funny because it's entirely my experience as well. Apple's attitude towards secrecy means that a huge amount of knowledge is simply never shared, and we're left with Quinn as an incredibly rare portal of knowledge between the inside of Apple and the rest of the world. Quinn, you've apparently seen some shit. Thank you for sharing it with us. I've worked with at least three teams who could never have deployed what we did without you.

There's US1549 and FR4102 - are there any others? But yes, the assumption about failures being independent is obviously violated by large flocks of birds, although this has also resulted in the loss of 4-engined aircraft.

or indeed any I/O ports.

PCI has the concept of I/O ports even if the CPU doesn't. The details differ depending on whether it's PCI or PCIe, but the net effect is that whatever's responsible for putting the access on the bus exposes an MMIO window that corresponds to the the port addresses available, and generates port I/O cycles in response to accesses to that window.

All else being equal, potentially - although as I mentioned there have been cases where one engine falling off a 4 engine aircraft hit another in the process. But ETOPS certification is based on it being demonstrated that engines are sufficiently reliable that the probability of an independent failure is incredibly unlikely, and also requires that operators have a stricter maintenance process. The only dual engine failures on modern two-engine aircraft I can think of off-hand have been fuel exhaustion (either actually being out of fuel, or ice blocking fuel filters in the case of BA38), and would have affected 4-engine aircraft just as badly.

More people have died due to one engine falling off a 747 and knocking off the other engine on the same wing than have died due to dual engine failure on an ETOPS certified aircraft

Shim, the first stage bootloader on Linux, is designed to be updated infrequently. Distributions embed their own signing certificate in it and have that binary signed by Microsoft. The actual bootloader (typically either grub or systemd-boot) is then signed with the distribution certificate, as is the kernel. Distributions get to set their own policy around how long that certificate lasts for, it's entirely unrelated to the Microsoft certificate expiry.

It's actually largely because I demanded it, our customers weren't paying attention at all - Fedora was going to be hit much worse than RHEL

Nothing stops vendors from shipping additional keys, and several do - I've seen multiple laptops that included an Ubuntu signing cert (contrary to Canonical's recommendation)

The short answer is simply that nobody credible has offered to run such a service. The Linux Foundation investigated it and concluded that it was impractical to do so. Since secure boot rolled out we've seen a couple of pieces of malware that have explicitly attempted to bypass it (largely through vulnerabilities in Microsoft's bootloaders, ironically) which strongly implies that it's an obstacle to their goals rather than mere security theater.

The majority of code in ffmpeg today isn't written by Fabrice, but also there's multiple axes that people view programming ability on. Some people can write software that will do things you couldn't imagine given the constraints. Some people can write software that is resilient against all malformed input. Sometimes these people are the same people, but frequently they're not.