Even after the owner has realized the attack and revoked the token, there’s next steps (alerting the community, pulling from NPM) that causing havoc delays even by just a bit.
I mean, it's certainly not as seamless as an open x86 machine, but if you have an Air already you can always try Linux on it? The Fedora Asahi spin [1] supports pretty much everything on M1/M2 devices.
I'm...rather confused why the results here are surprising. The title and first paragraph are suggestive of unusual data like analytics or sending all your codebase, but it's just sending the prompt + context.
This is how every LLM API has worked for years; the API is a stateless token machine, and the prompts + turns are managed by the client application. If anything it's interesting how standard it is; no inside baseball, they just use the normal public API.
Fair point — the stateless prompt+context pattern itself is standard, and the headline probably leans too much into “surprise.” The takeaway for me was the opposite of hidden complexity: start simple, don’t over-engineer. Claude Code feels like a good example of a system that’s straightforward, reliable, and easy to reason about.
Dang, everything about this feels really well considered. Semi-throwaway, nearly bare-metal machines that I can put on the internet with basically 0 config? I'll take
Sorry if I missed this in the docs, but how robust is the persistence? ie is it the disk that comes with a standard AWS VM? or is it a share backed by e.g. Ceph with multiple redundant copies?
Details coming in the next few weeks. The contents are regularly replicated to a disk cluster, though we have some more experimentation to do before we commit to exactly how frequently. This space has a lot of trade-offs, we believe we have found a new and interesting one.
If this is your product, my suggestion is you might want to consider a UI element that doesn't break user expectations on load, like maybe a sync button or something that doesn't feel like a buggy frontend but feels more intentional?
It may happen infrequently once you start using it and adopting it but first impressions are important.
Otherwise looks cool and interesting, glad its open source ;)
> But since it is a electron app, it will always contact Google everytime you open the app
Do you have a source for this? I couldn't find anything about this, and I find it strange that Electron (which uses the open-source chromium engine but not Chrome) would automatically send tracking information to Google.
I worked on Haiku this summer as part of Google summer of code, and it just made me wish their attitude towards user experience was more prevalent in mainstream OSs.
It's little things like errors automatically prompting you to open a graphical debugger or processes being grouped by application. There's sensible UX that doesn't expect me to be a wizard to understand what's going on or how to dig deeper.
Obviously it has rough edges (as, well, honestly all operating systems do), but the things that do work work really well.
> It's little things like errors automatically prompting you to open a graphical debugger or processes being grouped by application.
I think after Windows 7 the processes are grouped per application in Task Manager.
We’re all grumpy about the redesigns of things we are familiar with, but little UX improvements happen all the time.
> I think after Windows 7 the processes are grouped per application in Task Manager. We’re all grumpy about the redesigns of things we are familiar with, but little UX improvements happen all the time.
You're right; I was mostly thinking about problems with Linux since thats my daily driver. It would have been better to say that Haiku gives developers the same UX affordances for interacting with their system as non-technical users.
When using Linux I'm frustrated by an overall lack of UX, but when using Windows/Mac it's developer specific UX that's ignored.
FWIW, as with the Task Manager thing, the thing about launching the graphical debugger on crashes was added to Windows eons ago. Even Windows 9x had it, contemporaneously with BeOS. If you had a debugger installed, a "Debug" button would appear between "Close" and "Details". Debug assertion failures will pop up a dialog from the C runtime allowing you to break into the debugger there, too.
Not the Details tab, though, and the name of the executable is shown there. The tree view in Process Explorer (shipped with Sysinternals) is the best of both worlds.
I wanted to point to FOSS (GPL3) alternative ProcessHacker [1] which I'm using for years, and found out that their github link [2] now redirects to systeminformer [3], looks like repo rebranding, wasn't able to find it mentioned anywhere though.
Thanks, I knew about Process Hacker but not System Informer. It's all a bit weird: the download page for System Informer only lists Process Hacker binaries, for "legacy operating systems", while there are no binaries yet for "supported operating systems".
> I think that shows what the target audience is. I think most people wouldn’t know what to do with that prompt, other than immediately discard it.
That's a fair complaint, and I'm definitely biased since I'm technically oriented. That said, discarding it is totally fine as long as people who want it at least get the option; and if even showing it is too confusing to users, it's a lot better to have a "developer" toggle in settings that enables all this stuff, rather than not having it at all.
Haiku's certainly not crazy accessible right now, but it has some ideas that I think other OSs should take note of.
> attitude towards user experience was more prevalent in mainstream OSs.
> It's little things like errors automatically prompting you to open a graphical debugger
If this is the concept of "mainstream" and sensible "user experience" it sounds like Haiku is a complete bunch of horseshit. (And this feature is easily available in Windows anyway)
