Juli Clover (docket PDF, Hacker News):
Apple last year sued Corellium for copyright infringement because the Corellium software is designed to replicate iOS to allow security researchers to locate bugs and security flaws.
According to The Washington Post, a Florida judge threw out Apple’s claims that Corellium had violated copyright law with its software. The judge said that Corellium successfully demonstrated that it operates under fair use terms.
[…]
Apple has also said that Corellium circumvented Apple’s security measures to create its software and violated the Digital Millennium Copyright Act, and that claim has not been tossed out.
Miguel de Icaza:
The natural next step: Amazon offer iOS on the cloud, and you can remote login to your secured iOS devices on your cloud. I am surprised by the ruling, but it opens a whole new world of businesses out there (both monetizing iOS and monetizing all sorts of other software)
Previously:
Update (2021-01-01): John Gruber:
I can see why Apple fought this, but it also seems right that they lost.
Apple Copyright Corellium Digital Millennium Copyright Act (DMCA) iOS Lawsuit Legal
Jeff Johnson:
Many macOS Mojave users, including myself, have experienced frequent failures of App Store to update their installed apps. Whenever this occurs, App Store shows the completely unhelpful error message “cancelled”.
[…]
One of the most frustrating aspects of being an App Store developer is that whenever users experience a problem with App Store installs and updates, they contact us instead of Apple, even though developers have no control whatsoever over the App Store app. All we developers can do is press the “Release” button in App Store Connect, and then Apple has total control afterward. Even if you’re not running Mojave, I hope you come away from this blog post with the realization that developers are as much at the “mercy” of Apple as users are when it comes to the App Store app, and the only thing we can do to fix these problems is to complain to Apple and hope the company takes mercy on us.
Previously:
Update (2021-01-01): Greg Hurrell:
Seen this many times since (begrudgingly) updating to Mojave.
Update (2021-02-19): Jeff Johnson:
Wow, I found a solution to App Store apps not installing on Mojave:
When the spinner gets stuck, force quit appstoreagent
Update (2021-03-14): Jeff Johnson (tweet):
It appears that Apple has fixed this problem sometime within the past 24 hours. There was no Mojave software update, so it must have been a server-side change.
See also: Howard Oakley.
Bug Mac Mac App Store macOS 10.14 Mojave
Dan Luu (tweet, Hacker News):
In the classic 1986 essay, No Silver Bullet, Fred Brooks argued that there is, in some sense, not that much that can be done to improve programmer productivity. His line of reasoning is that programming tasks contain a core of essential/conceptual complexity that’s fundamentally not amenable to attack by any potential advances in technology (such as languages or tooling). He then uses an Ahmdahl’s law argument, saying that because 1/X of complexity is essential, it’s impossible to ever get more than a factor of X improvement via technological improvements.
[…]
In 1986, there would have been no comparable language, but more importantly, I wouldn’t have been able to trivially find, download, and compile the appropriate libraries and would’ve had to write all of the parsing code by hand, turning a task that took a few minutes into a task that I’d be lucky to get done in an hour. Also, if I didn’t know how to use the library or that I could use a library, I could easily find out how I should solve the problem on StackOverflow, which would massively reduce accidental complexity. Needless to say, there was no real equivalent to Googling for StackOverflow solutions in 1986.
Moreover, even today, this task, a pretty standard programmer devops/SRE task, after at least an order of magnitude speedup over the analogous task in 1986, is still nearly entirely accidental complexity.
[…]
Brooks explicitly dismisses increased computational power as something that will not improve productivity (“Well, how many MIPS can one use fruitfully?”, more on this later), but both storage and CPU power (not to mention network speed and RAM) were sources of accidental complexity so large that they bounded the space of problems Brooks was able to conceive of.
pron:
Our current state is a big disappointment compared to where most programmers in the 80s believed we would be by now, and very much in line with Brooks’s pouring of cold water (perhaps with the single exception of the internet).
My perception is that the total productivity boost over the past three decades is less than one order-of-magnitude (Brooks was overly careful to predict no 10x boost due to one improvement in language design or programming methodology within one decade), and almost all of it comes from improvements in hardware and the online availability of free libraries (Brooks’s “Buy vs Build”, which he considered promising) and information -- not from changes in programming methodology or language design (although garbage collection and automated unit-tests have certainly helped, too). The article also mixes hardware improvements and their relationship to languages, but we knew that was going to happen back then, and I think it’s been factored well into Brooks’s prediction. Moreover, my perception is that we’re in a period of diminishing returns from languages, and that improvements to productivity Fortran and C had over Assembly are significantly greater than the gains since.
[…]
I would also add that if you want to compare the ratio of essential and accidental complexity in line with Brooks’s prescient analysis, you should compare the difficulty of designing a system in an accidental-complexity-free specification language like TLA+ to the difficulty of implementing it in a programming language from scratch. I find the claim that this ratio has improved by even one order of magnitude, let alone several, to be dubious.
Programming Stack Overflow
Bert Hubert (tweet, via Max Seelemann):
The BNT162b2 mRNA vaccine has this digital code at its heart. It is 4284 characters long, so it would fit in a bunch of tweets. At the very beginning of the vaccine production process, someone uploaded this code to a DNA printer (yes), which then converted the bytes on disk to actual DNA molecules.
[…]
Our body runs a powerful antivirus system (“the original one”). For this reason, cells are extremely unenthusiastic about foreign RNA and try very hard to destroy it before it does anything.
This is somewhat of a problem for our vaccine - it needs to sneak past our immune system. Over many years of experimentation, it was found that if the U in RNA is replaced by a slightly modified molecule, our immune system loses interest. For real.
So in the BioNTech/Pfizer vaccine, every U has been replaced by 1-methyl-3’-pseudouridylyl, denoted by Ψ. The really clever bit is that although this replacement Ψ placates (calms) our immune system, it is accepted as a normal U by relevant parts of the cell.
COVID-19 Malware Science
