One silver lining this is finally going to push me to switch to a dedicated camera and some niche unrestricted Linux or graphene device as a phone. Goodbye iPhone. (I say this as someone with an Apple account old enough to auto “qualify”, how lucky).
LineageOS doesn't come close in terms of security, however it's an amazing project for all the hardware abandoned by the vendors -- however I wouldn't go as far as telling people they're using their phones wrong and don't actually need to use 90% of they apps they use :)
Also parent in the UK - strong disagree, it’s part of our parental responsibilities to set this up, not doing it is the same as not watching a newly walking baby on the stairs (/etc). Compromising everyone’s privacy for a subset of lazy parents is a failing of society.
Relatively few newly walking babies have peers whose parents allow them to use stairs unattended making them feel socially excluded for not also using stairs unattended.
Ignoring the existence of peer pressure and calling parents lazy is a failing of individuals.
This is not going to get rid of peer pressure. That existed long before kids had phones and it will continue to be a problem with this.
Parents should be there to teach rather than just restrict. Kids will need to learn how to recognize and deal with peer pressure at some point.
Also Apple definitely benefits from peer pressure generally. Their devices are seen as status symbols, the dreaded green bubbles, maybe more. I wouldn't expect them to do anything to actually improve things in this area.
I was using this religiously but there’s a bug currently that makes the initialization fail and/or throws an error on the phone client.
Absolutely great piece of software otherwise, free, anonymous, encrypted and so on. Really hope the team can fix this soon - I would hate to switch back to tmux tunneling.
Set it up and never managed to have it work. Only thing it did was renaming my sessions on my main cc instance. Mobile did nothing, not even an error message.
All of these agent wrappers/claws/whatever seem to encourage wildly irresponsible usage of AI. Sure it can get stuff done in what is effectively a simple loop but without review we’re just playing with fire.
I was experimenting with Claude code doing similar (don’t need wrappers really) and the result was a huge amount of mediocre code and my weekly limit burnt. The code “works” but oh my the duplication and potential bug surface is off the chart.
Stopped my experiment and back to human in the loop plan->execute cycle which is way more effective.
Thankfully I don’t think we’re at jarvis levels yet.
The whole point of Mato is to make human-in-the-loop supervision easier, not to encourage autonomous loops.
In my daily workflow I constantly run multiple coding agents at the same time. The annoying part isn’t the AI itself — it’s switching between tabs, terminals, and different tools just to check what each agent is doing.
I built Mato mainly because I wanted a faster way to jump between agents, review their outputs, and approve or intervene when needed. Think of it more like tmux for AI workers, where a human manager can oversee multiple agents at once.
Personally I’m also skeptical of fully self-driving loops. In practice the plan → execute → review cycle with a human in the loop is still the most reliable way to work with AI today.
As a primarily Go dev - 100% agree. The endless check and wrap error results in long chains of messages you have to grep for to understand the call stack. For what benefit? Might as well just panic and recover/log the stack in many cases.
The error handling is by far my least favorite aspect of Go. It's tedious and dangerous. It should either be like Rust or like JS, there isn't a good third option.
Isn't JS the same? But seems like people tend to make a lot of exception types in Java with inheritance, which I think is overkill.
Typically I'll only have a couple of exception types that my own code throws, like user error vs system error. If I want more detail than that, it goes into the exception payload rather than defining many different types of exceptions.
The key here is a singleton sequencer component that stamps the new versions. There was a great article shared here on similar techniques used in trading order books (https://news.ycombinator.com/item?id=46192181).
Agree this is the best solution, I’d rather have a tiny failover period than risk serialization issues. Working with FDB has been such a joy because it’s serializable it takes away an entire class of error to consider, leading to simpler implementation.
reply