Selfhosted
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don't control.
Rules:
-
Be civil: we're here to support and learn from one another. Insults won't be tolerated. Flame wars are frowned upon.
-
No spam posting.
-
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it's not obvious why your post topic revolves around selfhosting, please include details to make it clear.
-
Don't duplicate the full text of your blog or github here. Just post the link for folks to click.
-
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
-
No trolling.
Resources:
- selfh.st Newsletter and index of selfhosted software and apps
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
view the rest of the comments
I'd recommend an x86 board because as great as the RPI and similar can be, ARM just doesn't have the same support for a lot of things you might want to self host. I personally like to spring for a used thinclient PC off of eBay, because they have about the same resources as a Raspberry Pi but on an x86 platform. With my thin clients I typically install Alpine but a really light Debian install could work as well, and then from there you can go about installing Docker etc for a little homelab. Even better, if you get lucky and get a couple of them you could mess around with clustering them and some light Kubernetes at home. I've got mine running PiHole and Unbound on Alpine to serve my whole house with DNS and it works great. I don't think I've had hardly any downtime issues or anything of that sort.
TL;DR: try a couple cheap thin clients from eBay and you can run some light stuff on them for cheap.
Like what? Person explicitly mentioned opensource software.
Usualy thay are cheap used, so it might work too
ARM software support is just generally rough, yeah it's good on RPi (and Mac) but on other boards it typically sucks, namely the cheaper boards OP would be buying. Here's a couple software examples though, I'm a big docker user and just the other day I was trying to run I believe Mastodon and Lemmy on an ARM device but there was just no image for it. I'm sure I could build an image myself but for someone just getting into Homelabbing (like OP), x86 is the platform to use.
Let's see... Not counting Rock64 which is popular and AARCH, I also have chinese noname Espada E-726 TV Box on Allwinner A10, that(box) nobody knew about. Built bootloader, built kernel, installed system on SD card, it works.
It is easier to not use Docker.
There is actually lots of OSS that does not support arm. As a popular example documentserver for nextcloud.
If it can be compiled from sources, it works
SIGILL
This means you did not compile for correct architecture. There also can happen with program that use hand-written assembly, but I reeeeally doubt nextcloud devs do it.
For simplicity just compile with -mcpu=native on target computer.
EDIT: wait a sec, who are you? I doubt you want documentserver too.
Nonaligned memory access can occur in C code. I'm not speaking about nextcloud, you mentioned "if you can compile it works (for any architecture) ", which is demonstrably false.
Entire Cortex A-series should work fine with unaligned memory access to RAM when MMU is enabled(which is always on for linux). With few exceptions, but nextcloud is not a device driver.
I never said that.
It was implied in the discussion: "if you can compile it, it will work".
There's plenty of ARM processors before Cortex. There's SPARC. And there's a crapton of others with their quirks.
Just because you can compile a program from source, it doesn't guarantee it will work. As mentioned: online assembly, memory alignment, but you can add endianness or questionable pointer arithmetic, not to mention dynamic runtime code generation. And I'm sure there's 5 other reasons that I haven't personally run into.
Yeah, in a perfect world everyone would write bug-free, platform-independent code, alas...
Nope. If you can compile for this microarchitecture, it will work on it. You know what was implied, I know what was implied, but you choose to run in circles and yell "Look! This person doesn't know that program compiled for one architecture can't run on another!"
Me: says about -mcpu=native
You: oh, yeah, there is completely another architecture.
Ooorr...
Did you just said that SPARC is ARM processor? Who tf are you?
What now?
. . .
What distro runs ARM in big endian? Name one. I think you are just trying to throw as much arguments you don't understand as possible. EOF.
I assume you program in Javascript and haven't written C code ever. SPARC doesn't allow unaligned memory access to this day, no matter what parameters you throw to the compiler. If a program doesn't process endianness won't work correctly. s/online/inline/g. You didn't even address 4 other arguments.
"if you can compile it, it will work" is just false.
Show me your github profile
My github profile is under my real name, so no thanks. Won't be giving my social security or credit card numbers either.
I'm seconding this. The Pi-supply-dry is getting better, but for similar money to a Pi4 you can get an ex-corporate 1L mini PC (I like the HP G1 800's in a nice case, with engineered cooling, real storage, and easy memory upgrades.
Have you measure the power consumption? How is it?
According to the readout on my UPS, about 10W idle