i’d avoid BIOS-based RAID… it doesn’t really offer many benefits over linux-based raid like MDADM, and MDADM offers a LOT of up-sides for portability, repairability, diagnostics, etc
i’d avoid BIOS-based RAID… it doesn’t really offer many benefits over linux-based raid like MDADM, and MDADM offers a LOT of up-sides for portability, repairability, diagnostics, etc
yeah stupid people like most tech workers who just need their tech to work as expected rather than be “customisable”
there’s value in the “just works” when not working costs you hundreds of $ per hour that it doesn’t work
$2000 for a phone is nothing when it’s a professional device
i’m sure they learned plenty of things about the old game engine they built
and now they have a new one… which was the whole point
yes and no… we don’t have revenue goals, but we have goals for the fediverse and we have the social media critical mass problem: you have to hit a critical mass before you become indispensable… if people try the fediverse and there’s not enough content, they tend to just leave rather than stick with it
mastodon can do default instances because they have the account migration process… i totally agree this is a great solution: get people in with sane defaults, and then let people move once they know how it works
there will be plenty of people that don’t move (or maybe that’s solvable too: analyse your toots and suggest a more niche instance after 2mo?) but i’m not sure that’s a huge problem if your “default instance” is more of a random choice from a list of sane defaults
it’s kinda vaguely similar though… a fediverse instance is moderated by the instance admins, just like a discord server (though discord has a level of admin above server mod/admin i’m not sure that distinction matters for the general user)
HTTPS is heavy when you’re talking about the extreme low power, bandwidth, and compute devices matter is intending to support
its also not a broadcast protocol - matter intends to connect many devices to many devices
those are off the top of my head; i’m sure there are more. HTTP is great, but new/alternate network protocols aren’t inherently bad: especially when you’re operating in a very constrained/niche environment
i mean… to deny the similarities in the platform is kinda ridiculous… i’d go so far as to say that lemmy/kbin probably wouldn’t have the format it does without reddit being like it is. there’s a direct relationship, whether we like it or not
“even”… i think reddit’s follow ups were least likely to succeed because they were the least organic!
place was special (at first) because it was a bunch of people with no time to plan and prepare… it was humans doing human things with all the limitations and creativity that came with that
other iterations of place were bots and pre-planned “stake our claim” rather than making something interesting and different… it was kinda all just the same as the last one but with subtle “meme of the moment” tweaks
of course nobody is going to commit to supporting a stable API for 10 to 20 years… that’s expensive as heck and not even remotely worth it!
there’s nothing “wrong” with software development, it’s just that consumers demand new features rather than stagnation… i sure don’t want to be using a 20 year old app because we’ve come a long way in 20 years in so many regards
in 2003, windows xp was still microsoft’s dominant OS with vista still being several years off, half life 2 was about to be released, gmail was allllmost ready to release, msn messenger was still in its prime
yeah no, ill stick with rapidly changing technologies rather than sticking to that for some misplaced sense of “stability”
you’re missing the fact that google chat and XMPP is a totally different situation… they used an open protocol; they didn’t open their backend
sure, but an open source UI isn’t going to change that… they’d just close the source!
sure you can fork it, but you can also just copy the UI to an open source clone
imagine if twitter were activitypub: kinda like having an OSS backend with a proprietary front end… i’d bet the move to mastodon would be far quicker… network effects keep people on twitter… same here with OSS backend: we can reimplement the UI and people will have the same experience
yeah… pragmatism beats purity every time: they’re doing some great work, but to do that great work they have to fund it somehow… i think that open sourcing all of the functional components (the bridges) and keeping the shiny UI closed is a pretty good way of doing that!
i guess i get not wanting to used closed source clients too, but it’s shades of grey: people shouldn’t hate on them for keeping 1 part closed source!
so i just did a quick search and apparently
Starting with Gitea 1.19, Gitea Actions are available as a built-in CI/CD solution.
*edited:
also they support being a package repo, including container registry
their clients are proprietary but it’s built on matrix (federated chat kinda like xmpp) and their bridges (things that connect matrix to other protocols) are open source
they say you can use any matrix client, and that you can host your own home server with their bridges
it is matrix yes! and they’re contributing back to the upstream bridges
from their website:
Remember this XKCD comic? That’s why we built Beeper on the open source chat protocol Matrix. Unlike other chat networks, there is no lock-in. You’re free to use open source Matrix clients to connect to Beeper, or download your data and move to a different Matrix server and continue chatting with your friends on Beeper.
Beeper contributes back to the Matrix community. All of our Matrix bridges are open source on our Github. Don’t want to pay for Beeper? Self-host your own instance for free.
not related to backup solution, but this is a great time to get some home monitoring sorted! put prometheus on it, run prometheus at home too, and have them monitor each other… great way to know why/when things aren’t working in general, but adds another level of confidence that your data are nice and safe
so what you ideally want is people to ONLY be able to access your backend service through caddy, so caddy should be the only one with ports publicly accessible, yes
caddy running in the same docker network as your services can talk to those services on their original ports; they don’t need to even be mapped to the host! in this case, you have 3 containers: caddy, service 1, service 2… caddy is the only one that needs to have ports forwarded and you can just forward caddy:443 and no need to worry! then caddy can talk directly to services:80 or services:443 (docker containers show up to other docker containers by their container name! so if you run eg: docker run … —name lemmy, then caddy in the same docker network would be able to connect to http://lemmy:80!)
… but if you forward say service 1 and 2 on :8443 and :9443 (without firewall, and even with it makes me uncomfortable - that’s 1 step away from a subtle security problem), someone could be able to access <yourserver>:8443, right? so they don’t have to go through caddy to get to the backend service… for some services, that can be a big deal in ways that it’s difficult to understand, so it’s best to just not allow it if possible
an alternative is to make sure your services are firewalled so that nobody from the internet can hit them, but caddy still can… but i like this less, because it’s less explicit what’s happening so it’s easier to forget about
i think it’d be possible, but probably more about sponsor ads entirely rather than youtube ad revenue… i believe that’s the way most youtubers make the majority of their money anyway - ads from youtube are worth peanuts
kinda the same reason people suggest something like linux mint over slackware, gentoo, arch, etc… mint is easy to install and is preconfigured to be an easy to use user desktop environment. you can configure any other option to be have like that, but they tend to be a bit more “DIY”, which is great if you know what you’re doing!
dedicated NAS OSes will have good software out of the box that make it easy to configure and manage various common disk-related configurations (RAID, SMB, NFS, etc). you can certainly do all this yourself, but it might not have a pretty, unified user interface, or you might have to deal with software that isn’t compatible with some version of a library that’s in your distro of choice… all resolvable things, but they take time to solve: anywhere from installing a package manually to applying a kernel patch and recompiling the kernel to get something to work