>instead require the user to manually go into settings to turn them on, but if they do then it's still possible
They clearly addressed this option in the post, under sufficient social engineering pressure these settings will easily be circumvented. You'd need at least a 24h timeout or similar to mitigate the social pressure.
>I'm not really sure what to do. Maybe this MacBook Pro was just a one-off, and I have to go back to buying Windows laptops and putting Linux on them. But they just aren't as nice.
Why would you think that? They're working hard on upstreaming all patches ATM, adding new hardware support will be much easier afterwards.
First: It's great to have some serious competition in the durable execution market! You build some impressive tech already! It took me a decent time to investigate before pulling the trigger on temporal at my current PSP fintech as you'll end up with a pretty hard vendor lock-in which has to be worth it.
I have to say the architecture blog post is very leightweight on details, which makes it hard to judge so you have to dive into the docs for the spicy details and I see abig showstoppers for our usecase:
1. Workflow versioning: It seems currently impossible to properly upgrade inflight workflow without manually forking the workflow
Also the marketing material and docs aretoo handwavy on the idempotency and determinism constraints, which makes them dbos seem to good to be true.
I'd also love to see higher level abstractions around message sending. Temporal's signal, query and update are essential building blocks for our use cases and allow some quite interesting use cases as you can really view workflows as actors.
I hope you can keep innovating as temporal really is too heavy for a lot of use-cases.