max-privatevoid

> They build the whole OS in CI

As opposed to only building a part of the OS?

Yes, the relay design is very convenient for PDS operators on a technical level, but it comes at the enormous cost of having to trust a third party with message delivery, or, alternatively, running services that are much more expensive than an ActivityPub server.

> for some ridiculous reason

A ridiculous reason, such as being able to interact with the federated world from my own server directly, and not through a third-party service. Why is the simple concept of going to your own server to interact with the entire network, getting content directly from your friends' servers, and receiving interactions (e.g. PRs) directly from someone else's server such an afterthought in ATProto?

When you say "they can run on a $5 VPS", do you mean that the entire server will be dedicated exclusively to processing ATProto data? I run an ActivityPub server on my $5 VPS that allows me to interact with everyone else on ActivityPub, and that VPS is hosting a lot more services than just that.

> Tangled has been entirely self-hostable since the beginning!

As has BlueSky, as long as you had enough hardware to keep up with the firehose. The protocol heavily lends itself to centralization due to this design. I think this should be obvious by the fact that you haven't considered self-hosting to be the default case.

> In our case, those are org.tangled.*.

I suppose my wording was inaccurate, but this is what I meant by "the entire network". My indexer would have to consume "all of Tangled" instead of the things related to the repos, orgs and people I am interested in. Correct?

> ActivityPub categorically does not make sense here because of how coupled identities are to instances.

I feel like this is more of an inconvenience rather than a dealbreaker. Having to point people to a new account ID on the off-chance you lose your domain seems like much less of a problem than having to deal with ATProto's firehose architecture.

They had the mostly-centralized offering up immediately, and now they're spending a lot of time making the parts easier to self-host one by one. What does that say about the protocol? And I assume Tangled also suffers from the general ATProto AppView problem, where your AppView has to consume all the content in the entire network even though 99% of it is likely uninteresting to you.

Code hosting platforms are probably much more disjointed than microblogging platforms, so something like ActivityPub, where servers only keep track of content that users are actually interested in, would make much more sense. It's a shame that the people working on ForgeFed and/or Forgejo federation seemingly aren't making much progress.

For a federated system they sure talk a lot about their struggles around scaling centralized infrastructure. ATProto seems like it's entirely the wrong protocol for this sort of application.

llama.cpp has done this since forever. I've used other engines including vLLM here and there, and I was quite surprised that many of them don't have this feature. Glad vLLM has it now.

It's just LPDDR5X, standard modern laptop RAM. Sure, it's quite a bit faster due to the way it's connected, but comparing it to the VRAM on a dedicated GPU is absurd, especially considering memory on laptops has been "unified" in this way since forever.

It's properly sandboxed, which is a lot better than Google Play Services on regular Android. Far from ideal of course, but I assume GrapheneOS is built with those people in mind for whom Google is unavoidable.

The last couple of Android phones I bought, I rooted within 1 hour of owning them. The current one will probably be my last Android phone.

It's always been a matter of skill issue. An LLM subscription being necessary or not says more about the user than the tool.

That's the wrong domain...

Including Ollama support is the new token "open option", like a cross-platform application that claims to support Windows, macOS, and Linux, and targets Ubuntu 16.04 only. Just target the OpenAI-compatible API with custom endpoints, it's not that hard. https://schizo.cooking/schizo-takes/9.html

An XR glasses company, Nreal, changed their name to XREAL, allegedly because of Epic Games.

> ZDR

Does anyone actually believe this?

> Mistral is the only AI company in the world building the full stack required to answer that question: open-weight models, the infrastructure and the compute capacity they run on

Didn't know Mistral sold affordable inference hardware. /s

My favorite programming language is called "A Programming Language".

> Is there telemetry? Yes, and it is opt-out

Fuck you. Will there ever be a decent agent where the answer to this is "No"?

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