3·
24 days agoTalos is amazing and if you want to start from a fully automated setup (GitOps, Renovate), I highly recommend using https://github.com/onedr0p/cluster-template
- 2 Posts
- 39 Comments
Joined 3 years ago
Cake day: June 11th, 2023
You are not logged in. If you use a Fediverse account that is able to follow users, you can follow this user.
Glad you found your ideal selfhosting setup!
Enjoy!
Dococd + renovate goes brrr
Docker Compose is really the easiest way to self-host.
Copy a file, usually provided by the developers of the app you want to run, change some values if instructed by the
# comments, rundocker compose upand it “just works”.And I say that as someone who has done everything from distro-provided packages to compiling from source, Nix, podman systemd, and currently running a full-blown multi-node distributed storage Kubernetes cluster at home.
Just use docker compose.
I installed VoidLinux on a 17 year old laptop with 2GB of DDR2
Is that like teaching grandpa factorio?
Old PCs are plenty powerful and compatible with everything, but if energy consumption is a major concern, an old phone can work too.
You are 100% right that Android is a very weird Linux and Termux is limited.
PostmarketOS is a project that enables installation of a full upstream Linux onto old phones. Then you can run whatever (ARM-supporting) distro you like on it, without weird kernel limitations.
More likely: SQLite is built to be small, simple and lightweight, not to be super highly concurrent.
If this situation happens rarely, just make sure you have a retry on the query. If it happens often, switch to postgres.
Nullable:
Type?meansTypeornull
You’re not advertising 196.x.x.x routes to your tailnet?
I think you are confusing a license to use “enterprise edition” yourself, with a “license to provide the product (as a service) to customers”, as is required under SSPL.
SSPL is not AGPL: you can never be sure you comply with “or make your code available” due to the way this is worded. Please read https://www.ssplisbad.com/ before arguing that it is the same as AGPL.
That’s how they’re trying to sell it. But why did Elastic and Redis drop SSPL if it was so good, and why did OSI not accept it as open source? The answers are here but the TLDR is that SSPL is vague and, as a consequence, makes it risky to provide a service with the product, unless you are large enough to make a big lucrative deal with the owner of the product.
This stifles competition and innovation.
Case in point: Mongo DBAs are nearly non-existent outside California and managed MongoDB is much more expensive than managed PostgreSQL/MariaDB services, because it is only offered by 3 providers.
Saying you are “MongoDB compatible” is IP violation?
Meanwhile they are still actively opposing the creation of an open document database standard, which would make it unnecessary to use their brand name to indicate compatibility.
They also sent Peter a “Cease And Desist” for saying MongoDB is not open source. They themselves retracted the SSPL from the OSI when it became clear it would be rejected because it is not open source.
Wonder how much 💩 is in their heads for not realizing everyone gave up on SSPL, and that Postgres is thriving because of the permissive license: even the tiniest local managed services providers have a Postgresql service, there’s tons of DBA talent available, and due to the competition in managed services, a managed postgres is much cheaper than managed MongoDB.
They’ll keep shooting themselves in the foot until someone else puts a lead shoe on it.
Shoutout to FerretDB doing God’s work.
Putting data from apps that were built for MongoDB into Postgres.
https://github.com/FerretDB/FerretDB
And their lived experience trying to help the MongoDB ecosystem by building an open standard for document databases:
In 2021, we founded FerretDB with a bold vision: to return the document database market to its open source roots by creating the leading open source alternative to MongoDB, built on Postgres.
For years, we tirelessly advocated for an open standard. We built a popular product, collaborated with Microsoft to open source DocumentDB, and held high-level meetings with cloud providers and stakeholders to make the case for a standard that is similar to SQL, but for document databases.
In 2023, a MongoDB VP reached out to me. On a Zoom call, we were threatened with a lawsuit for building a compatible product. Being called a thief by a leader of a (then) $35B company was a moment of stark clarity on MongoDB’s opinion about our work and the need for a standard. At the end of that call, I told them the industry would inevitably come together to create the open standard they refused to provide.
Their response? “They would never do that. They are our trusted partners.”
Today, the market has spoken. The Linux Foundation has announced the adoption of the DocumentDB project [1] to create an open standard with MongoDB compatibility, the exact thing we were sued for earlier this year. [2]
This is a monumental win for developers and enterprises everywhere. It validates the years of work we’ve poured into this mission.
It is also telling that MongoDB’s SSPL license has been abandoned by Elastic or Redis, the two prominent companies who were initially in favor of MongoDB’s attempt to redefine open source. All clear signs that MongoDB’s behavior is not appreciated by developers. […]
381·7 months agoI don’t agree with /u/red-crayon-scribbles ’ approach to memory safety, but what you’re saying isn’t entirely true either.
It is possible to manipulate memory in ways that do not conform to Rust’s lifecycle/ownership model. In theory, this can even be done correctly.
The problem is that in practice, this leads to the following, many of which were committed by some of the most highly skilled C developers alive, including major kernel contributors:
If selfhosting the family chat is not a goal in itself and it’s about privacy or being independent from big tech, just take the loss and go to Signal. Much smoother experience than any self-hosted messenger can provide for now.
The problem with non-PLP drives is that Rook-Ceph will insist that its writes get done in a way that is safe wrt power loss.
For regular consumer drives, that means it has to wait for the cache to be flushed, which takes aaaages (milliseconds!!) and that can cause all kinds of issues. PLP drives have a cache that is safe in the event of power loss, and thus Rook-Ceph is happy to write to cache and consider the operation done.
Again, 1Gb network is not a big deal, not using PLP drives could cause issues.
If you don’t need volsync and don’t need ReadWriteMany, just use Longhorn with its builtin backup system and call it a day.
I tried Longhorn, and ended up concluding that it would not work reliably with Volsync. Volsync (for automatic volume restore on cluster rebuild) is a must for me.
I plan on installing Rook-Ceph. I’m also on 1Gb/s network, so it won’t be fast, but many fellow K8s home opsers are confident it will work.
Rook-ceph does need SSDs with Power Loss Protection (PLP), or it will get extremelly slow (latency). Bandwidth is not as much of an issue. Find some used Samsung PM or SM models, they aren’t expensive.
Longhorn isn’t fussy about consumer SSDs and has its own built-in backup system. It’s not good at ReadWriteMany volumes, but it sounds like you won’t need ReadWriteMany. I suggest you don’t bother with Rook-Ceph yet, as it’s very complex.
Also, join the Home Operations community if you have a Discord account, it’s full of k8s homelabbers.
Volsync