owaislone

This project has been so impressive and exciting. I hope power management is a serious concern once they nail all the reverse engineering and functionality. Battery life would be a huge differentiator for the day to day macbook usage and traditionally Linux has been terrible at that due to lack of proprietary & highly tuned drivers

Good for you. Nobody is challenging what a web app can or cannot do. I love PWAs but services I need every day either don't have a web interface at all, have limited features or are unusable on a small screen let alone having a PWA. This is not about technical abilities but about what companies actually do.

Nothing is stopping you. You're free to use a desktop web app that either doesn't work or is terribly slow or has limited features on a mobile web browser. I'd love it if all apps were PWAs but that is not the case.

Apps. We'd love a completely different OS and it is viable on desktop because web almost does everything but on mobile you're basically locked out of very essential functionality like banking, transit, messaging etc. The compatibility layers aren't good enough (yet) to offer a seamless experience.

Thanks. Just set my shell and all IDEs to this. Perfect!

I check HN a few times a day. Anything I miss is probably not worth it anyway. Never felt I need to "keep up" with it.

Looks so nice. What is the easiest way to use this in ghostty+fish?

Exactly. This is how I design agents as well. I essentially treat the agent as the web/mobile app, cli tool os API library not as part of my backend even though there is where it runs. The backend doesn't treat the agent in any special way. It simply gates all action based on the permissions of the user/guest that is using the agent.

In my experience, Dart/Flutter has been so much better than React. Go has been really good for the backend. Basically if the framework/language gives you structure and one way to do things, agents tend to create less mess with less guardrails from you.

Exciting! Maybe techniques like these can enable systems with 30-60GB memory and very fast SSDs of the future run very large models hopefully.

For anyone interested in this - https://www.youtube.com/watch?v=gPJkM95KpKo

oh boy

- discuss the plan, dos-and-donts, instructions and have them add it to a PLAN_FEATURE.md with the goal, non-goal, non-negotiables, technical details on the top. - come up with phases to implement your thing. P1, P2, ... P8.. whatever - in each phase add simple one line TODOs with as much explanantion of the task as needed e.g, - [ ] Update DB schema, - [ ] Generate migrations - Ask the agent to go one phase or todo at a time depending on complexity. - if the context fills up, /clear the window and just ask it to do the next line. - if you wrote up all you care about in the plan properly, it'll follow what you need it to do.

Sure - define your project standards in the repo or agent's skill and tell it just that.

You have to treat it like a co-worker send you PRs for review. You review, ask to improve/cleanup stuff and it'll follow up. You can even ask it to remember so it follows the patterns in future. Even better, if you work with it to come up with a design first and then send it coding, you often don't need as much cleanup as the desired architecture is agreed upon early.

Enables the best git command ever: git bisect

Answer to almost all of your questions is that it entirely depends on the service what kind of auth implementation they offer. I personally have completely adopted passkeys and use them with every service that allows it.

I use ProtonPass and have made it the default password store on every device and browser. This way all passkeys get stored in proton and I can login from any other personal device with proton setup.

Yeah but they were intentionally trying to build a better C++/Java, not a better C. It wasn't even aimed at things that C is good at. It was mostly aimed at writing high performance servers that have to scale really big not only in terms of performance but software complexity, size and contributions. So Go is a better C++ or Java for writing servers according to its creators.

Isn't this basically the same a Framework Desktop which has been out for quite a while? Does it improve on it in any way?

https://frame.work/desktop

I've been considering it as well. I'm using 1.5TB in google one storage. mostly from photos/videos from the last decade from 4 family members.

Have you thought about backups and redundancy? I was thinking of hosting it on my homelab with backups on some cheap cloud storage but almost any cloud storage ends up costing somewhat similar to Google One so I've been a bit reluctant.

A good backup story is probably the only thing keeping me from switching.

My cousin just dumped 50GB of photos from his weddings in a Google Drive folder and shared with his contacts. I wanted to extract photos of my immediate family members from it and just save those. I setup immich on my macbook to do this but sadly I found the face recognition is nowhere near as good as Google Photos. It missed a lot of photos with tricky angles. Other than that, everything else looked quite solid to me.

Choosing 1 is totally fine but that doesn't mean it should not be possible to choose 2, right? Just because I don't need a feature doesn't mean I loudly complain when others ask for it.

I want to host an instance for me and my family. Right now we have a Google One instance shared by 5 people. Having e2e means my family members can rest assured that I or whoever I share admin rights with cannot look at their private photos. It's an important enough feature even without thinking about 3rd party bad actors.

Interesting. For me if I want to keep my lab stable, I have to ensure I pin all images and components to a specific version. I rarely but deliberately upgrade them (2-3 months). I feel putting things on auto-update is bound to break stuff and force you to spend time on it at the worst possible times.

Depends. If you backend is just one service, it is not a big deal but then you don't JWT at all. You just need a regular cookie/token.

If your backend is a set of 12 services where each needs to verify the authenticity of the request then it might start adding up. In that case using JWT _after_ the initial API gateway makes a lot of sense. The gateway hits the DB, authenticates the request, mints a JWT and injects it into downstream requests. Then each service on the request path just verifies the JWT.

Overall I don't think hitting the DB for auth is a big deal and that is why we don't need all the bells and whistles JWT brings. Just use bearer auth.

This. Totally defeats the purpose of having JWTs if you have to hit the DB or some service to validate the token every time.

They aren't insecure really. They're pretty secure by design but people are using them for things they were never designed for like web/mobile client auth.

JWTs are awesome but they are are being overused by people. People use them in web, on mobile and everywhere in between. Places where cookie or bearer token auth has already solved the problems. JWTs strength is that it can be verified independently without real-time coordination between services. So a service can issue a JWT with auth scopes to a user. The user can take the JWT to any other service and if that service trusts the signer, it'll allow the user access and also get basic user info from the token itself. The service doesn't need to make an API call to the issuing service or even know if/where it exists. That is where JWT is really powerful.

For web/mobile auth where same server issues the JWT and same server verifies it, it makes no sense. JWTs cannot be invalidated. If a user loses some permission or account gets disabled, JWT will still be valid until its expiration time. Servers must either make DB calls to verify the user is still active or be fine with deactivated users having access for a while after account is disabled. This completely defeats the purpose and bearer tokens work perfectly for this use case.

JWTs should _almost_ never be used in client side auth. Client should send regular cookies and bearer tokens. The auth server can internally generate a short lived JWT and inject it into requests before they get routed to various services internally so those services don't need to query DB every time to verify the user.

Make it as perform as well or close to Apple Silicon and give me free access to Linux dev environment and I will give this a shot.

I really is impressive. I wish publishers like EA and anti-cheat developers weren't so reluctant to support it. I hope Steam devices and SteamOS gain enough traction to force their hands.