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.
I have my seed box limit upload bandwidth to quite a low value, not because I hate leechers, but because I have to spread out my available data cap to maximize availability over the long term. If I blow through my data in three days I’m not as much good to the network.
Seed. I’d rather have at least one whole copy in a swarm versus a bunch of really fast peers that don’t have the complete files.
Really? I’ve been told by all my dudes into hardware that AMD is where it’s at for value. Plus, Intel has manufacturing issues. I’m sure there’s good deal out there if you look, but I feel dissonance between this article and what I hear in my circle.
I appreciate a simple piece of software that does exactly what it’s supposed to do.
It’s not just that. Imagine the dependency management trying to hold onto 32 bit compatibility.
I have a simple pile of Markdown files that I edit with Obsidian. I like the simple text file format because it keeps my documentation forwards-compatible. I use OpenWRT at the heart of my network, so I keep I right there in root’s home. Every long while I back it up to my general Documents which is then synced between my high-storage devices with SyncThing.
The h265 hardware support is a lot less exciting than you might think. Most hardware that has support to encode it doesn’t even use the hardware encoders anyway because a software encoder produces a significantly better result. I would make sure you have CPU power to handle your transcoding, and I haven’t has any issues transcoding that resolution on my quite old Intel® Core™ i5-4590T CPU @ 2.00GHz.
A Raspi is probably not going to be enough for reliable video transcoding at high resolutions, but I haven’t tried it myself. You certainly have more upgrade path options with a mini-PC while still keeping a low power target.
I agree that distro is not very important if you’re running your services in Docker containers anyway. It’s mostly whatever you find comfortable. My personal recommendation is don’t get too creative unless you enjoy setting up servers. I tend to be conservative in my server OSs.
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.
You can pry my 1080 from my cold dead hands.
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.
Perhaps I’m making a wrong assumption that Microsoft is trying to build some sort of PC compatible gaming store around the device that I see as an inevitable failure. Maybe it will be something completely different and open.
And of course, just because I fail to understand the goal of this device doesn’t mean that it doesn’t have one with merit. It still got half the year to build up hype targeting a 2025 holiday season release.
We already have Windows handhelds. There’s some comparisons here with Windows phone and the smart phone OS industry. If it is to be successful that’s quite the uphill battle being late to the game.
Interesting, although I wonder if they’re going to fall into the trap that everyone else has. It’s not good enough to just make a handheld. You need to have a great ecosystem surrounding it, and Steam is one of the very best for gaming that actually seems to respect its users.
How do you plan to be better than Steam? This is the question that this product fails to answer. If it doesn’t come up with a truly impressive answer soon, it’s dead on arrival.
My money is on no one remembering this device after six months.
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.
Definitely share your initial concern. Without strong review processes to ensure that every line of code follows the intent of the human developer, there’s no way of knowing what exactly is in there and the implications for the human users. And I’m not just talking about bugs.
They say it’s reviewed, but the temptation to blindly trust is there. In this case, developer appears to have taken some care.
Let us hope so. Handle with care to ensure responsibility is not offloaded to a machine instead of a person.