Francesco Cesarini (Hacker News):
It is with great sadness that I share news of Joe Armstrong’s passing away earlier today. Whilst he may no longer be with us, his work has laid the foundation which will be used by generations to come. RIP @joeerl, thank you for inspiring us all.
Sugandha Lahoti:
Dr. Armstrong was best known for helping lay foundations in the ’70s and ’80s to the most widely spread concurrency models as we know them today. In concurrent programming, multiple events, code snippets or programs are perceived to be executing at the same time. Unlike imperative languages, which uses routines or object-oriented languages, which use objects. Concurrency oriented languages use processes, actors, and agents as the main building blocks. Dr. Armstrong helped propel concurrency programming at a time when there was no IoT, web, massive multi-user online games, video streaming, and automated trading or online transactions.
[…]
Erlang was originally built for use only at Ericsson, as a proprietary language, to improve telephony applications. It was designed to be a fault-tolerant, distributed, real-time system that offered pattern matching and functional programming in one handy package. It was then open-sourced to the public in 1998. Since then, it has been responsible for business, big and small, to create reliable systems.
Greg Hurrell:
His last tweet:
Joe Armstrong:
Once upon a time my boss asked me to study if we should use C++ or Erlang for a specialist XML parser to be used in a product (for reasons of speed not energy).
My recommendations was an FPGA
We built an FPGA.
Relative speed of C++/Erlang was irrelevant compared to FPGA.
Michael Gasch:
Apparently, the creators of the language found a way to trick the mighty failure gods. What have they done differently? Well, amongst many carefully evaluated design decisions that went into the language, they came up with the philosophy of “Let it crash”. I.e., instead of writing a lot of defensive code to handle every possible corner case, you accept that there will be failures, where you separate the concerns and take corrective actions.
The separation of concerns in this case is based on the concept of a supervisor and supervision trees, where the supervisor deals with failure (crash) handling when faults in the business logic (worker processes in the tree) occur. Another advantage is that these processes don’t have to run on the same machine to benefit from the supervision concept. Furthermore, in Erlang, processes are isolated from each other and don’t share state. So you can further reduce the blast radius of failures on a process-level.
See also: Wikipedia, Let’s Talk Concurrency (via Hacker News), Why OO Sucks (via Hacker News, note).
Previously: A Taste of Erlang.
Update (2019-05-10): See also: uses this (Hacker News) and The Guardian (Hacker News).
Concurrency Erlang Programming Language Language Design Programming Rest in Peace
Thomas Tempelmann:
Unfortunately, with Apple’s new file system APFS, and the fact that any macOS running High Sierra or Mojave got their startup volume converted from HFS+ to APFS, search performance has decreased by factor 5 to 6!
[…]
I’ve tried to find out which of the various methods of reading directories, looking only for file names, is the fastest: I had to scan the same directory tree with every method separately.
[…]
contentsOfDirectoryAtURL and getattrlistbulk perform equally indeed, just as predicted, with the latter usually being a bit faster once the data comes from the cache.
On APFS, NTFS and SMB, opendir() is significantly faster than the other methods, which is quite surprising to me.
[…]
When accessing a Mac via SMB, contentsOfDirectoryAtURL is faster than the other methods, but only on the first run (see red field). Once the caches have been filled, it’s slower. I can’t make sense of it, but it’s a very consistent effect in my tests.
Previously: APFS and Fast Catalog Search.
Update (2019-04-23): Thomas Tempelmann:
fts_open() / fts_read() are, in most cases, faster than readdir(), contentsOfDirectoryAtURL and getattrlistbulk. Exceptions are network protocols, where especially the retrieval of additional attributes makes it slower than the other
Apple File System (APFS) File System Mac macOS 10.14 Mojave Optimization Server Message Block (SMB)
Jeff Johnson (tweet):
Notarization is a kind of two-factor authentication. In order to notarize an app, you first need to sign it with your Developer ID cert, but then you have to submit it to Apple using the Apple ID and password of your developer account. If your signing cert is compromised, that by itself would no longer be sufficient to distribute the app.
[…]
A myth has been spread that Developer ID certs can only be revoked in entirety, meaning that all versions of all apps signed with a Developer ID cert would be invalidated when the cert is revoked. Apple has contributed a bit to this myth[…]
[…]
The ability of Mac apps to update themselves shows that the notarization malware scan is security theater. Apple’s notarization service scans for malware, but malware authors don’t need to submit malware to Apple! They can submit a perfectly innocent app for notarization, get the app notarized, and then flip a switch on their own server to download a malware software update when the victim opens the “innocent” notarized app. The downloaded malware update doesn’t need to be notarized, because the software updater will delete the quarantine attribute, thus bypassing Gatekeeper.
I guess the questions are:
- Is having to integrate something like Sparkle enough of a hurdle to deter malware authors?
- Can notarized malware convince users to update the app and download the actual malware?
I suspect that the answers are “no” and “yes.” Apple presumably believes otherwise. (They are surely aware of this loophole, and I don’t see why they would bother developing notarization if they didn’t believe in it.)
The malware scan is unlikely to catch serious malware authors, but it does punish legitimate developers, because they have to submit their apps and then sit and wait for Apple’s response, which Apple claims should take less than an hour (already too long), but in practice has taken much longer in some instances, according to developers I’ve heard from. Just yesterday, Apple’s Developer System Status showed 2 outages of 90 minutes each with the Developer ID Notary Service. The whole point of distributing software outside the Mac App Store is to avoid problems like these, submitting to Apple for approval and waiting for their response, but now Apple is imposing those very same problems on software outside the App Store. If notarization is to be required at all, I think it should skip the security theater of malware checks and simply notarize the app on submission, a process that would be almost instantaneous.
I’m not sure that the malware scan is the reason that notarization can sometimes take a long time, because I’ve had the same problem with “Processing for App Store” when submitting via App Store Connect.
Besides the notary service being down, mandatory notarization is risky for developers because code signing requirements can (and have) changed without warning and the malware scan might falsely block a legitimate app as malware. I’m not sure what you’re supposed to do in that case, but it would likely take a while. Developers know that when the App Store scanner falsely flags their app for violating a rule, contacting Apple through official channels rarely leads to a resolution. Instead, they have to act like an actual malware author and try to obfuscate their code to fool Apple’s tools.
Previously:
Update (2019-04-23): Jeff Johnson:
“signing applications with your Developer ID certificate provides users with the confidence that your application is not known malware”
Isn’t that the exact same story we’re being told again with notarization? Fool me once, shame on you, fool me twice…
Update (2019-04-28): Todd Ditchendorf:
I fully appreciate the criticisms on this, but I can think of one good reason why Notarizing is not just Security Theater: It gives the responsible developer some “confirmation” that his app does not unintentionally contain malware. Like a mandatory virustotal dot com check.
Update (2019-04-29): Stephane:
Strangely, I tend to remember that Apple was not able to detect XCodeGhost by itself and prevent infected iOS apps from entering the App Store. So why should we believe they would be more effective with the notarization process?
Update (2019-05-09): Kyle Howells:
App notarisation I think is the biggest threat to the Mac remaining the open app platform we know today.
It can act as a Mac AppStore style, sandboxing and private API gate at the flick of a switch.
And we all just have to hope Apple will never flick that switch.
Update (2019-05-10): Jason Snell:
Yes, it’s possible that Apple could use this approach to ban most third-party apps outside of the App Store, but I don’t think that’s the intent. Instead, I think this is yet another example of how Apple wants to gain some of the benefits of App Store-style security without forcing every piece of Mac software through the Mac App Store.
Update (2019-09-09): Thomas Clement:
Funny thing, someone notarized the latest version of my app and that’s not me. Is it some random developer? Is Apple notarizing apps out there to avoid too much breakage?
Jeff Johnson:
My old blog post “The true and false security benefits of Mac app notarization” said that notarization is a kind of 2FA, but now we see that’s false.
Any developer can notarize signed software, not just the owner of the Developer ID signing certificate.
This means that if someone has unauthorized access to your DevID cert (not the situation for Thomas, but other devs have had certs stolen), the unauthorized person can still notarize and distribute software using your cert without your knowledge or access to your AppleID.
Update (2019-12-23): Jeff Johnson (tweet):
In my previous article I claimed that notarization protects your Developer ID certificate from unauthorized use, because once your app is signed with the certificate, it also has to be uploaded to Apple’s notary service using your Apple developer account, which itself requires 2FA. Consequently, unauthorized distribution would require compromise of both your Developer ID certificate and your developer account, and you would still receive email notification of any notarization performed with your account, or indeed any changes whatsoever to your account, including change of the email address associated with the account. Nobody can notarize an app using your account without your knowledge.
My mistake was assuming that a Mac app signed with your Developer ID certificate would have to be notarized with your Apple developer account. […] It seems that anyone with an Apple developer account can notarize any signed Mac app, even if the signer and the notarizer have no knowledge of each other.
Previously:
Code Signing Gatekeeper iTunes Connect Mac Mac App Store macOS 10.14 Mojave Malware Notarization Programming Security Xcode
Dieter Bohn (tweet):
I have never used a device with this many problems that I have liked this much.
[…]
The Galaxy Fold is also beset with issues that stack up into a pile that you can’t excuse away by saying this is just a first-generation product. There are basic user experience issues that are unacceptable on any smartphone, much less one that costs two grand.
What you should do is head to a store and play around with it because it is legitimately a marvelous thing to play with. Beyond that, it’s a status symbol, a curiosity, and a little tease at a possible future.
[…]
I found myself using it in meetings, and nobody batted an eye. I was reviewing docs for the meeting, but I could have just as easily been messing around on social media. But think about the social rules of a work meeting: somebody messing around on their phone is a jerk, but somebody using a tablet is more likely to be doing something relevant. The Fold feels like a different device with different social rules, and that’s fascinating.
Joe Rossignol:
Samsung has confirmed the delay in a statement provided to CNBC, noting that it will announce a new release date “in the coming weeks” and “will take measures to strengthen the display protection.”
Previously: Galaxy Unpacked 2019.
Android Samsung Samsung Galaxy Fold
Rene Ritchie:
But it sounds like the half a decade plus of trolling is, at last, behind us, and performance improvements done, the design evolution is continuing, and this year we’ll actually be getting dark mode for iPhone and iPad.
[…]
[Font] Management is going to be implemented in a Settings panel. There’ll be a new Font Picker controller so you can get your styles on inside text fields, and an alert if you download a document but don’t have the fonts installed to go with it.
[…]
Gui does add that something like PanelKit will also be in the offering. Windows will be able to contain sheets and those sheets will be able to be dragged free, into cards, and those cards will be able to be stacked.
[…]
Three finger tap and swipe left to undo. Three finger tap and swipe right to redo. It’s not quite the Procreate double finger tap, but it’s close and direction adding dimension sounds smart.
It also sounds like we’ll be getting multi-select support not just for icons and draggable items, the kind that currently exists in iOS, but for items in list and collection views as well.
[…]
According to Gui, in a separate article on 9to5Mac, Find my iPhone and Find my Friends are merging and, what’s more, adding the option to find other things connected to small, Tile-like beacons from Apple.
Previously: Proof That iOS Still Hasn’t Gotten Undo Right.
Update (2019-04-29): See also: macOS 10.15: Features, release date, and analysis.
Update (2019-05-13): Mark Gurman (MacRumors):
Apple is also planning bring over a couple of its own iPad apps to the Mac this year: a Podcasts app and the new merged Find My iPhone and Find My Friends app from iOS 13.
There will also be a new Apple Music app, which is being developed as a standard Mac program.
Other in-house software coming to the Mac includes: Screen Time; effects and stickers for the Messages app; integration with the Siri Shortcuts app (the company’s new service for writing your own Siri commands); the new Reminders app; and upgrades to Apple Books.
Dark Mode Find My iPhone Font iOS iOS 13 Mac macOS 10.15 Catalina Undo
