Gus Mueller:
Retrobatch is a node based (not the JS language) batch image processor. A bit like Quartz Composer, and a bit like Audio Hijack. But for images. Lots and lots of images (or maybe a few or even one).
[…]
But why node based? Every batch image processor I’ve come across was linear. You put images in one end, and out they came the other side. But that’s so limiting! What if it was possible to take a folder of images and then operate on them twice with the same workflow? What if you could create branches where one would resize images to 50%, and another write out PNG files with the @2x suffix added to the file name? What if you had a workflow that referenced multiple folders which combined into a single output?
And all the possibilities! What if you could read an image from the clipboard, apply a filter to it, and write it to a folder and to the clipboard? What if you had a way to separate out PNG images of a certain size from a folder and only do an operation to those? What if you could script the application in response to new images being added to a shared folder? What about if it could capture all the open windows of your favorite application as images, then apply a filter to those, and then write out a layered PSD of those windows? What if you wanted to apply a machine learning model against your images, to figure out which contains pictures of hotdogs in them, and then perform some action based on that?
This is a really cool idea for an app, and I like the way he’s designed the interface. The beta seems to be pretty mature already.
FAQ:
The App Store requires apps be sandboxed, which would considerably limit Retrobatch’s functionality.
Update (2018-06-02): Gus Mueller:
Which is all to say Retrobatch 1.0 was released yesterday!
[…]
For instance, the initial work to bring Metal to Acorn 6.1 was originally done in Retrobatch. Since I had no legacy code to worry about with Retrobatch 1.0, I started with Metal from the beginning. And with that experience I was able to figure out how I could move code around and refactor Acorn in an intelligent way to bring Metal rendering there.
AppleScript Graphics Mac Mac App Mac App Store macOS 10.13 High Sierra Retrobatch Sandboxing
Ryan Jones:
Wasn’t the W1 in AirPods supposed to, and did initially ship with, automatic pairing switching between Mac and iOS?
Ryan Jones:
Consensus is saying W1 AirPods shipped with
1) shared pairing between iCloud devices
2) auto switching between iOS devices
No documented auto switching Mac to iOS.
Consensus was wrong. Auto switching is not between iOS devices, it’s between Watch and iPhone. That’s it.
For the record, the AirPods intro video deviously leads you to thinking they switch, without saying it.
ADITYA Patel:
Agree. Whatever it shipped with, right now Mac vs iOS switching doesn’t work automatically.
Ryan Jones:
Bingo. W1...meh for Bluetooth pairing. Actually, worse since they can only pair to 1 device at a time.
Also, press did get a version that auto switched between Mac and iOS...for a few weeks. It never shipped.
I continue to like my AirPods, but it is disappointing that the switching is more limited than we initially thought it would be.
Previously: Tooth Fairy.
Update (2018-05-04): See also: Dan Masters and Evgeny Cherpak.
Tom Hagopian:
Well they just remember which device used them last, right? What’s really annoying to me is 1) using them with iPad; 2) leaving the iPad at home and just bringing my Watch+iPhone; 3) AirPods don’t auto-connect to the “only device” present. (Quotes bc Watch+iPhone auto-switch.)
AirPods Apple Watch Bluetooth iOS Mac ToothFairy
Twitter (Hacker News, MacRumors):
Due to a bug, passwords were written to an internal log before completing the hashing process. We found this error ourselves, removed the passwords, and are implementing plans to prevent this bug from happening again.
Nick Heer:
The euphemistic and misleading headline upsets me. What’s even more worrying is Agrawal’s reaction in a tweet[…]
CTO Parag Agrawal:
We are sharing this information to help people make an informed decision about their account security. We didn’t have to, but believe it’s the right thing to do.
Roustem Karimov:
This is weird, @Twitter. Shouldn’t you be hashing the passwords on the client side, BEFORE sending them to the server?
Mark Hughes:
So first, and most importantly, never reuse passwords, no matter how trivial. Eventually any company will screw up or be hacked, and your password exposed, and then someone can try it on every other site.
Rick Fillion:
It took us a while to find what we needed for this layer. (Apparently the marketing department of augmented password-authenticated key agreement protocols is underfunded.) But we eventually found SRP, which ticked all our boxes. SRP is a handshake protocol that makes multiple requests and responses between the client and the server. Now, that may not sound very interesting – and I’m not one to show excitement easily – but SRP is a hell of a layer. With SRP we can:
- authenticate without ever sending a password over the network.
- […]
Previously: High Sierra Stored APFS Volume Passwords in Log Files.
Bug Passwords Security Twitter Web
