22 January 2023

Encumbered by the hacking process

I come to youse live from a New York State Thruway service area…

…because when I write blog posts, I have to finish them in one sitting, else they never get completed and start to make the whole place reek, not dissimilar to an astronaut not finishing their meal on the International Space Station…

I'm on my drive back from a (collegiate) hackathon in Toronto, and let's just say that this showing was downright embarrassing to say the least. I brought the entire complement of tools, parts and whatnot that usually come for the ride to these events with the intent to build something wonderful, but ended up without motivation for the final four hours and unsalvageable software component, thus no submission and no demo. My team did the best we could even finding a problem to tackle at all that would make for a good demo, but at least for me, I simply felt so uninspired and brain-dead that it brought the whole experience down for both myself and the team. Reckoning time.

On bright notes, my friend Bailey came thru (she registered but could only stay briefly on Saturday) and we finally linked up irl. To future adventures with whoever we can conjure up from the gang! Also the Eagles won 38–7, and as soon as I saw the Birds at 31–7…chills.

Earlier in the month, I confided to a few friends about some thoughts I've been having about the "standard" collegiate hackathon format. Hell, if I really think about it, I've been having them since HackCon (conference about mainly collegiate hackathons and communities) back in August 2022, and even earlier since BSDCan 2018. Why it took this long for these to come to a head, I have no idea, but I'm actually glad this is happening.

My collegiate hackathon career is probably best described similarly to Nick Foles's NFL career: inconsistently great or abysmal depending on the year/team/situation, almost contemplated retirement during a down period (but then the Birds signed him back as a backup and happily after ever). Except I actually did declare myself retired from participating as a hacker after winning Jefferson Health Hack 2016, slowly trying to shift more towards technical mentorship instead, but for those who know how abusive relationships go…

Collegiate hackathons are almost always competitive events with sponsors and prizes where some sort of user-facing prototype is demoed at the end. This format is great for those looking to skill up and network in the job (internships included) hunt whilst having fun learning and building something in 24–36 hours. This was my mindset during my first round of undergrad, and as long as my team had an itch to scratch and executed such that we had a demo at the end, served me well.

Things changed a little after winning Jefferson Health Hack 2016, things changed some more after BSDCan 2018, and things drastically changed after getting my amateur radio licence. For a little, man, mentoring at the competition-type hackathons just hit different and in the best way possible: instead of effectively helping one team win, you're helping all the teams who request your assistance win. For some more, the hacker lounge at BSDCan (along with the FreeBSD Developer Summit that I was not invited to back then) helped me personify the spirit of the original open source project hackathons: get as many folks working on similar stuff, who would otherwise do it asynchronously over mailing lists, IRC, etc, in the same room (not necessarily indoors) for a concentrated time period to trade notes and get stuff done.

I do want to place emphasis on this drastic change after getting my amateur radio licence. With egging from Jedi Dough Boy, particularly his PLAY BREAK LEARN, we have co-opted the existing Field Day events by adding a hackathon element. Of course not as a competition, but rather in the original open source spirit, feeding off the energy from everyone else hanging about or operating. So much that as soon as I mentioned working with an XR-2206 monolithic function generator chip for a class this semester, multiple other hams have egged me to have a whack at it next weekend at Winter Field Day. Just see how many directions we can go, in a cursory manner, but most importantly just having fun, not worrying about networking or prizes or other not important stuff.

The "standard" collegiate hackathon format really does not bode well for say, improving existing open source projects, particularly incremental or more behind-the-scene/infrastructure improvements. Said format also does not bode well for more experimental hacks with components that need more pre- preparation, like what I found with trying to base this weekend's attempt on Automatic Packet Reporting System. The original, non-competitive, community-oriented setup works much better for these cases. I'm also at the stage where I don't particularly care for computing careerism, but that's another topic entirely.

When pressing the format differential at venues like HackCon, I can almost smell the indifference. The original, non-competitive, community-oriented setup relies heavily, maybe even almost solely, on intrinsic motivation to make something happen. The competition-type events also have that extrinsic motivation that attracts a demographic that I am no longer in, one that has (early-stage) careerism almost top of mind.

Time to get back on the road and hope that they are treated correct. There's just enough snow coming down to stick to non-treated surfaces the whole rest of the way…

at No comments:

31 December 2022

The one where the wins come at the very end

Technically this is a blog reboot, not a new start. It's been much much more than a minute since I've done any sort of long-form, updates(?) on what I do for fun or pain, and maybe somebody wants to waste some time reading. This is also half-instigated by my friend Tiffany:

The ship has kinda sailed for the quarterly reports, but I think blogging more than makes up for that. Spoiler: all of these "wins" have something to do with my work on FreeBSD ports. Not sorry to disappoint if you were expecting anything otherwise. In no particular order:

PEP-517 framework support

This one's been kicking my arse since the second quarter of the year, mostly between having to mind real life (mostly academia), other moving parts of the open source ecosystem living in our ports tree and actually playing human (so more real life).

I'm so damn excited to land this. Can't put it into words. Not from fighting all the trials and tribulations called distractions and moving parts within the ports tree, but rather PEP-517 is just that much better than the lemon Python packaging once was.

Implementing this into the ports framework, with yuri@ starting it off, wasn't particularly difficult. I really wanted to focus more on the not-really-technical bits of proper problem scoping and consumer expectations, namely to provide a seamless as possible transition between from the old way without reinventing any wheels (pun intended). Those first couple implementation takes before I could catch wind of it (because real life) just didn't cut it.

Some more real life later, the one remaining but incredibly important snag to seamless transition was making sure autoplist behaved itself, including when multiple Python distributions (versions) are on the system at the same time. These two iterations of Python packaging have always included installed file manifests, so it only makes sense to continue using this facility rather than having porters maintain a separate manifest (called a plist) for each Python package port.

Next steps are to rework the use of setuptools in the tree. There's a lot of unnecessary, and now wrong, uses of setuptools, particularly after version 58…

Cinnamon 5.4

I had this going way earlier in the year, to the point where as of this writing 5.6 is the current version. But I never put it up in Phabricator, until now, because I thought I would get around to qualifying the reworked Wacom support. I guess that will wait for either when I sit down to work on 5.6 or xf86-input-wacom.

Firefox and Thunderbird toolchains

I'm currently typing this on a fully up-to-date Firefox 108.0.1:

I ran Firefox 107 for a little bit even after it End of Lifed, not the greatest idea of course. As alluded from the tweet, the delay in updating came squarely to toolchain selection…

Both the latest Firefox and Thunderbird not only require C, C++ and Rust toolchains, but the very beginning of the build process uses Node.js and parts of the source are now in WebAssembly. It didn't seem that long ago when it was just C, C++ and Rust; hell I still remember the days of wrangling Cygwin and Microsoft Visual C++ to play nice together to build my own Windows binaries.

For Firefox 107 I had LLVM/Clang 14, Rust 1.64 and a revision of WebAssembly System Interface (WASI) libc from early May 2022. Particularly between LLVM/Clang and Rust, the LLVM version has to match, particularly with link-time optimisation, else bizarre things happen. This worked until both Rust 1.65 and other factors had me moving to LLVM 15, which that revision of WASI libc did not support. I had tried earlier in the year to update to a revision dated early June 2022, but ended up with opcode errors I didn't know how to deal with…until actually having some time to sit down with them.

Turns out this was long a known issue, thanks to the folks at Arch Linux (which I used to use). Some time during May, WASI libc gained the use of bulk memory opcodes. This is otherwise a great thing! But the mozilla-central repository (home to Firefox sources) still contains and uses an older (and forked?) copy of wasm2c that does not support these opcodes, so when the WebAssembly bits get linked, the linker becomes sad:

error: unexpected opcode: 0xfc 0xa

I still needed to use a newer WASI libc that supported LLVM 15, which contains the bulk memory support, but that support was easily disabled in the Makefile, so I did that accordingly. And now we have the happy ending that, after some cleanup, I'll put in Phabricator.

Python cryptography library backports

I actually dedicated pretty much all of the week leading up to Christmas for this one, judging by commit logs. And almost entirely because about a fifth or sixth of my listed ports would not build without it.

But hold up, that's an ancient cryptography version. And you would be right, in a vacuum. But we don't live in a vacuum, we live in an imperfect world where we have choices in secure communication libraries (a very Good Thing) and how they are implemented. I switched to LibreSSL soon after Heartbleed happened and haven't looked back to OpenSSL since, even though there have been moments where I wanted to give up the good fight in keeping consumers compatible with both.

On the cryptography side of things, starting version 35, they integrated Rust code to replace bindings for non-cryptographic operations. Their project, their choice.

There exist certain operating system communities where it is a tradition to build your entire system, or as much as personally practicable, from source. Gentoo is probably the most (in)famous about building from source, but building from source has always been a tradition in the open source BSD family, even though all have binary repositories as a convenience. With this in mind, compiled programs should be relatively quick or pain-free to build, which ties in with Unix philosophy and C's wide proliferation among other things. Building the entire Rust toolchain from source is extremely painful and resource-intensive compared to all that. It is this pain that has some longer-time committers and other FreeBSD community members calling for de-oxidisation…

I care about that but not to that extent. Sure, it might take like five hours or so on this ThinkPad, but I'm also not afraid to tweak operational parameters such that I start the build when I crash for the night and wake up to hopefully success. The real problem for me is that Rust (and go and probably some more new-age compiled language toolchains) will not build or run under QEMU user-mode, which I use as part of cross-compiling stuff for my ARM and RISC-V single-boards.

So cherry-picking we go. As long as stuff keeps working and tests (particularly downstream) passing for the most part between OpenSSL 1.1.1 and 3.0 and LibreSSL 3.5 and later, I'm a happy man.

What's next

Time to enjoy the scenery and get lit for the new year, until the next post I guess.

at No comments:
Subscribe to: Posts (Atom)