08 August 2023

Sales Whore University

Man, even though there have been some wins, my 2023 thus far has been a year of Ls.

We lost the Super Bowl.

I wasted my last collegiate hackathon.

I squandered a really nice (on paper) grad school opportunity.

We lost Interstate 95.

But worst of all, we lost this guy:

[19:43:32] <vishwin> you still have that dough boy shirt?
[19:44:23] <jedijf> i do not...just my dough boy clock in the office and dough boy tie on Yoda

His irl name was Jim Fisher. His internet name was jedijf, and his amateur radio call sign was AJ3DI (originally KC3BRA). A bunch of us were chatting away on IRC that morning. Two mornings later we all received the bad news. I still have no words to describe the pain that not only myself, but everyone else he worked or played with, all felt.

Most will remember him as every ham's favourite ham and all the support he provided to the various technical open source communities in the Philadelphia area and beyond.

Yes, communities as plural.

Yes, technical open source communities.

You can read all about it via everyone else's tributes and such on the obituary and various public mailing list threads. Others have more coherent words on the subject than I probably ever will.

But was tech his career?

NO!!!!!!

He sold bread!

Best secret weapon ever.

For those of us who are relatively not social technically-minded people, we easily get caught up in prerequisite this, given that thinking. Someone else who comes along, who does not necessarily have a tech background, but eager to play, break, learn as much as possible, together, and have a knack of selling unadulterated joy of the process easily becomes a best friend.

Selling bread, selling playing with fire (technology).

Those in the bread business with him can elaborate more on how he revolutionised service to customers and whatnot. That's only part of the story. I cannot drive home enough just how good at sales he was, encouraging people to play, getting people out of their comfort zones.

Every interaction with him, especially lately, and even more so in a group setting, was a class session of Sales Whore University.

Whenever I am to give someone unfamiliar with Jim what his essence was in a concise manner, I always use the advert he recorded by messing around at a community broadcast radio station. Just brilliant.

This clip predated my ham radio journey but not my Philly open source community journey. At that time, I was an arrogant impatient prick, more than I am now, just getting my feet wet with the irl half of the open source community. Jim always emphasised how the virtual/online only constituted half the experience.

During my prime collegiate hackathon days, I started dabbling with wireless communication as part of my hardware hacks. Once I finally decided to bite my tongue and cram for my initial ham licence, I signed up on Jim's club exam session. Lowkey I was hoping he wouldn't notice, but it didn't take long to get an IRC message from him. Even though he wasn't at that exam session, he would get me soon enough by ganging a bunch of the open source community folks up to attend a ham club meeting, making me a member of said club on the spot and giving me some equipment he wasn't using just to get me started. He didn't have to do any of that shit.

What I slowly learnt from that act and many more over the years, with so many other people, constituted the finest acts of salesmanship and service. Acts of a true sales whore.

He made sure to use whoever he interacted with's intrinsic motivation to not only reinforce why they showed up, but to try new things, get people out of their comfort zones a little. He called it "PLAY BREAK LEARN"; for those who have ever wasted a perfectly good hour listening to Car Talk, this was his phrasing of "unencumbered by the thought process". Attraction over promotion.

Sometimes it would take a bit, perhaps years, for stuff to have the desired effect on people to take action. This was perfectly okay with him, unlike my impatient arse. Good lasting sales are always a long game.

Growing up, I was never a fan of doing "community service". Many such activities seemed dry like improperly cooked chicken breast, especially when not amongst friends. I confided to him and others that they always felt like more of an obligation than anything fun, rewarding and lasting, particularly amongst the biologically younger crowd who were exposed to such activities in this manner. The Multiple Sclerosis Society's City-to-Shore ride was coming up, and the ham team needed more bodies. In another act of attraction over promotion (and wrangling and begging), Jim flipped the notions of community and service on their heads: we will play radio, hang out and convoy together as a community, most importantly amongst friends who actually want to be there, and oh we just so happen to support a cause in the process. I'm about to do my fourth MS 150 this year, but through his framing, branched out to other ham radio service events that other friends do like the Boston Marathon.

There are so many more examples of Jim's salesmanship, like the time he got an indoor(!) vendor table at the Kimberton Hamfest, ostensibly to have MS 150 paper sign up sheets and info to those interested, but ended up as a hang-out table. I believe this was the other Charlie's (K3NOP) first hamfest, where he bought an HF rig and some coax cable, eager to do some testing, so Jim had him wire just the coax up tuned to KYW Newsradio to check proper receiver function. At some point, maybe before, Jim got asked what he was selling at the vendor table. "Nothing! The hobby!"

Ultimately, the only thing that mattered to him was whether you played, broke and learnt. He was not one for compliments or anything resembling a personality cult; principles over personalities all day every day.

I'm probably rambling to the point of needing to pass out. Even when having fun and reminiscing and whatnot, big dogs gotta sleep. I'm sure besides any actual cause of death, Jim needed to pass out after a long day of working and playing, to get ready for another early morning of breading. I do hope that when he wakes up (somewhere else), he sees all the text messages, phone calls, screenshots, etc of all the joy he spread, all the people helped, all the confidence and inspiration, all the careers launched, all the communities and initiatives formed and strengthened and continued, and most importantly, the family raised. Probably a smoky smell in there too, like damn dude.

left to right: me, Adam K3JCP, Jim NS3K and the Jedi himself at Philly Maker Faire 2019
courtesy Mark WA3QVU


at No comments:

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)