devttyeu

1. Even rotated you have padding 2. Those videos are compressed really heavily, on the larger screen the quality is unbearable

Too busy in life to give up the small conveniences of Apple ecosystem, also the glossy foldable screens had really cheap feeling to me, the screen on Duo feels relatively premium.

I have a Duo:

* TouchID (as implemented on Duo specifically) sucks, really hope next gen has FaceID

* Screen ratios make reels-like addictive content less appealing which is great for me

* Inner screen is a game changer for using Agents on the go, absurdly better than a normal phone

I’m keeping mine, the big screen on the go is a completely different level of productivity.

Have you used the one on Duo? It’s in a weird position, essentially always gets in the way on what you’re doing.

Just feels like a compromise on least bad form factor that apple engineers said was feasible placed at the least bad spot that apple UX designers could come up with.

But that least-bad is still just not great, not “apple great”

@dang if the speculations circulating around are anything to go by this is apocalyptic and deserves to be amplified such that the right people see this before it’s too late.

CERT-EU even suggests isolating any systems that may be exposed and can’t be patched quickly.

Speculation is that the affected subsystem runs before any application code and affects all default installs.

Yeah, speed is the one, I believe the default TypeSafe API quota is 1.5-2k queries per second (batched in bigger requests).

On the readme I'm so sorry to tell you that, but it's 100% written by Opus 5.5 with zero "pretty please don't write slop" prompting, it's just how slop is going to look like from now on. I've been writing code for 15 years or sth like that and the code is also what I'd call pretty reasonable..

It is /possible/ to use an LLM.

But with Jev you're just paying for input (prefill) which is really fast, and in case of Jev specifically costs 50% of Deepseek V4.1 Flash (which has famously really cheap input token pricing).

I put 250MB / 1M lines of logs through Grev and it cost ~$10USD, DSv4.1 would be at least 10x that and much, much, much slower. With Jev/Grev that 1M requests took 10 mins

Edit: completely misread your question - yeah you could finetune specialized models to do that, probably based on some decent pretrained llm base, that is true for roughly any Jev-shaped problem. Do you want to bother doing that, also having to deal with having to host a zoo of specialized models?

Thought it would be funny to build, but those have actually helped me with log-combing already

What else does Oracle have? Mostly just a bunch of IP that a sufficiently strong AI will be able to recreate for a fraction of each customers bill. Oracle is very aware.

Where is the value coming from when all knowledge work (and later manual work) is 10-100-10000x cheaper done by AIs? You probably don’t want to build models, too easy to move to another provider when one is better, open models eat your lunch etc. But there are still means of production to be owned but it’s just GPUs

Yeah I’m still iterating on the pitch and target audience, thanks for flagging.

It’s not a general coding tool, shortest description would be “personal/company data/process management layer” or “everything a company may want an on-prem datacenter and admin (dev)team for, accelerated by AI”.

Came from finding bug shortcomings in OpenClaw/Hermes where it’s not really close to having everything needed to organise and deal with big data in a safe or efficient way.

Basically the bottleneck is building a massive amount of software around agents which won’t happen in an all-in-one harness, this attacks that problem

I run a company currently serving ~1.7B requests per day (~20k/s) to ipfs gateways, so presumably still some. Very likely a big chunk of that is bots scraping stuff.