Wow, it's cool to see astrometry.net get put to use! I worked on astrometry.net back in undergrad and grad school. If you have questions about how it works, I can answer them.
How does it work? astrometry.net uses 4-star combinations to define codes, then indexes the codes on the celestial sphere. The particulars of each of these phases matter, but that's the basic idea.
I used to be in astronomy and I always thought astrometry.net was one of the coolest tools in the field. It feels about as close to magic as you can get.
Astrometry.net is damn handy. I don't use it too much these days for myself except for annotating images, but I do have some friends just getting into astronomy and it's blind solve is amazing to help them.
Plus when I show them plate solving their minds are blown. Hugely useful tool.
Take a look at Veritasium's perspective on this issue [1]. Veritasium reflects on clickbait thumbnails from the content producer perspective, and balances that against the motivation behind YouTube's algorithms. His final conclusion is that cilckbait isn't all bad, and that it serves an important purpose for both viewers and content creators. His classification of clickbait into different types is also fascinating.
Very minor anecdata I would like to share: I have discovered Veritasium like most others, at the time when they weren't "clickbaiting", when their videos actually had the thing that they discussed right there in the title. I learned tons of things. Each new video, and each title, made me eager to discover that thing.
But around the time they implemented their "clickbait" titles and thumbnails, it had the opposite effect on me. They all just *seemed* like so many other videos: bland and tasteless. The content itself hasn't much changed, but the allure certain has diminished for me. I've stopped watching their videos.
Compare that to Curious Droid, or Practical Engineering, which still use descriptive titles, sometimes questions, but always exactly about the subject.
The key to understanding ELF is that it serves three purposes:
(1) Execution - A container describing how an OS can load and execute a binary
(2) Linking - A container with relocatable machine code; for the linker to assemble
(3) Metadata for debugging and other purposes like stack traces
Program headers describe "segments". Segments are for the execution time view of the ELF. They describe the parts of the file to load into memory regions, and the execution entry address. The program headers are what are read by the OS when running "./my_executable". The segments don't always have names. Also, it is confusing that "sections" and "segments" mean very different things, but that's just how it is.
Thus, program headers (and the segments they describe) are for #1 - Execution.
Sections are a link-time construct, leveraged by the linker, to decide how to allocate functions and data to the execution segments (via sections). Intermediate ELF object files contain relocatable code, where the code is allocated to sections (you can manually specify them if you want). Example sections include ".text", which is executable code; ".bss" which is zero-initialized static variables; ".data" which is pre-initialized static variables, and so on. You can see an example of sections being allocated to segments in this thoroughly described linker script [1]. Sections are mostly ignored during program execution.
Thus, section headers (and the sections they describe) are for #2 - Linking.
You aren't alone in not knowing these details about ELF. It wasn't until I got into the embedded space that I dug deep to understand linking and loading, linker scripts, and executable formats. These details are important to understand for microcontrollers since you may need to carefully allocate code to physical addresses that have faster memory (e.g. core coupled RAM), or put code in flash. In some cases you execute code directly out of flash (so must tell the linker that including physical addresses); but in other cases, you might need to load code into RAM (manually, there is no OS!) from flash since executing out of flash can be slow. On desktops and servers, it's rare to change (or even know about) linker scripts.
The value of Hongjiu Lu's paper is that it brings the overarching end-to-end essentials succinctly together for a programmer (non-baremetal). Once i got into Embedded, things became much more clearer but those were just details.
Valora made it easy for me to donate to a typhoon relief effort - https://doni.app/c/36/. The onboarding flow is well thought through. Valora is the first app that for me, feels like a crypto currency system that's usable by normal people. I suggest checking it out if you've interested in crypto but haven't given it a try yet.
If you're interested in self hosting and willing to put in a bit of work to collect data from your online presence for archival, take a look at Perkeep (previously known as Calimstore) [1].
Have you seen Saga [0]? They're an app for making private podcasts with people in your life but, it's free - they help you choose questions and then everyone can hear each other's answers. There is an app [1] for the tech savvy, but also they have a dial-in option for older users where they can just call from a landline and record that way.
My team works on Pigweed [1], which offers a more terminal based approach to embedded development. Instead of working with Make, we use GN [3] as our primary build system (though we also support CMake, and plan to support Bazel).
The "pw watch" command is an integrated watcher that can detect file changes from e.g. vim, then re-build, re-flash your device, and re-run tests according to the dependency graph. I use 2 or 3 STM32F429i Discovery boards to run tests in parallel.
If you're curious, we're giving a workshop [4] at Hackaday's Remoticon; feel free to join or watch the recording after it's up.
For those who are interested in the accounting side, I highly recommend Financial Shenanigans by Howard Schilit [1]. If you don't have an accounting background, all you need to get value out of this book is a basic understanding of the double entry accounting method, and understand the four financial statements: balance sheets, income statements, cash flow statements, and statements of shareholders equity.
After reading this book, I found myself digging through earnings reports to look for signs of shenanigans, and have found cases that raise my armchair-accountant eyebrows.
Thank you for this, I just bought the book. Any books you'd recommend to go over the prerequisites you mentioned? I read this [1] ages ago but I honestly don't remember much at this point.
I took a class specifically on this - how company manipulate their financial statements to make things look better.
It's really fascinating. If you're willing to dig into the financial statements (and ones from the past), you can learn a ton about how a company defines "performance" and whether or not it's reasonable.
Despite GAAP accounting rules, there is enough gray area for companies to hide a lot of bad information.
It's pretty interesting to study the mechanism of the fraud. Enron did a lot of things, but one of the big ones was how they booked revenue. Since they were a middleman, they should have booked their cut (i.e. fees) as revenue, but rather they booked the entire purchase as revenue, drastically inflating their growth.
https://pigweed.dev/docs/size_optimizations.html