#Tag
@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!
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!
This morning, this is extremely appropriate (even if I yell at cloud when it's working, too)
#AWS #AWSDown #AWSOutage #IT #SysAdmin #OwnYourData #Decentralize
While I don't think this is good news, it's still something I was expecting.
And - who knows - maybe they'll finally support ipv6
The Email They Shouldn't Have Read
https://it-notes.dragas.net/2025/10/08/the-email-they-shouldnt-have-read/
This morning I took a look at the spam I received overnight. Excluding what my system rejected (so, messages that never reached my inbox), 87% came from MSFT or Google - straight from the mail servers of those two companies.
Yet many people choose these big providers - now near monopolies - because they "actively fight spam".
Or maybe fighting spam is just the perfect excuse to crush the decentralization of email?
This morning I took a look at the spam I received overnight. Excluding what my system rejected (so, messages that never reached my inbox), 87% came from MSFT or Google - straight from the mail servers of those two companies.
Yet many people choose these big providers - now near monopolies - because they "actively fight spam".
Or maybe fighting spam is just the perfect excuse to crush the decentralization of email?
Another small victory today.
A salesperson had almost convinced a client to move their email from 365 to Google because "they hold all the cards now". I stepped in and suggested they keep their email on servers that they control instead. The salesperson almost mocked me, treating me like a "nerd" who doesn't understand how the world works.
I was happy to be a nerd, if necessary, to explain the pros and cons of the solution to the client.
The result? The salesperson was politely thanked and "sent home", and I'm now evaluating some details of the new mail server, which, by the client's choice, will be based on OpenBSD.
Because people need explanations, not brochures.
Personally I would have gone with #Mailcow. Much easier to setup and administer. As much as I love #FreeBSD and #OpenBSD I sure as hell wouldn't recommend it for an SME.
Unless your goal is lock-in. Vendor lock-in. And in this case that vendor is you. Because let's face it, even in IT, OpenBSD is quite niche and FreeBSD is already niche enough.
Another small victory today.
A salesperson had almost convinced a client to move their email from 365 to Google because "they hold all the cards now". I stepped in and suggested they keep their email on servers that they control instead. The salesperson almost mocked me, treating me like a "nerd" who doesn't understand how the world works.
I was happy to be a nerd, if necessary, to explain the pros and cons of the solution to the client.
The result? The salesperson was politely thanked and "sent home", and I'm now evaluating some details of the new mail server, which, by the client's choice, will be based on OpenBSD.
Because people need explanations, not brochures.
Another small victory today.
A salesperson had almost convinced a client to move their email from 365 to Google because "they hold all the cards now". I stepped in and suggested they keep their email on servers that they control instead. The salesperson almost mocked me, treating me like a "nerd" who doesn't understand how the world works.
I was happy to be a nerd, if necessary, to explain the pros and cons of the solution to the client.
The result? The salesperson was politely thanked and "sent home", and I'm now evaluating some details of the new mail server, which, by the client's choice, will be based on OpenBSD.
Because people need explanations, not brochures.
A space for Bonfire maintainers and contributors to communicate
