https://it-notes.dragas.net/2025/11/19/static-web-hosting-intel-n150-freebsd-smartos-netbsd-openbsd-linux/
#ITNotes #NoteHUB #freebsd #illumos #jail #linux #netbsd #openbsd #ownyourdata #server #smartos #sysadmin #zoneshosting
#Tag
Static Web Hosting on the Intel N150: FreeBSD, SmartOS, NetBSD, OpenBSD and Linux Compared
My own made smart thermostat is currently working fine.
My neighbours' isn't.
My old one was impacted by the recent Azure outage.
https://itsfoss.com/self-hosting-starting-projects/
5 simple(~ish) tools to start your home-lab or home-server with
- Jellyfin: Your own Netflix
- Kavita: Your own Kindle library
- Nextcloud: Your own Google drive (and more)
- Immich: Your own Google Photos
- Navidrome: Your own Spotify
#SelfHosting #Homelab #OpenSource #Linux #DIYTech #TechStack #ServerSetup #PrivacyFirst #DigitalFreedom #DataProtection #SecureYourData #EncryptEverything #FOSS #DataSovereignty #OwnYourData #InternetFreedom #TechIndependence
https://itsfoss.com/self-hosting-starting-projects/
5 simple(~ish) tools to start your home-lab or home-server with
- Jellyfin: Your own Netflix
- Kavita: Your own Kindle library
- Nextcloud: Your own Google drive (and more)
- Immich: Your own Google Photos
- Navidrome: Your own Spotify
#SelfHosting #Homelab #OpenSource #Linux #DIYTech #TechStack #ServerSetup #PrivacyFirst #DigitalFreedom #DataProtection #SecureYourData #EncryptEverything #FOSS #DataSovereignty #OwnYourData #InternetFreedom #TechIndependence
Self-hosting your Mastodon media with SeaweedFS
https://it-notes.dragas.net/2025/11/06/self-hosting-your-mastodon-media-with-seaweedfs/
#FreeBSD #SeaweedFS #Mastodon #ITNotes #Fediverse #Hosting #OwnYourData #RunBSD
Self-hosting your Mastodon media with SeaweedFS
Self-hosting your Mastodon media with SeaweedFS
Self-hosting your Mastodon media with SeaweedFS
https://it-notes.dragas.net/2025/11/06/self-hosting-your-mastodon-media-with-seaweedfs/
#FreeBSD #SeaweedFS #Mastodon #ITNotes #Fediverse #Hosting #OwnYourData #RunBSD
Self-hosting your Mastodon media with SeaweedFS
Self-hosting your Mastodon media with SeaweedFS
Self-hosting your Mastodon media with SeaweedFS
My grandpa's drill (made in West Germany in the 60ies, still doing great) and some manual work and I've reinstalled it.
And it's working!
@stefano if you don't already have something in mind, this might make a very interesting conference talk. We've already had a FreeBSD Fridge. I think a privacy first NetBSD thermostat would be well received.
Here is a link to the FreeBSD Fridge from 2024 BSDCan. It is available on the SDF Peertube instance Toobnix.org:
@bsdtv this could be a nice idea - I think people could be quite interested, and it's another step towards the #OwnYourData
Here's a short video about my cloudless, portable, small, low-resource "smart thermostat". It doesn't need an internet connection and uses MQTT. Here, it's directly driving a relay.
It's running on a Raspberry Pi Zero W, powered by NetBSD, in read-only mode.
I used it for years and it's time to go back to it, cloudless and local.
#RunBSD #NetBSD #IoT #OwnYourDevices #OwnYourData #Cloudless
Hello, old friend!
Maybe you deserve a software upgrade, but you still rock!
Yesterday evening I couldn't use my Netatmo thermal control. I was blaming the changes I was performing in the home network but it seems it was a global #Azure outage.
I think it's time to revamp my old, pre 2010 python program that served me well for years.
About a year ago, a client I've worked with for over fifteen years informed me that some of their "less critical" servers would be migrated to $CLOUDPROVIDER. According to them, this provider would guarantee an efficient management panel, "more freedom for their devs", and lower costs. This didn't impact me financially but, on an ethical and personal level, I warned him about the potential problems. Yet they decided to move forward, aided by the arrival of $YOUNGDEV who "has worked with it, it's reliable, and everything works fine". Again, I warned them (where are the backups? A disaster recovery plan? etc.) but they insisted: $CLOUDPROVIDER is efficient and gives us everything.
I studied their plan and immediately understood that their "cost-cutting" strategy wouldn't work: I know their workloads, and the plan they chose was insufficient. Needless to say, a few days later they went down and had to make an "emergency" purchase of the next tier up. The cost? Higher than their previous server infrastructure.
I heard nothing more about these workloads for almost a year but my monitoring tools still were marking them down, from time to time. Then, I get a phone call this afternoon. $YOUNGDEV asks me for support. He doesn't explain, but I immediately understand it's one of those workloads. A serious problem, and they don't have a backup of the database. They don't have a test environment to run diagnostics. The DB is very large, and they don't know what to do. My predictions - not even my worst ones - had come true.
I was running between two appointments. I only remarked that this situation could have been avoided and that it's not something I manage or can manage, but I nonetheless suggested we sync up tomorrow morning. I'm not going to get my hands dirty, but still, $YOUNGDEV is in trouble, and I offered to take a look to suggest a strategy. I then asked for the access credentials to $CLOUDPROVIDER, considering that up until a year ago, I managed all of these workloads. He replied that he "doesn't know if he can give them to me" and that he "would have to ask his bosses". I pointed out that if he wants my help, I need something - I don't even know how $CLOUDPROVIDER grants access to data (or if it does) - how can I give him advice?
It's 18:30 and I have received nothing. Tomorrow morning, if the phone rings, I will answer, but at this point, I won't do anything. I prefer, albeit reluctantly, to completely end the relationship with this client.
If this is the price of dignity and respect, I'll gladly pay it.
About a year ago, a client I've worked with for over fifteen years informed me that some of their "less critical" servers would be migrated to $CLOUDPROVIDER. According to them, this provider would guarantee an efficient management panel, "more freedom for their devs", and lower costs. This didn't impact me financially but, on an ethical and personal level, I warned him about the potential problems. Yet they decided to move forward, aided by the arrival of $YOUNGDEV who "has worked with it, it's reliable, and everything works fine". Again, I warned them (where are the backups? A disaster recovery plan? etc.) but they insisted: $CLOUDPROVIDER is efficient and gives us everything.
I studied their plan and immediately understood that their "cost-cutting" strategy wouldn't work: I know their workloads, and the plan they chose was insufficient. Needless to say, a few days later they went down and had to make an "emergency" purchase of the next tier up. The cost? Higher than their previous server infrastructure.
I heard nothing more about these workloads for almost a year but my monitoring tools still were marking them down, from time to time. Then, I get a phone call this afternoon. $YOUNGDEV asks me for support. He doesn't explain, but I immediately understand it's one of those workloads. A serious problem, and they don't have a backup of the database. They don't have a test environment to run diagnostics. The DB is very large, and they don't know what to do. My predictions - not even my worst ones - had come true.
I was running between two appointments. I only remarked that this situation could have been avoided and that it's not something I manage or can manage, but I nonetheless suggested we sync up tomorrow morning. I'm not going to get my hands dirty, but still, $YOUNGDEV is in trouble, and I offered to take a look to suggest a strategy. I then asked for the access credentials to $CLOUDPROVIDER, considering that up until a year ago, I managed all of these workloads. He replied that he "doesn't know if he can give them to me" and that he "would have to ask his bosses". I pointed out that if he wants my help, I need something - I don't even know how $CLOUDPROVIDER grants access to data (or if it does) - how can I give him advice?
It's 18:30 and I have received nothing. Tomorrow morning, if the phone rings, I will answer, but at this point, I won't do anything. I prefer, albeit reluctantly, to completely end the relationship with this client.
If this is the price of dignity and respect, I'll gladly pay it.
This morning it looks like two of my connectivity providers had serious issues across almost all of Italy. I didn't notice anything and thought the problem was in other areas.
I was wrong: the problem was related to their DNS, which was down or malfunctioning.
This is why I didn't notice: I use my own DNS resolvers, and they perform resolutions directly, without a forwarder.
Once again and for the second time this week, Own Your Data and decentralization guaranteed continuity.
I will never stop saying it: Own Your Data!
A space for Bonfire maintainers and contributors to communicate