I don't have you in my log! Southeast US here. What aspects of ham radio are you into? Any HF nets you frequent? To be honest, life keeps me away from radio most of the time so there is nothing "regular" that I participate in outside the two Field Days, but if things ever slow down I will have the license and the equipment for it. I got in due to a general interest in technology but I like contesting, the occasional net, and someday I would like to practice CW (have "learned it" twice now but have been unable to dedicate the time to practice). I like digital modes and am not anti-FT8 but I wish there was more use of the "conversational" modes like RTTY or others in fldigi.
If you are interested, find and go to an amateur radio club meeting. The licensing test makes sure you know the regulations and some theory. It does not help introduce you to "ham culture" which is definitely a thing. I learned all the practical stuff from talking with local club members. They are usually overjoyed for new members; if not just go to the next club. Youtube and whatnot helps but it's better to be able to ask someone a stupid question, and believe me, if you want to be overwhelmed with information, ask a ham a question. In my experience there are some assholes but more genuinely kind people, mostly older folks who just want to connect with someone.
This is amazing to see. I have some audio recordings, digitized from tapes recorded in the 1960s, of my great-grandfather who was raised on a farm in Iowa. He talks about his experiences in amateur radio in the early 1900s-1920s. He mentioned bringing telephones out into the field that could be clipped to the fence wire to make calls back to the house, which was not hooked up to an electric grid but had batteries. Sadly, he did not say how the batteries were re-charged.
My father in law grew up in the Denver area. His father made his living as a handyman, and one of his regular customers was Molly Brown (the Titanic survivor known as "The Unsinkable Molly Brown"). Every week he would go to her house to exchange her radio battery, then bring the old battery back to his workshop for charging.
There’s a great radio museum in Howth, Ireland, a waterfront town near Dublin. The founder was a lifelong radio enthusiast who grew up in a poor rural community and was mesmerized by the power of radio from an early age. I remember him telling me he had never heard a language other than English until radio came to town and he heard a broadcast in French. He also talked about using very basic acid batteries and having to go into town to change out the acid. I believe he said it was also a serious problem if you spilled any in the house because it would damage or dissolve anything it came in contact with.
Yes, in the old systems, you'd get about 90 volts AC down the line to ring the mechanical bell ringer. Once saw a guy nearly fall off a ladder, splicing phone lines with bare hands. He thought the relatively low voltage was safe enough, but then someone rang him in the middle of the job.
I had to refresh my memory about the hybrid use of AC and DC current in telephone networks.
The Alternating Current signals could be used over longer distances and were effective at making the bells ring, moving the clapper back and forth. This back-and-forth is exactly what makes AC so deadly in the body, should it cross through your cardiac muscles, for example, and set the muscles twitching at 50 or 60 times per second.
There’s nothing inherently deadly about AC nor anything inherently safe about DC. If there’s enough voltage available to drive current through your body, then electricity is deadly regardless of if it’s AC or DC.
In general AC tends to be a little safer than DC, because the voltage is constantly reversing, which means it’s constantly passing through 0V, creating moments where you don’t have current driving through your body and forcing all your muscles to contract. Those 0V crossings create moments where you can let go of whatever is electrocuting you. DC on the other hand has no such 0 crossings, if there’s enough voltage there to drive current through you, then all your muscles will be stuck contracting until either the power is turned off, or until they’re all so fried they’re not physically capable of contracting anymore.
The phone batteries weren't a high load kind of affair. They merely needed to change the varying resistance of the carbon microphone into an audio voltage - on the order of milliwatts of power - to send down the line. A more modern phone, still using a carbon microphone but powered by the line, needed about 20mA of loop current to do this. The telephone terms for the old system vs. the newer is "local" vs. "common" battery.
Heavy duty batteries - specifically the "A" batteries that powered the vacuum tube heaters in early radios - were made rechargeable to save cost.
This might be a bit of a tangent but I couldn't help but wonder if the appearance of 20ma here is related to the old fashioned, but I understand commonly used, 4-20ma current loop signalling in industrial applications.
It's almost never a coincidence. Before digital switching everything was done mechanically, and before mechanical switching everything was done by people with plugs. If you have a big enough industry like telephone switching equipment then you're bound to see a lot of suppliers expand their market by selling the same parts outside of their home industry. Current flow is a nice signalling mechanism because you can tell the difference between short, open, and functional circuit. So I'm guessing it got used in telephone switching equipment and then preserved because there was no reason to change.
And current through a wire stays the same on every point of the wire, more or less regardless of the length, as long as the supply can provide enough voltage to maintain it. This in turn dramatically simplifies the electronics needed to interact with it.
My grandmother from rural Saskatchewan said that back then they would exchange their radio batteries when they went to town.
Her husband, my grandfather, lived in Regina but worked on a traveling threshing crew and mentioned seeing a windmill driving an old generator from a car to charge batteries at one stop.
All of the "btrfs eats your data" bugs have been fixed and the people who constantly repeat them are people who relied on an experimental filesystem for files they cared not to lose. FUD all around. I have a btrfs on my home file server that's been running just fine for almost 10 years now and has survived the initial underlying hard drives mechanical death. Since then I have used it in plenty of production environments.
Don't do RAID 5. Just don't. That's not just a btrfs shortcoming. I lost a hardware RAID 5 due to "puncture" which would have been fascinating to learn about if it hadn't happened to a production database. It's an academically interesting concept but it is too dangerous especially with how large drives are now, if you're buying three, buy four instead. RAID 10 is much safer especially for software RAID.
Stop parroting lies about btrfs. Since it became marked stable, it has been a reliable, trustworthy, performant filesystem.
But as much as I trust it I also have backups because if you love your data, it's your own fault if you don't back it up and regularly verify the backups.
> All of the "btrfs eats your data" bugs have been fixed ... I have a btrfs on my home file server that's been running just fine for almost 10 years now and has survived the initial underlying hard drives mechanical death
In the last 10 years, btrfs:
1. Blew up three times on two unrelated systems due to internal bugs (one a desktop, one a server). Very few people were/are aware of the remount-only-once-in-degraded "FEATURE" where if a filesystem crashed, you could mount with -odegraded exactly only once, then the superblock would completely prevent mounting (error: invalid superblock). I'm not sure whether that's still the case or whether it got fixed (I hope so). By the way, these were on RAID1 arrays with 2 identical disks with metadata=dup and data=dup, so the filesystem was definitely mountable and usable. It basically killed the usecase of RAID1 for availability reasons. ZFS has allowed me to perform live data migrations while missing one or two disks across many reboots.
2. Developers merged patches to mainline, later released to stable, that completely broke discard=async (or something similar) which was a supported mount option from the manpages. My desktop SSD basically ate itself, had to restore from backups. IIRC the bug/mailing list discussions I found out later were along the lines of "nobody should be using it", so no impact.
3. Had (maybe still has - haven't checked) a bug where if you fill the whole disk, and then remove data, you can't rebalance, because the filesystem sees it has no more space available (all chunks are allocated). The trick I figured out was to shrink the filesystem to force data relocation, then re-expand it, then balance. It was ~5 years ago and I even wrote a blog post about it.
4. Quota tracking when using docker subvolumes is basically unusable due to the btrfs-cleaner "background" task (imagine VSCode + DevContainers taking 3m on a modern SSD to cleanup 1 big docker container). This is on 6.16.
5. Hit a random bug just 3 days ago on 6.16, where I was doing periodic rebalancing and removing a docker subvolume. 200+ lines of logs in dmesg, filesystem "corrupted" and remounted read-only. I was already sweating, not wanting to spend hours restoring from backups, but unexpectedly the filesystem mounted correctly after reboot. (first pleasant experience in years)
ZFS in 10y+ has basically only failed me when I had bad non-ECC RAM, period. Unfortunately I want the latest features for graphics etc on my desktop and ZFS being out of tree is a no-go. I also like to keep the same filesystem on desktop and server, so I can troubleshoot locally if required. So now I'm still on btrfs, but I was really banking on bcachefs.
Oh well, at least I won't have to wait >4 weeks for a version that I can compile with the latest stable kernel.
The only stable implementation is Synology's, the rest, even mainline stable, failed on me at least once in the last 10 years.
> Quota tracking when using docker subvolumes is basically unusable due to the btrfs-cleaner "background" task (imagine VSCode + DevContainers taking 3m on a modern SSD to cleanup 1 big docker container). This is on 6.16.
I had to disable quota tracking. It lags my whole desktop whenever that shit is running in the background. Makes it unusable on an interactive desktop.
Early bcachefs was ridiculously fast, it's gotten slower as we've grown all the features to compete with ZFS. All the database stuff that gives us amazing flexibility adds overhead (the btree iterator code has gotten fat), backpointers and modern accounting blew up our journalling overhead. A lot things that we needed for scalability, or hardening/self healing, have added overhead.
COW really isn't the main thing, it's cramming all the features in that we want these days while keeping the fastpaths fast that's the tricky part.
But, a lot of this stuff is fixable - performance just hasn't been the priority, since the actual users aren't complaining about performance and are instead clamoring for things like erasure coding.
(and, the performance numbers that I've seen comparing us to ZFS still put us _significantly faster)
Yeah, no. I've had btrfs lose a root filesystem on a laptop with only one disk. No RAID, nothing fancy, well after it was supposed to be stable, on OpenSUSE where I assumed it would be well supported and pick good defaults.
Claiming that anyone reporting problems is lying is acting in bad faith and makes your argument weaker.
I know ultraviolet CCD sensors exist and are probably expensive, specialty scientific equipment. I've kinda had this hope that one smartphone manufacturer (any of the big ones) would go to the trouble of including a UV camera and drive costs down. On the one hand you can market a unique and fun photography tool that lets you see the world in a different way. And then in the more serious part of the commercial, you show friends at the beach taking UV pictures of each other after applying sunscreen and one person says "You missed a spot right there, mate."
Plus I'd imagine you could immediately tell if your sunblock were BS and do an even better job of holding these folks accountable. You and buddy of similar skin tone both buy SPF 50 and apply it, take pictures, and see that one of you is not as well protected.
Also, cheap chinese UV camera tablets ($25) that just showed you yourself through a UV camera. This seems more likely to happen than getting Apple to add a UV camera. They already sell cheap LCD photo frames. I'm sure they can make them cheap. A few influencers and suddenly everyone would get one for checking their UV protection.
I recently started using Aider and had that thought about too many commits. What I realized though was: (1) if I'm going to contribute to a project, I should be working in a local branch and interactively rebasing to clean up my history anyway (and of course carefully reviewing Aider's work first) and (2) if I'm working on my own thing WITHOUT LLM, I tend to prefer to commit every dang little change anyway, I just don't remember to do it because I'm in the zone and then inevitably wish I had at some point.
> I tend to prefer to commit every dang little change anyway, I just don't remember to do it because I'm in the zone and then inevitably wish I had at some point.
That’s what I do too until I developed a practice to break up into thematic commits as I realize I need them. And if I don’t, then I just git reset to the beginning and use git gui to commit lines and chunks that are relevant for a given piece of work. But with experience, I barely do the break down completely - I generally don’t even bother creating commits until I have a starting sense of what the desired commit history should be.
I have seen this sentiment on HN a lot recently. Any good resources for that? I was quite the accomplished web developer 15-20 years ago and want to catch up without having to learn a new library or framework every six months.
