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.
No low-effort posts. This is subjective and will largely be determined by the community member reports.
Resources:
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
Linux was born out of manually making drivers to see how hardware works, which after putting enough together, Linus noticed he had a kernel.
Meanwhile, people pushing code they don't understand are more often than not breaking the programs they "help" with.
I'd suggest studying low level coding to at least be able to audit others' codes, including LLMs', let alone to publish comnputer-generated codes.
I've even seen people vibe code ethernet drivers for freeBSD.
Please make sure to read what considerations that developer had before undertaking that effort using an LLM: https://github.com/Aquantia/aqtion-freebsd/issues/32#issuecomment-3997341698
Specifically, they (the human) were kept in the loop for the entire process, which included referencing the working Linux driver to do a clean-room reimplementation. This already means they have some experience with software engineering to spot any issues in the specifications that the LLM might generate.
Also, Aquantia (before the merger) already had a published FreeBSD driver but it hasn't been updated. So this port wouldn't have to start from zero, but would be a matter of addition support for new NICs that have been released since, but Aquatia hadn't updated the driver.
This is very much not an example of an Ethernet NIC driver being "vibe coded" from scratch, but a seasoned engineer porting Linux support over to FreeBSD, a kernel that already has a lot of support for easily adding new drivers in a fairly safe manner, and then undertaking a test plan to make sure the changes wouldn't be abject slop. That's someone using their tools with reasonable care. In the industry, this is called engineering.
Admiration for what people can do with the right tools must always be put into the right context. Even with the finest tools, it's likely that neither you nor I could build a cathedral.
I used a very similar method in a similar situation to albb0920. They describe it as vibe coding too.
The exact chip that handles everything is undocumented, but similar ones in the same series have datasheets. A maintained version of the linux driver handily collated all of the available datasheets and configurations used by different motherboards. Between that and my microcontroller/hardware experience, that side of things wasn't too bad.
What I didn't know anything about was writing an Illumos driver. I used the chatbot with a free claude account, compiling and running the code manually myself. I was impressed that it was able to build out the boilerplate and get something going at all. Course it took a few tried to get something that compiled and worked somewhat correctly. At some points I needed to look through the generated code and point out exactly what what wrong, but at least it would address it.
Code running in the context of the kernel is definitely not something I would have autonomously executing by a LLM. The end result is absolutely not something I would want put into the official Illumos source.
spits on ground, squints reeeeaaal slow
Now listen here sonny.. we don't take kindly to none of that AI business around these parts.
We is simple, God fearin' folk, raised on sweat, dirt, and good honest labor, not all of that fancy machine learnin' contraption nonsense.
Ain't no place for thinkin' machines where a man’s meant to use his own two hands. So I reckon I'll mosey on over and downvote this here post myself, nice and proper.
🤣
Personally it's what I use them for the most. I do not have the time to reverse engineer arbitrary things like this. I have a scooter that uses Bluetooth BLE which has no connectivity beyond that. I've been using Claude to help reverse engineer the protocol to hopefully get a home assistant integration up and running.
Claude can see things I can't, patterns in hex that are coming back, I send in results from wireshark and it can try ad neaseum to try and get something working. Right now it's about half working. When I have time I'll keep plugging away. Then hopefully other people will be able to use it, and we can have one less vendor locked in device
That's awesome! Can you describe your set up for vibe coding this? I'd like to take a look at porting postmarketOS linux, or ubports to some phones I have laying around.
First I asked it how to create a dump file. I hooked up ADB debugging to my phone, then used the scooter's app as normal, with the logging turned on in Android developer tools. It created a very long and complex dump file of hex that I could not understand.
However, then I had Claude get to work. I describe that in that I had opened the scooter's app, and turned it on, paused a few seconds, then turned it off and closed the app. It started attempting to mimic the commands through the computer's local bluetooth device, to get a successful response. Eventually, after something like 20 attempts it found a hidden clue that was basically a pattern that it had detected, and it was able to finally get an ACK from the scooter. Something I would have never been able to do. From there we have a plan on how to map out all of the other commands, but it was a huge win for the day.
Pretty cool so long those fans don't go berserk. Faster troubleshooting if it's tested well. I remember setting up fan curves on bios at one point and it was annoying enough. Also I don't think you can stress test there so if your use case needs that then sure.
I've always geeked out about fan curves and monitoring, though I readily admit for most PCs leaving the default BIOS curve works fine enough.
That's awesome! Can you describe your set up for vibe coding this? I'd like to take a look at porting postmarketOS linux, or ubports to some phones I have laying around.
I just used the free chat with Claude, it created and tracked the files in its own webchat thingy. Being a kernel module, I was happy to manually check, copy/paste, compile, then run the code for each iteration.
Porting postmarketOS to a phone sounds like it may require some amount of manual running and explaining results back to the chat. Ultimately the output only starts to get functional when it hits reality and needs to keep adapting to feedback.
I wrote a blog on the process that more focuses on the journey and technical details of the controller chip.
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I've seen in this thread:
| Fewer Letters | More Letters |
|---|---|
| FTS | Flight Termination System |
| LOX | Liquid Oxygen |
| SECO | Second-stage Engine Cut-Off |
| SES | Formerly Société Européenne des Satellites, comsat operator |
| ~ | Second-stage Engine Start |
| USSF | United States Space Force |
5 acronyms in this thread; the most compressed thread commented on today has 16 acronyms.
[Thread #177 for this comm, first seen 17th Mar 2026, 06:40] [FAQ] [Full list] [Contact] [Source code]
Go home, bot. You're drunk.