We grew, picked, washed, *sliced*, triaged, and dried 2.438 kg of Blondköpfchen tomatoes (about 770 tomatoes). That dehydrated down to just 300g. Turned out to be a bit over a quart in volume. It required a significant amount of work, equipment, and skills, but they are SO GOOD. They'll last at least a year in storage (if you can stop people from eating them for that long). Not for sale. There's a reason nobody sells dehydrated cherry tomatoes, let alone Blondköpfchen. Too much work. Only the wealthiest people would be able to afford them. #garden

It's sad to see open source project shipping closed source binaries. 🤮 It goes against best practices because it prioritizes the attackers over the users. Attackers will reverse engineer an executable and bindiff it to find the patch, and possibly find code paths that the initial patch missed. The users will be left in the dark about what was wrong, what was fixed, and whether the patch really fully addresses the issue or not. With the exception of the full-disclosure crowd, the infosec industry agrees that it's best to keep the details under embargo until the patch is written and tested, then release the patch (binary and source) along with all of the details. The industry has been facing this problem since at least the 90s. It's extremely well understood and we have decades of evidence that led us to this conclusion. Some exceptionally critical software projects post a notice saying that a security update will be released at a given date and time (in UTC) along with how severe the vulns are that are being patched. OpenSSH does this. This allows users to be ready for when the patch drops. The outliers in the industry advocate for full disclosure before a patch is available, sometimes including an exploit to demonstate the issue is real and to allow people to test their mitigations and patches. Linux does this. Opinions vary about whether it's appropriate to publish an exploit at the same time as the patch (or at all). Opinions also vary about how long developers should get to fix the issues before the person who found the issue tells the users directly. It used to be 90 days and then the details drop whether there's a patch or not. There's been a push for shorten this to 30 days. If you are a developer in any open source projects, please do security disclosures properly. If you don't believe me saying this is how its done, just look at how the open source projects who power the majority of the internet handles these things. By hiding the details from the very users you're supposed to be serving, you're putting your project's reputation on the line. Vulnerabilities happen, nobody should fault you for that (unless they're happening non-stop...), but we will fault you for how you handle it after you find out about them. View quoted note →

Just had a drive fail which held the root partition on a hypervisor that was hosting at least a dozen production VMs. No downtime. No emergency. I plan for the long term, which assumes that this will inevitably happen. That's why it's in a mirrored ZFS pool. All VMs have been migrated and I can shut the machine down and replace the drive at my leisure. Once the drive has been replaced, it goes into the pool and we're redundant again.

I'm back on this project again. Now I have a file server on there with open registration that works offline (no email verification required). I have a few settings to automate instead of setting them up manually, but it already works. What else would people want if the internet went away? We have: - LLM access over meshtastic (blackbox) - weather conditions over meshtastic (blackbox) - file server over wifi (nextcloud) I don't think I have enough space to host a copy of wikipedia on this box. - Matrix server for decentralized secure comms (beyond just Meshtastic)? - plus a local matrix to meshtastic bridge? - gitlab for wikis, project tracking & code storage? - a basic website to point people to these various resources? View quoted note →

Do you know a good conac recipe that isn't a sidecar? Rules: 1. Don't suggest something you've never tried 2. If I wanted an answer from an LLM, I'd have asked one.

Indon't know who needs to hear this, but @beejay's keto mac 'n' cheese recipe is amazing. In our household we have 5 ratings: ⭐⭐⭐⭐⭐ I've died & gone to heaven ⭐⭐⭐⭐ I want some more ⭐⭐⭐ A good, solid meal ⭐⭐ I'll eat it so it doesn't go bad ⭐ I'd rather throw it out This gets 5 stars, without question.

Since I can list two products on TakeMySats, I listed a second product.

USB to PS/2 adapter for keyboards - Open Source Gadgets

This is an open source adapter which allows using a USB keyboard (and mouse) with a computer that has a PS/2 port. It is shipped in a ready-to-use ...

It lets you plug a USB keyboard into your computer's PS/2 port. This one will probably only be of interest to Qubes users, and probably only a small subset of them at that. It allows you to not allow USB keyboards to access dom0. This prevents a malicious USB device from acting as a keyboard and taking over your computer. If you have a PS/2 keyboard, you can take advantage of this feature without any adapters, but for the 99% of us who use USB keyboards, this has you covered. I use one myself, every single day. As always, it's open source hardware and firmware. You can absolutely build your own instead of buying one from me. You can fork the project and change the design. You can do whatever you want. #freedom Shout out to @The Bullish ₿itcoiner for making this marketplace.

What should I read next? The bitcoin standard Bitcoin is for everyone or The price of tomorrow

I heard a ticking today. I almost decided that it wasn't important enough to interrupt my work to track down. Sure glad I didn't go that route. When I investigated further, it was dripping water from the basement ceiling. When I investigated further yet, half the machine shop in the next room over was flooded from this water dripping. Got the water shut off so it's not getting any worse, but we still haven't found the break in the line. Dry everywhere up top, but water somehow dripping from the plywood above the floor joists. Still working on it It's just turning out to be one of those days...

Idea for @ZEUS: Run a nostr poll on what functionality people want to see improved (reliability, error messages, etc) or what features people want (ability to be paid while offline, bolt15 or whatever, etc.). People who have been enjoying your app for a while can use this as an opportunity to donate and help guide development efforts at the same time. #v4v

OK, at the risk of stirring up a hornet's nest, I'm going to #AskNostr to help me understand why people think an army of script kiddies is a security threat to any decent open source project. I get why they'd be a threat to something that was hacked together in a hurry, and doubly so if it's unnecessarially complex (design, dependencies, etc.). That makes perfect sense. I don't consider the above to meet my definition of a "decent open source project". If you're fixing security holes every day for months on end, your code is not very good. Sorry, not sorry. You need to ask why you didn't catch these things earlier. And if the answer is that it's all upstream bugs, you need to ask yourself why you have those dependencies. Whether the attackers use AI or not doesn't seem like it should change the equation. If doesn't matter how advanced your AI is, it's a question of attack surface and code quality. I do understand why the developers could be overrun by a ton of meritless bug reports generated by AI. That's a very real operational problem, but that's not a security theat. My take is this: script kiddies and AI tools help reveal the difference between projects that have good code, and ones that don't. Previously, we could look at the number of dependencies and complexity of a project and get a feel for whther it's held together with bailing wire and duct tape. Now, if AI can write a functional exploit, we can also get evidence of what we suspected. I think this is a good thing. Change my mind.

If you do any engineering, this is a handy reference

The Engineering ToolBox

Free tools and information for engineering and design of technical applications.

I'm in the market for a replacement for BTCPay. I want a web interface to accept donations on-chain with a unique address each time, accept LN donations, and ideally be able to take payments for an e-commerce platforms like CS-Cart. If it could also just BE the store, and that'd be fine. Self hostable, without reliance on 3rd party servers (e.g. nostr relays) and without having to run extra services (e.g. a public nostr relay). Simple and open source. That's what I'm after. This is not because BTCPay had a vulnerability, but because of their handling of it. They intentionally omitted that vulnerability fix from their release notes, making it look like the 2FA fix was the "critical vulnerability" fix. The people who admin servers need to be able to trust the release notes to be an honest account of what has changed. We're not going to look at every line of code that has changed. We don't have time for that. You know who does have time for that? The attackers. Had the authors just put a single line in the release notes that said "unauthenticated attacker can get the .macaroon file for LND", I would feel like I could still trust them. Doing so would not have made it any easier for the attackers, they'd still have to read the patch, just the same as they had to do without proper disclosure. I've worked in infosec for 15+ years, most of that time finding 0-days. We can debate about whether the details and exploit should be released before the patch, at the same time, 30 days later or 90 days later. Reasonable people can draw different conclusions there, even when looking at the same information. What's not debatable is whether it's good practice to do what they did. Don't take my word for it. Ask anyone who works in the field professionally. Is it okay to say there was a critical vulnerability fixed in a release and then only list one vulnerability fix in the changelog and omit another, mire serious vulnerability that was fixed?

I don't even understand what any the bitcoiners are saying anymore. It's a bunch of name-calling and references that I don't understand. But I'm okay with that. It doesn't seem like it's worth pouring my time and energy to understand why people are calling each other names. If this is the best use of their time, I say: you do you, boo.

@ZEUS came through for me again in the real world. Paid in 5 seconds, but more importantly, it worked the first time. 🤙 Before anyone asks, no, I don't use Olympus.

To those who advocated for Coldcard: 1. Don't beat yourself up too much 2. Disclose if you're being paid for the things you recommend (if you didn't already) 3. Disclose whether you've personally analyzed/audited the product and if not, where the basis for your recomendation comes from 4. If you're not being paid to advertise their product, consider advocating for community projects. Things that are open source hardware, where the community can actually modify the design. Bonus points if there are multiple groups building the hardware. None of this guarantees you won't ever regret something you recommend, but it provides more transparency and gets you to think about the incentives for building these things and whether they are monetary or not.

I feel for these folks who bought coldcards. Trust in that company has been completely shattered. People expected that buying a closed source hardware product would be run by people who would invest in audits of their firmware and the libraries on which they depend. That's a reasonable expectation, even if it is based on trust instead of verification. On the flip side, there's open hardware projects like seedsigner and trezor, where it's well known that they're not raking in the money needed to fund a serious audit. Because they are expensive. There aren't a lot of people who can say "yeah, the code looks good" and have that be taken as evidence that the code is vulnerability-free. Their time is valuable. There aren't any magic answers here. Sure, it's easy for armchair analysts with the benefit of hindsight to say now what people could have done differently. It's a different thing entirely to put in the work to change the game.