1. 17
  1. 5

    Thanx for the readings far! Really enjoyed them even though I didn’t get all of it. :)

    1. 4

      IRC is ultimately a low-bandwidth medium. So for everyone trying to participate, there’ll be plenty of awkward silence during which they don’t really know what the reader is eyeballing. Finally they get a summary of some section of code, after which they can try and catch up by reading that code for themselves. It doesn’t help that there’ll be noise and dead ends unless the reader is already super familiar with the code. So the IRC backlog gets messy and is quite demanding to keep up with for anyone who wasn’t doing their own read on the side from the start. Yeah, it really doesn’t work too well. It’s great for discussion and debugging things together though.

      One thing I’d love to try is pairing up such that both people have their own terminal or tmux session, and they’re displayed side-by-side, and there’s voice chat. That’s much higher bandwidth, and you see exactly what the person on the other side is doing. And when they get stuck or you have ideas to contribute, you can show and tell – by showing the relevant code, perhaps modifying or commenting it, and explaining as you go. Obviously this is harder to arrange and doesn’t really scale, but the bandwidth is so much higher that maybe you can afford all the dead ends and enter less prepared. For non-reading participants, it’d be a more focused experience than the IRC messages interleaved with awkward silence.

      In this format it’s still possible for others to participate via chat, and maybe they can get something out of it (and give something in return) even if they don’t have grep and a local copy of the source tree?

      Another thing that might help is some sort of a note file that can be updated live. So instead of posting everything on IRC (hard to follow), one could take notes in a more palatable format and revise them as needed. It could be editable by the participants (e.g. with something like etherpad) so others can fill in links to source code, fix typos, add questions and remarks, etc.

      I sure hope we get to have another fun bug-squashing session some day :-)

      1. 4

        Nice ideas. @smalina and I tried something similar for a while: tmux sessions later transcribed to https://github.com/akkartik/mu/wiki.

        Tmux isn’t very bandwidth intensive. Unfortunately it only has one cursor, so you can’t quite browse independently yet observably.

        (/cc @nickpsecurity, @rain1)

        1. 1

          So, how do I tie into this as a guy using graphical apps on Ubuntu? I dont do much terminal stuff at all probably since I got my start on MS-DOS and Windows. Ive considered gettimg back into using terminal apps for improved efficiency and security but not currently knowledeable.

          1. 2

            Yeah, tmux is for text mode only. GUIs would require something like VNC or NoMachine. Which is also pretty decent. A little more bandwidth intensive, but may work quite well for you. Both work on Windows. Other options: https://en.wikipedia.org/wiki/Comparison_of_remote_desktop_software

            The other part of this is getting used to a CLI. Perhaps I can help you with that? I certainly don’t do everything in text mode. But perhaps we can chat about your workflows and what parts of them would be interesting to try out in text mode. Just for education, not necessarily for efficiency or anything. Just trying out stuff in case it generates new ideas. Going outside your comfort zone, etc.

            1. 2

              I appreciate the offer. I might do it in the future. Right now, I had to put a lot of IT work on pause to deal with work and family issues. Kind of overloaded. Still commenting since it doesn’t take a lot of time and energy.

      2. 2

        The concept is great, and I enjoyed the reads that I lurked on, thanks for putting in the effort.