peheje

Something can be misleading whether or not anyone meant it to.

Because you have like every model on the planet to choose from. So if a contender drops you switch.

Also if DS is down you can choose another provider.

I have credits at DS and OR directly. But I do see the value in OR.

Vibes. But I was thoroughly disappointed by Sol 6.0 high in today's work session.

Available in play store on Android also. Cheap

one of those games where i wish i could erase my memory just to play it again, still think about it, i think it's like a year ago i played it, maybe more. idk. great game.

I think I'd just separate the two things:

``` Theme ( ) Light (•) Dark

[x] Follow system Dark — currently controlled by system ```

When "Follow system" is on, the theme choice is greyed out.

Feels simpler to me, and it scales better if themes ever become more than just light/dark.

Source

I'm using my unrooted stock s23u with damaged screen as a server but only to me thru tailscale.

Termux. Proot ubuntu. Serving OWUI and syncthing. Works fine. Had to remove pw protection so runit starts services at reboot. Therefore encrypted at rest any sensitive data

I Ssh in into it with ai harness to make changes. Made me not want to sell it after all.

Despite all the trends, I still really like HTML for structure, CSS for styling, and JavaScript for logic.

The boundaries aren’t perfectly clean, and that’s fine. But the separation gives you a useful way to think: structure this first, style it later, add behaviour where needed.

My experience with Compose—though I suspect SwiftUI people will recognise the feeling—is that I have to think about everything, everywhere, all the time.

Then we add some MVVM/UDF flavour. The "ViewModel" knows nothing about the view, despite usually serving exactly one screen. Add some "MutableStateFlow"s, combine them into "ScreenUiState", expose it as a "StateFlow", collect it with lifecycle awareness.

Beautifully decoupled. Extremely testable.

Then the organisation writes no unit tests and relies entirely on two-hour nightly screen tests.

A welcome-page refactor breaks the profile page.

“Didn’t you check the nightly build?”

No. It runs at night.

“Well, that’s your responsibility.”

But you broke it.

“Yes, but it’s your code.”

Then why did we ship it?

Fine. Schedule the postmortem with my mother.

And I’m not blaming mobile developers here. I’m frontend, backend, full-stack, I think AI engineer now. I have personally helped make simple things complicated across the entire stack.

What I like about the web is that one simple screen can be vanilla JavaScript. Another can use Vue. Another can use some specialised spreadsheet component.

People react to that with horror: what if components are duplicated, behave or look slightly different?

Fair concern. But that is real coupling with visible consequences and trade-offs. Somehow we have started treating coupling as something abstract that only exists inside code, rather than something that should produce an actual benefit when removed.

HTML. CSS. JavaScript. Or something close to it.

Maybe I’m getting old.

Shipping. Breaking stuff. Fixing it. And discovering, repeatedly, that the tool sounded much more confident than it had any right to.

Like always. This is why the average carpenter you hire in 2026 still won’t do a perfect job, despite carpentry having existed for thousands of years.

Might just resub. Will experiment with Luna next sessions. 5 h window is not working very well for me. But if I can drop down to Luna at 20-30 % left and comfortably ride out the wave then.. that might just work.