- 6 Posts
- 121 Comments
1·1 month agoIt’s copy-pasted, not linked, but this is essentially a crosspost of: https://lemmy.ml/post/36614892
There are some good answers there already
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. […]
Tell your buddy you can play Helldivers with him!
Helldivers 1 and 2 are platinum and gold rated on ProtonDB with recent reports on both confirming they work well.
381·3 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:
71·3 months agoIf 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.
62·4 months agoYep, as for the last point: the problem was not so much the devs but data going through a Chinese server
If Mint works for you, just stick with it. No need to try a different distribution to compare. You’ll know when you need it.
I would only go to Fedora if you need it. For example newer drivers (kernel, mesa). Don’t go change the kernel and/or mesa on a distribution, probably better to switch at that point. Or if you need KDE or GNOME for some reason. Wayland is disabled in Mint by default, but can be enabled. It’s been over a year IIRC since they added experimental Wayland support so it may be fine by now.
Differences between Linux distributions are exaggerated.
Mint is a great choice, it is very stable, and it really holds your hand via the Software Center.
However, stable also means old: it does not support the latest hardware.
If you have hardware that released after (rough estimate) April 2024, consider something based on Fedora, such as Bazzite, instead. It comes with modern drivers and should support modern hardware much better.
keep it on cache since I do a lot of code compilation, but I will usually switch it to frequency for gaming and stuff.
Isn’t gaming the most cache-heavy CPU workload there is? The X3D CPUs have consistently topped gaming benchmarks, even outperforming much more modern CPUs that lack 3D cache.
I’d sooner do it the other way around: frequency for compiling, rendering, transcoding, etc. Cache for gaming!
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.
The article says it can debug TUIs, similar to what the browser’s debug panel does for web apps. That is useful for TUI developers.
Other than that, I don’t know either what Kitty is missing.
Finally, the end of “it doesn’t work on Wayland” is in sight. Just in time for Windows 10 EoL too
Nullable:
Type?meansTypeornull