186 karma · joined February 7, 2018
Like everything else, it's tied to your Apple account. You risk losing your browser history etc. You _can_ export it if it happens, but it's easier to not have the issue in the first place.
> 2. Is there an alternative to "Find My" that I can use with AirTag?
https://github.com/seemoo-lab/openhaystack maybe? I haven't tried it.
I was able to regain access to my phone and laptop eventually, but my airpods are still "someone else's" and my air tags were permanently broken (ringing a bell whenever they are moved).
As for derisking things from Apple:
- Whenever you buy apps on App Store, ask yourself whether you'd be OK buying it again if you get locked out
- Don't use icloud for email
- Don't use icloud for permanent storage (it's OK for transfer)
- Don't use safari
- Ideally don't use "Find My" - it's what locks your device to your Apple ID
- Use an external password manager like Bitwarden
[1]: https://skogsbrus.xyz/dont-put-all-your-apples-in-one-basket...
https://skogsbrus.xyz/dont-put-all-your-apples-in-one-basket...
Well done!
Seems more reasonable to me to have a much longer deprecation notice.
As an Apple noob at the time, I assumed that if my MDM-managed device prompted me to log in with my Apple ID, that it of course would be an allowed action.
With regards to data being shared, the only thing I noticed was wifi passwords and peripherals pairing (apple keyboard).
I hope legislation will force Apple to step up and be more transparent / helpful.
https://skogsbrus.xyz/dont-put-all-your-apples-in-one-basket...
See https://skogsbrus.xyz/dont-put-all-your-apples-in-one-basket... for more info.
See my previous posts on the matter for more info.
That book should set you up with the fundamentals. Pytorch is the defacto standard right now for training; during deployment you will use whatever your deployment setup allows (e.g. embedded devices typically have their own inference frameworks).
Python is the lingua franca for anything in machine learning, but other languages are used where necessary for performance or for ecosystem benefits.
[1]: https://www.manning.com/books/deep-learning-with-python
To do that you only need to understand the fundamentals of tensors, some basic knowledge on what the big no-nos are within ML development so you can course correct your peers if they break them, and either focus on the operations side of things or deployment. In both cases, having a knack for optimizing bottlenecks will be very helpful since they will be present during both training and inference.
I recently encountered this with Apple (https://skogsbrus.xyz/dont-put-all-your-apples-in-one-basket...). After 2 months I'm still fighting them to recover some of my devices.
> If asked, enter your Apple ID.
1. syncthing uploads photos from my phone to my NAS (receive only)
2. scheduled systemd service (hourly) on my NAS reads newly received photos, renames them by date, moves it to my photos catalog
3. photoprism starts a scan of the photo library (triggered by systemd when 2. finishes)
4. weekly systemd service syncs the library to backblaze
I am so far merely an enthused observer, so I can't give any insights into the experience of delivering business software with it. Here's my observations though
- Engineers that work with this stack love it. The two most common issues I've seen are lack of static typing and difficulty in hiring
- Great for IO bound tasks due to collaborative scheduling. For CPU bound tasks performance is better offloaded to e.g Rust (see rustler)
- Exception handling is done by processes having supervisors. My mental model for this is similar to pods & deployments à la K8s, but at any abstraction level you want inside your component.
- Elixir pleases many crowds: ruby, FP, performance, resilience
- Phoenix (an elixir library) is seen as a next step from ruby on rails.
- Concurrency model is considered to be simple & powerful
The service ingests data from a timespan T spanning M minutes. Before the next timespan T+1 is ingested, the service has to process the data from timespan T in <M minutes otherwise we fall behind. What I mean with "faster than real-time" is that it has to process the data faster than it is ingested.
The main bottleneck that C-extensions solved for us then was marshaling. Instead of doing something like Numpy --> custom algorithm --> Numpy --> custom algorithm in Python, we moved it all to C. This way, we decreased the number of times we had to marshal data & we reduced the amount of data that needed to be marshaled.
IIRC we gained 10-100x improved performance in all scenarios where we used C-extensions. Before doing so we tried to use Numba, as it seemed to offer a "free lunch", but we never got it to work.
The final cherry on top that let us surpass real-time speed was replacing a graph algorithm with another that had a better time complexity for larger graphs. Before doing that switch, we'd still be faster than real-time for _most_ inputs but would lag behind severely whenever we had a dense input graph come in.