Getting a license is your first step if you want to transmit. If you are in the US, the ARRL produces the training material for the various tests. There are free apps that go over the test questions but I like having a little more context to the answers.
With your background you'd probably need to devote time mostly to learning the rules and regulations. You can take all 3 tests in one sitting for a $15 fee and be done with it. Each test gets you more privileges (power, frequencies).
Even without a license you can receive with a cheap SDR and home brew antenna. This blog has many examples of that: https://www.rtl-sdr.com/
Finally, you may want to find a local club. Usually visiting during a "contest" will enable you to get on the air. In the US you don't need a license to use the radio if you are with a properly licensed operator.
I would love to have an advanced file system that works on portable drives across multiple OSes.
ZFS is not designed for this use case, but at least it is something. Having compression, encryption, integrity checking, and data duplication on a potentially flaky external drive would be killer features.
I use alot (to view and send mail) + notmuch (to index) + mbsync/isync (to retrieve mail). It was painful to configure, mostly due to needing scripts for syncing up tags with IMAP folders.
So far its been worth it. Instantaneous search of all my email ever. With a properly configured mailcap file HTML emails are rendered ok (still have problems with links) and attachments open in external programs as well.
Since `alot` is written in Python and can be extended with Python hooks for almost any event it has been easier for me to customize than emacs.
While I look forward to a faster desktop and mobile browsing experience with HTTP/2 I do worry about the complexity. I hope that the simpler protocols remain supported for a long time to enable implementations on low resource embedded systems.
The last thing we need is for all the closed-source, internet-connected, black boxes in our lives to poorly implement a complicated web standard protocol. There are so many places where we have already seen vulnerabilities with implementations of simple web severs and clients.
Unrelated but this article is a diamond in the rough for hams. I have to applaud the fairly concise writing style and actual use of math.
I've recently gotten in to amateur radio and it has been exhausting reading the wordy and anecdotal treaties of many "expert" hams on various topics. Not only are the works filled with jargon, but most posts start out with a tenuous link to actual science/technology and then immediately dive into very specific anecdotal experience.
I'm interested in finding better sources of info so if you or your club have good technical pieces on the web please let me know.
Unfortunately not all of us have alternative ISP's to switch to. I hear upgrading to a business account can help with certain providers but that's not always available at all locations.
I understand your criticism but the Columbia Accident Investigation Board released a full report with recommendations for changes 6 months after that accident. Not too shabby.
Right now we have a press release that is pretty thin on details from SpaceX. Not quite comparable.
HD Radio really grinds my gears. They hijacked the HD acronym for marketing: it stands for Hybrid Digital. As you mention the quality is not comparable when you have a strong analog FM signal.
On top of that the encoding is proprietary and one company holds the IP for the codecs. I can't believe the FCC allowed it to become a "standard".
Instead of hacking think of it from the other side: If no computer connected to the Internet has a reasonable expectation of privacy then law enforcement must develop a system to manage all of their data and IT needs that is not connected to the Internet.
Good luck getting that budget passed.
While the the slippery slope is not a valid argument it is always interesting to think about how precedent like this could spiral out of control.
The Planet Money podcast #677 (The Experiment Experiment) discussed an effort to reproduce some experiments.
One of the methods they discussed to both increase reproducibility and reduce experimenter bias was to register the experiment procedure and hypothesis with the journal before performing the experiment. It's been a while since I listened but I think one or more journals is supporting this workflow.
I'm glad we are working towards a better scientific process. These days sensationalism scores more grant money and Scientific American articles. We need incentives to improve our body of knowledge not just make headlines.
You can get better performance using the proprietary driver because you get access to all the device parameters. Depending on your application this can be critical.
While I don't like that FTDI is pushing their brick-making drivers out over automatic updates, I think the folks calling for everyone to ditch their chips are a little over the top.
Personally, I would love to have a reliable way to detect counterfeit chips. For FTDI I do! Now it is trivial to lot test my chips: Just put one (or a few depending on your level of quality) on a test jig and use the latest driver with it.
Contrast that with one of these other generic pieces of silicon. Is the argument that since the drivers are generic it doesn't matter if counterfeits make it into your products? Of course it still matters! Every single datasheet value that you used in your design is now out the window.
FTDI should absolutely be more forthcoming with their counterfeit detection process. It is going to be a tough call next time I need a USB-Serial chip. FTDI has a great product and documentation, but a future update might break my device if it used counterfeit components that were so far undetected.
3-6 months is not that bad. Especially if it means you can guarantee that you get genuine parts. Most real projects can easily handle this lead time for production.
[1] https://www.mathworks.com/solutions/fpga-asic-soc-developmen...
[2] https://www.intel.com/content/www/us/en/software/programmabl...