

Even more broadly, you’re seeing regulatory capture. Money gets whatever rules it wants.
This is a secondary account that sees the most usage. My first account is listed below. The main will have a list of all the accounts that I use.
Garbage: Purple quickly jumps candle over whispering galaxy banana chair flute rocks.
Even more broadly, you’re seeing regulatory capture. Money gets whatever rules it wants.
I absolutely love the term clankers. It’s the perfect blend of dystopian cyberpunk and the very real threat of AI.
I like this solution because I can have the need filled without a central server. I use old-fashioned offline backups for my low-churn, bulk data, and SyncThing for everything else to be eventually consistent everywhere.
If my data was big enough so as to require dedicated storage though, I’d probably go with TrueNAS.
Note that the official documentation says that it’s experimental and may leak your IP address.
Then use decentralized links or hashes, which is what IPFS uses to identify content. A character limit doesn’t solve this problem fundamentally. Indeed, it’s been a tough problem to solve for decentralized services.
I’m concerned about the large amount of low quality, vaporware/crypto applications built on IPFS which is the same core technology used here. It’s concerning how many clicks it takes to get technical specs for the underlying work, like libp2p for the network layer, which itself espouses only vague ideas on its main website that seems to focus a lot more on presentation than technical merit. Even the GitHub admits that the spec that most of these apps are relying upon is, well, unspecified.
Your project source downloads and runs an executable. That’s a little bit SUS; it would be much better if you compiled/built this core code as part of your build process, else, it’s not much in the way of source code, no? But, it works. It seems to delegate just fine, and few understand how to actually talk IPFS directly. But, this is the most important part!
I think the biggest tell that IPFS borders on vaporware is that there’s very little discussion about concrete specifications and the main problem faced by all DHTs: how you get your data to actually stay hosted on the network over time. These ideas are not new, and you may be better served building your app on technology that has spent vastly more time understanding the fundamental problems.
This is how you write a spec without actually writing a spec. And I’ve written a lot of specs.
This is how you write a spec. Excruciating detail of what actually gets sent over the wire at different levels of the design starting from the very bottom.
Anyway, just my 2c. It’s cool you’ve got functionality at this level and that’s commendable, but I feel it’s built on shoddy foundation of an immature technology. At least it should be easy to migrate to something else in the future as the distributed technology is offload to a separate binary anyway.
Note: Various edits for clarification and to ensure I focus on the code and not the human.
If you’re willing to donate bandwidth, I suggest I2P or a public SyncThing node. My server chews through a terabyte of bandwidth helping people securely access their files. I also run Tor’s Snowflake proxy which helps users reach the network.
I2P is Java. SyncThing and Snowflake are written in Go which means you can’t pull off typical memory corruption attacks in these relatively safe languages, and it’s fairly easy to run them in a container.
I don’t feel like it makes a huge difference for me and I run quite a few servers. It’s mainly the cooling costs in the summer months that run up the bill.
BOINC is great. In its day, you could get an enormous amount of computing power on a shoestring budget thanks to volunteers. It also helped the volunteers feel like they were more a part of something, because they were! I used to have a small server farm crunching numbers for science.
Unfortunately, the landscape has changed. Some projects are still around, but many of the big players have left. Computing power is a lot more accessible now, and the main limitation is time spent analyzing the data rather than the computation itself. Cloud computing can make just about any computation happen fast for a reasonable price without having to own all of that hardware. GPUs have exploded in computation capacity. Just, a lot of factors came together where the need isn’t as great.
With that said, I still run it on one mini PC, but the payoff for having to write your application in a distributed fashion doesn’t have the return on investment that it used to.
Same I just throw it in a desk at work. It’s encrypted anyway.
Can’t we just ignore court orders now?
Overthrow democratic nations 👍 Theoretically the owning class loosing out on a few bucks 😱
Thanks Meta.
Neutrino emissions detected!
I love Caddy. So easy to configure, and the automatic SSL is almost always what I need.
Maybe I’m being stupid but a trivial way to ensure this is just don’t connect it to the Internet in any way. No SIM card. Cut it off from the Internet after setup, and only connect to a LAN with your chosen services all physically isolated from any internet machines.
Different goals and different designs. Why are there so many links distro?
Snap is proprietary. Appimage does not include distribution and updates. It also doesn’t attempt sandboxing of any kind.
On the other hand, I find appimage very convenient to use.
That is definitely a sacrifice being made here I agree with you. It gives developers more control over exactly how their app runs, but it does mean less storage efficiency.
I don’t think Flatpak is going to be compatible with Steam anyway in the long-term because layering container solutions doesn’t generally work very well, and Steam is going to want to use its own solution for better control over the libraries each game uses. Earlier versions used library redirection and some still do.
But y tho?
I don’t think our governments are going to fall. I do think they are however extensions of corporations and over time are becoming increasingly difficult to distinguish from business.