max-privatevoid

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).

iroh is meant to be this library, but there is also libp2p, which existed before iroh.

That's the point of ICDs. That's why you link to e.g. vulkan-loader instead of directly to the driver library.

Done. https://github.com/Rust-GPU/rust-gpu/issues/351

Rust GPU libraries such as wgpu and ash rely on external libraries such as vulkan-loader to load the actual ICDs, but for some reason Rust people really love dlopening them instead of linking to them normally. Then it's up to the consumer to configure their linker flags correctly so RPATH gets set correctly when needed, but because most people don't know how to use their linker, they usually end up with dumb hacks like these instead:

https://github.com/Rust-GPU/rust-gpu/blob/87ea628070561f576a...

https://github.com/gfx-rs/wgpu/blob/bf86ac3489614ed2b212ea2f...

It would be great if Rust people learned how to properly load GPU libraries first.

That's true for this and many other features of Zed. For example, telemetry can be disabled with a simple switch. However, I feel deeply uncomfortable knowing that my editor is ready to report every file I open, commit I make, code action I perform, etc. at a moment's notice, held back only by that one line in my config file.

Surely this has to be a joke. If I wanted to write web stuff in XML, I would just write HTML.

Using "Secure Boot" with MS keys is not real Secure Boot. It's "Microsoft decides what you may boot". Enrolling your own keys should be the standard way of operating. shim is a joke.

Bad habits do happen. I forced myself out of `sudo su` and into `sudo -i` by configuring my sudo rule to allow any command except `su`.

The inference engine can do whatever it wants. This is already the case. The actual format of the tool call text varies by model, and the inference engine handles the translation from/to the JSON representation, that's the least of its concerns.

What I don't want to happen is for some shitty webdev who writes an AI client in JavaScript to be forced to write a custom parser for some bespoke tool call language (call it "MLML", the Machine Learning Markup Language, to be superseded by YAMLML and then YAYAMLML, ...), or god forbid, somehow embed a WASM build of Python in their project to be able to `import ast`, instead of just parsing JSON and looking at the fields of the resulting object.