Tux Machines
Posted by Roy Schestowitz on Dec 30, 2022
=> Open Hardware: Adafruit, Pi, and More | Security Patches and 'Linux' FUD
=> ↺ A brief interview with Mu creator Dr. Kartik Agaram
Dr. Kartik Agaram is a professional programmer by day and the author of several open source projects that try to demystify computers. His projects all show a great love for programming and empathy for readers grappling with a strange codebase.
=> ↺ Golang is evil on shitty networks - Somewhere Within Boredom
This adventure starts with git-lfs. It was a normal day and I added a 500 MB binary asset to my server templates. When I went to push it, I found it interesting that git-lfs was uploading at 50KB per second. Being that I had a bit of free time that I’d much rather be spending on something else than waiting FOREVER to upload a file, I decided to head upstairs and plug into the ethernet. I watched it instantly jump up to 2.5 MB per second. Still not very fast, but I was now intensely curious.
Since I figured I would have originally been waiting FOREVER for this to upload, I decided to use that time and investigate what was going on. While I would expect wired ethernet to be a bit faster than wifi, I didn’t expect it to be orders (with an s) of magnitude faster. Just to check my sanity, I ran a speed test and saw my upload speed on wifi at 40MB per second, and wired at 60MB per second.
After some investigations with WireShark and other tools, I learned that my wifi channels have a shitload of interference in the 2Ghz band, and just a little in the 5Ghz band. During this time, I also learned that my router wouldn’t accept a single 5Ghz client due to a misconfiguration on my part. So, non-sequitur, apparently enabling “Target Wake Time” was very important (I have no idea what that does). Once that was fixed, I saw 600MB per second on my internal network and outside throughput was about the same as wired.
=> ↺ The Bitter Truth: Python 3.11, Cython, C++ Performance | Agents and Robots
This article compares various approaches to speed up Python. However, it should be clear in advance that C++ is still faster than Python. The question is by how much? The article is tailored for Data Scientists and persons with domain knowledge and Python experience that are interested in results gained from a simulation. The article demonstrates the current state of Python's performance using one example only. It is not a rigorous comparison. It shows what tools are available, how to measure performance gains, and what best practices are.
When I was in college in the early 1990s, we were still in the depths of the AI Winter, and AI as a field was likewise dominated by classical algorithms. My first research job at Cornell University was working with Dan Huttenlocher, a leader in the field of computer vision (and now Dean of the MIT Schwarzman College of Computing). In Huttenlocher's Ph.D.-level computer vision course in 1995 or so, we never once discussed anything resembling deep learning or neural networks—it was all classical algorithms like Canny edge detection, optical flow, and Hausdorff distances. Deep learning was in its infancy, not yet considered mainstream AI, let alone mainstream CS.
Of course, this was 30 years ago, and a lot has changed since then, but one thing that has not really changed is that CS is taught as a discipline with data structures, algorithms, and programming at its core. I am going to be amazed if in 30 years, or even 10 years, we are still approaching CS in this way. Indeed, I think CS as a field is in for a pretty major upheaval few of us are really prepared for.
=> ↺ Another Year of #TidyTuesday | Nicola Rennie
Last year, I wrote a blog post discussing of how I found participating in #TidyTuesday every week for a year. Well, this year I did the same again. And so I’m writing another blog post about it! If you’re unfamiliar with #TidyTuesday, it’s a weekly data challenge aimed at the R community. Every week a new data set is posted alongside a chart or article related to that data set, and ask participants explore the data.
=> ↺ SemVer but with Extra Steps | Toby Inkster [blogs.perl.org]
This is a variant of SemVer which mostly meets all its rules, except for releases prior to 0.2.0, where we bend them slightly.
It is my intention to use this versioning system for all open source software I develop from 1 January 2023 onwards. Existing open source projects I manage will adopt this scheme from their next release onwards. (Type::Tiny already somewhat does.)
=> gemini.tuxmachines.org This content has been proxied by September (ba2dc).Proxy Information
text/gemini;lang=en-GB