Right, I did hear about that lawsuit way back when, I just didn’t know of these types of consequences. Very appreciated, especially the sources.

Is this for hardware RAID controllers, or have you experience software RAID like LVM or ZFS exhibiting the same drop out behavior? I personally haven’t but it be nice to look out for future drives.

Does Backblaze work for what you are doing? It been a bit since I’ve price compared them, but I think it was something around 5$ a month per TB?

Those are distinct distros, while Bedrock is a layer that sits on top of multiple different distros and actively merges them together. At a glance, vanilla doesnt look like they merge/manage other distros at all? So I’m not sure the comparison makes sense. BlendOS is a completely different approach by using containers to isolate the different systems. Bedrock wants to merge the different systems where ever possible. I wouldn’t say either is better or worse as their goals appear to be entirely different.

Have you ever heard of Bedrock Linux? Its an extremely interesting “meta-distro” that let’s you run multiple different distros at the same time only marginally isolated. The whole premise is to merge the systems together instead of separating them with a container style workflow. Tons of stuff works cross distro to! Its extremely cool to have Debian AND Arch packages just installed the normal way on each distro. Its a beautiful and horrifying system, that warms my heart every time I remember it.

I’m reasonably sure that AV1 has better or at least similar size ratios. They also explicitly mentioned wanting to use libre codecs, which h265 is not.

Here’s a link to an instance of radicle for Yuzu. It’s a p2p git server implementation. I haven’t looked too much into it yet, but the tech seems interesting.

The post you originally replied to was misunderstanding how the username is located when authenticating with a server.

Original post:

The public key contains a user name/email address string, I’m aware, is the same information also encoded into the private key as well?

Your reply would be creating more confusion, because you implied that no username is required.

Your reply:

That means the corresponding public key that was uploaded to the git server is enough to authenticate and no username is required.

I am just clarifying if the original poster read your comment and was led to believe they wouldn’t need a username. It is, in fact, required. As you expressed, it’s usually “git” when connecting to a a git server, but it doesn’t have to be.

That means the corresponding public key that was uploaded to the git server is enough to authenticate and no username is required.

A username is required to authenticate with an SSH server. A public key alone is not enough.

Oh that’s a cool resource, thanks for the share.

Pardon me for asking, but this looks very strange. 10$ a year, when most VPS hosts I see are 5$ish a month, and the website is default WordPress stuff with literally nothing in their knowledge base, and two blog posts. Also your link is to https://cloudserver.net Where as when I lookup the name, https://www.cloudserver.net/. A totally different looking website. What is this?

The paywall as far as I know isn’t that much of problem. Cemu has/had a paywall for years. Several other, though less successful, emulators have had paywalled content/early access as well. The BLEEM emulator that was brought to court was a paid commercial product. So that currently is perfectly legal within the jurisdiction of those cases. Nintendo’s case against Yuzu was about piracy/DRM circumvention. That wasn’t brought to court, so we don’t know the outcome however.

I don’t believe Yuzu went to court, but that was the accusation Nintendo was suing them over. Ryujinx wasn’t sued, so Nintendo either didn’t believe they had done the same, or didn’t care. We didn’t get to have a discovery process for the case to find out for sure, so we don’t know.

IANAL, but they should be fine since they aren’t decrypting / breaking DRM they same way Yuzu was. They are a much cleaner codebase, much more similar to mGBA and Dolphin.

That’s sorta the curse of an open protocol is that anyone, even your enemies, can use them. I am no fan of Meta. I am a big fan of open standards, monkey’s paw and all. It is not a case of tolerating the intolerant. To restrict Meta out of using ActivityPub is against the spirit of open standards. The protocol is no longer open, and THEN we really have something to worry about.

Don’t worry I’ve been quoted EEE enough times. I really don’t think that is the direction this will go down. If Meta actually embraces it, then the whole of the fediverse grows over all. Then, if Meta does extend the ActivityPib protocol in a way the that becomes incompatible with the rest of the ecosystem, we just let them go and do their own thing. ActivityPub already has a userbase, if they join us, and then later on cause problems then everything just goes back to how it is right now. The final E can’t realistically happen because the existing ecosystem will just carry on exactly as it is now. If people on Threads want to communicate with us, then they need to speak the same protocol. If they don’t, then they don’t get to participate.

Do you genuinely believe that the whole community of the fediverse would just lie down and accept breaking changes to the protocol without resistance? There are too many talented and passionate people invested in this ecosystem, the absolute worst case scenario is the protocol itself gets forked, and again the exist communities just carry on. There is no extinguish time line. Everyone points to how Meta handled XMPP, please compare the user bases of ActivityPub vs XMPP. The world has changed a lot since then. Another example I’d like to point out is Hashicorp’s Terraform. They explicitly tried to EEE, and the moment they attempted the final E, it was instantly forked, and the open licensed fork was adopted into the Linux Foundation and the ecosystem carried on.

Take that what you will, but I am reasonably convinced ActivityPub has enough support and community that any EEE attempt will inevitably fail. The front ends will change, the hosters will come and go, the open standard is here to stay.

They are very diverged projects, but share the same philosophy. The Nix packages themselves aren’t the problem, its the organization backing them. So this fork is attempting to create better governance and organization, so that the good underlying tech can keep going and progress.

For example, Flakes have been held back from truly flourishing because the governing body has purposefully held back changes to those systems for nontechnical problems, but rather political conflicts with their proprietary offerings.

Think of the fork the same way we had the Alma/Rocky forks off of CentOS. Its political rather than technical, so keeping the same base tech helps adoption. Over time we can improve or replace parts of the ecosystem as the needs of this new project grow.

What do you mean by Mastodon selling out to Meta? Isn’t Meta just building an ActivityPub based platform so we can talk to their users as far as I know. If they want to talk to us, then the onus is on Meta to stay compatible. If they aren’t, then we just continue on as we have.

Mailing lists are a platform/protocol not really a UI. IRC is trash if all you are using is some terrible web UI, but much better with proper native apps designed around its use cases. Mailing lists are a massive improvement over Discord that so many projects tend to use instead. I’d take a mailing list over a Discord “server” every day.

I would love to host a mirror of the ecosystem once the fork is underway. I made a small attempt a little while ago to create a mirror of the Nix repos but the documentation on how to set it up was lacking. Hosting a Debian mirror is relatively easy, Nix appeared quite a bit more obfuscated.