HN user
I encourage you to actually read the OP if you haven't, because I think it gives the most obvious example for that. That kind of app makes much more sense (for the user) to be a web app, especially when you don't intend to become a repeat customer.
It's a mystery to me why everyone tries to use OnCalendar here, when "n amount of times within a certain timeframe" can be done much more easily with OnActiveSec, in this case that'd be OnActiveSec=6h.
The online documentation does not suggest that using a generic OpenAI-compatible server is an option, and it once again lists the non-local option first.
https://atomicapp.ai/getting-started/ai-providers/
OpenAI-compatible is indeed one of the provider options for Atomic. Ollama and openRouter are separate options to allow for easier selection of models from these specific providers.
Why is this necessary over just presenting the result of `/v1/models`?
You can say it's just the ordering of a dropdown, but to me it seems pretty clear that this thing is developed with the idea that you'll most likely use a SaaS provider.
Yes. Why even call it local-first when local isn't first? Not to mention, for some reason they decided to only support Ollama instead of giving you the option to connect to any OpenAI-compatible server, which would make this work with any other inference server such as llama.cpp and vLLM as well as Ollama. (and also most SaaS inference providers, including OpenRouter, so the custom integration would not be necessary either, https://schizo.cooking/schizo-takes/9.html)
I sure love when the local-first software defaults to a non-local option for its main feature.
I'll believe it when it's FOSS
If you release it as GPL or AGPL, it should be pretty difficult to obey those terms while using the code for AI training. Of course, they'll probably scoop it up anyway, regardless of license.
I'm surprised no one has said NixOS yet.
The only good Claude.md is a deleted Claude.md.
The idea is awful as well if you spend one second thinking about dependency sharing.
It's insane that Zig was needed to achieve this, instead of a preprocessor definition like "#define GLIBC_MIN_COMPATIBLE_VERSION GLIBC_2_40".
Clicking on "Customize" on the cookie consent banner reveals toggles for the following:
Analytics Cookies
Help us understand how visitors interact with our website. We use privacy-first analytics.
Tracking.
Marketing Cookies
Used to track visitors and show relevant advertisements.
Ads and more tracking.
Preference Cookies
Remember your preferences like language and theme settings.
Do these actually require separate consent, or can they be considered functional?
I would expect that a European digital sovereignty project in which privacy is the whole point would not have a cookie consent banner at all, because it would simply not use any non-functional cookies that would require it. I see the cookie banner as a sort of "mark of shame" that nefarious websites are forced to wear.
Also, I recall hearing that there were plans to make highlighting the "Accept All" button above the other options illegal, because it's a dark pattern that gets people to click the highlighted option more often.
Why does this have ads and tracking?
Docker is unusable for build tools that use namespaces (of which Docker itself is one), unless you use privileged mode and throw away much more security than you'd need to. Docker images are difficult to reproduce with conventional Docker tools, and using a non-reproducible base image for your build environment seems like a rather bad idea.
The collab editing stuff was Zed's original gimmick. The AI stuff is the real feature creep.
Why use Docker as a build job execution engine? It seems terribly unsuited for this.
What prevents you from just using certificates not signed by a CA and verifying them based on the public key fingerprint?
You can't disallow hole punching.
Why go through the effort of reimplementing all this instead of using libp2p?
MinIO has a CLA, so they're in the exact same situation as HashiCorp, just not as far ahead.
Perhaps this will eventually lead them to give up on spying on users altogether.
Careful, it's CLAware.
I think the proper way to do this would be a DCO. https://developercertificate.org/
Indeed, if you discount all the instances where it is true, it is not true.
From my understanding, Zed is GPL-3.0-or-later. Most projects that involve a CLA and have rugpull potential are licensed as some GPL or AGPLv3, as those are the licenses that protect everyone's rights the strongest, and thanks to the CLA trap, the definition of "everyone" can be limited to just the company who created the project.
https://github.com/zed-industries/zed/blob/main/crates/zed/C...
Even opt-in telemetry makes me feel uncomfortable. I am always aware that the software is capable of reporting the size of my underwear and what I had for breakfast this morning at any moment, held back only by a single checkbox. As for the other features, opt-out stuff just feels like a nuisance, having to say "No, I don't want this" over and over again. In some cases it's a matter of balance, but generally I want to lean towards minimalism.
Yeah it looks pretty funny. Probably happens because it's not a fork as far as GitHub is concerned (had some problems with that). Looking at PR creators should give you a better idea. It's basically just me right now.
https://github.com/zedless-editor/zed/pulls?q=is%3Apr+is%3Ac...
It shouldn't be as tightly integrated into the editor as it is. Zed uses it for a lot of things, including to install various language servers and other things via NPM, which is just nasty.
I'm concerned about relicensing. See HashiCorp.
I like to think of the relationship between Zed and Zedless more like Chromium and ungoogled-chromium.
We can stop calling it spyware once it is not spyware (will never happen).