logo

drewdevault.com

[mirror] blog and personal website of Drew DeVault git clone https://hacktivis.me/git/mirror/drewdevault.com.git

Hack-everything-without-fear.md (3488B)

    

  1. ---
  2. date: 2018-03-17
  3. title: Hack everything without fear
  4. layout: post
  5. tags: [philosophy]
  6. ---
  8. We live in a golden age of open source, and it can sometimes be easy to forget
  9. the privileges that this affords us. I'm writing this article with vim, in a
  10. terminal emulator called urxvt, listening to music with mpv, in a Sway desktop
  11. session, on the Linux kernel. Supporting this are libraries like glibc or musl,
  12. harfbuzz, and mesa. I also have the support of the AMDGPU video driver, libinput
  13. and udev, alsa and pulseaudio.
  15. All of this is open source. I can be reading the code for any of these tools
  16. within 30 seconds, and for many of these tools I already have their code checked
  17. out somewhere on my filesystem. It gets even better, though: these projects
  18. don't just make their code available - they accept patches, too! Why wouldn't we
  19. take advantage of this tremendous opportunity?
  21. I often meet people who are willing to contribute to one project, but not
  22. another. Some people will shut down when they're faced with a problem that
  23. requires them to dig into territory that they're unfamiliar with. In Sway, for
  24. example, it's often places like libinput or mesa. These tools might seem foreign
  25. and scary - but to these people, at some point, so did Sway. In reality these
  26. codebases are quite accessible.
  28. Getting around in an unfamiliar repository can be a little intimidating, but do
  29. it enough times and it'll become second nature. The same tools like gdb work
  30. just as well on them. If you have a stacktrace for a segfault originating in
  31. libinput, compile libinput with symbols and gdb will show you the file name and
  32. line number of the problem. Go there and read the code! Learn how to use tools
  33. like `git grep` to find stuff. Run `git blame` to see who wrote a confusing line
  34. of code, and send them an email! When you find the problem, don't be afraid to
  35. send a patch over instead of working around it in your own code. This is
  36. something every programmer should be comfortable doing often.
  38. Even when the leads you're chasing down are written in unfamiliar programming
  39. languages or utilize even more unfamiliar libraries, don't despair. All
  40. programming languages have a lot in common and huge numbers of resources are
  41. available online. Learning just enough to understand (and fix!) a particular
  42. problem is very possible, and something I find myself doing it all the time. You
  43. don't have to be an expert in a particular programming language to invoke trial
  44. & error.
  46. If you're similarly worried about the time investment, don't be. You already set
  47. aside time to work your problem, and this is just part of that process. Yes,
  48. you'll probably be spending your time differently from your expectations - more
  49. reading code than writing code.  But how is that any less productive? The
  50. biggest time sink in this process is all the time you spend worrying about how
  51. much time it's going to take, or telling me in IRC you can't solve your problem
  52. because you're not good enough to understand mesa or the kernel or whatever.
  54. An important pastime of the effective programmer is reading and understanding
  55. the tools you use. You should at least have a basic idea of how everything on
  56. your system works, and in the places your knowledge is lacking you should make
  57. it your business to study up. The more you do this, the less scary foreign code
  58. will become, and the more productive you will be. No longer will you be stuck in
  59. your tracks because your problem leads you away from the beaten path!