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.
Same here. I ended up writing a wrapper for alot (and a custom MDA): https://github.com/jakeogh/gpgmda (just split the client stuff into gpgmda-client, see the client side deps list)
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.
The "simple" text based protocols are NOT simple to implement correctly. Go try out line-wrapping and play with using \r\n vs \r vs \n as line endings and tell me what the compatibility ends up like.
And this does create real-world security problems. Some VoIP companies allow you to make free calls by screwing with their SIP proxies because popular software handles line endings differently allowing you to make their edge software interpret packets differently than their core.
Even parsing is easier in a nice binary format (and much, much, faster, too).
It's not got much to do with the serialization protocol itself as such - most server software uses a library which handles it properly and then doesn't have to worry about it. It's more that web developers have to get bits of their stack (the dynamic and static serving aspects) to cooperate in ways they never had to before (in fact, the general wisdom was to separate them as much as possible as they have totally different requirements when it comes to performant serving).
This is not even to get into persistent connections & server push etc., which is quite a big subject for developers used to handling independent fire-and-forget requests.
I guess I'm saying the massively complexity comes in trying to use these new features.
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.
Exactly the same here. I won't go through the [maybe] lengthy process of creating a new account to get a paywall then. Same goes with the privacy policy, I don't want to use it with my own PDFs and lose their rights or with other people's and screw things legally.
[1] https://www.mathworks.com/solutions/fpga-asic-soc-developmen...
[2] https://www.intel.com/content/www/us/en/software/programmabl...