about summary refs log tree commit diff homepage
diff options
context:
space:
mode:
authorNguyễn Gia Phong <mcsinyx@disroot.org>2022-11-10 22:15:20 +0900
committerNguyễn Gia Phong <mcsinyx@disroot.org>2022-11-10 22:20:25 +0900
commit408e4db30f1e1a7c71c9124a7d310fe6229905da (patch)
treeb3dd64c745eef8f5bce751fb916cd16e7ecaaac1
parent4aa04499c687f13a221d3a33ebed988d00b7771e (diff)
downloadsite-408e4db30f1e1a7c71c9124a7d310fe6229905da.tar.gz
Call for De-Dep Dec
-rw-r--r--_assets/outlets.jpgbin0 -> 134234 bytes
-rw-r--r--blog/dedep.md141
2 files changed, 141 insertions, 0 deletions
diff --git a/_assets/outlets.jpg b/_assets/outlets.jpg
new file mode 100644
index 0000000..d4e20c1
--- /dev/null
+++ b/_assets/outlets.jpg
Binary files differdiff --git a/blog/dedep.md b/blog/dedep.md
new file mode 100644
index 0000000..df21864
--- /dev/null
+++ b/blog/dedep.md
@@ -0,0 +1,141 @@
++++
+rss = "Comments for Static Sites without JavaScript via Emails"
+date = Date(2022, 11, 10)
+tags = ["fun", "packaging"]
++++
+
+# De-Dependency December
+
+> As we mature, the dependency graph matures with us.
+
+## Exposition
+
+In the [occasional fights] between system and language packagers,
+[I'm known to take the downstream camp.][ipwhl]  As an user, there are
+lots of things I take for granted.  I install the stuff I need,
+occasionally upgrade the system, and everything gets updated.
+Vulnerability in a library used by multiple programs?  Its patched version
+get swapped in within a few hours (given it's not [vendored or pinned]).
+[Most][debian] [distributions][fedora] [even][arch] [apply][opensuse]
+[hardening][gentoo] [flags][nixpkgs] that [some bugs aren't even exploitable
+in the first place][openssl].  They create a [safe place] for me to comfortably
+express myself at work and at home.
+
+Recently on my work computer, I've switched to Guix System, which has yet
+many packages.  Looking into the way to package programs I use
+and on-going efforts, I realized the colossal number of transitive dependencies
+of [certain software] and the impracticality for an user union (i.e. a distro)
+to maintain such set of [micro packages] in every language.
+
+## Confrontation
+
+This gave me a more serious thought on software sustainability.  Such topic
+often reminds us of energy consumption, modularity, development model,
+or even style (clean code).  End-users (including self-hosts),
+on the other hand, ask the following questions to decide upon installing
+and keeping a piece of software:
+
+- Can I *trust* installing this won't do anything funny to my machine?
+- How much [effort] I need to prevent people doing funny things to my machine
+  if the software includes [something that gets on the front page
+  of some magazines][heartbleed] tomorrow?
+- How much of my limited resources will it take to run or [simply exists]?
+
+There are certain intersections in concerns of enterprises and users,
+however it's worth noticing that distributions are almost exclusively optimized
+to cater for the users' need.  Not only they [fight for the users][tron],
+they *are* the users.  Suppose you don't want to write yellow-glowing programs,
+you should [make the life of downstream package maintainers easier][distros].
+No, it does not count if you push them to give in to run [`go mod vendor`][go]
+or [download from NPM recursively][node2nix].
+
+## Resolution
+
+*So how do I write software that is easy to package*, you may ask.
+If you followed the articles linked above, you've probably already
+figured that out.  It's less about what *you* write and more about
+what you *don't write*.  When someone complain a program is difficult
+to build from source, certainly it's not about how hard it is to type,
+say `make install`, but acquiring the dependencies for that to run
+successfully and the result will work.
+
+Lower the number of dependencies will absolutely help.  To put it bluntly,
+you can't have a problem with dependencies if there's none of them.
+This sounds like reinventing the wheel, but if the use case is common enough,
+you might find what you need in the standard library.[^rust]
+I've been restricting myself from using third-party libraries
+for new side projects and it actually worked for my most recent ones:
+
+- [Phylactery], a static comics web server on Go with [CBZ] parsing
+  and concurrent request handling
+- [Fead], an [SSG] plugin in Python for advertising others’ feed
+  with parallel HTTP request, parsing of RSS 2 and Atom and CLI argument parsing
+
+Even for such simple use cases, there are still many libraries in the wild
+that can handle more data formats, are more convenient to use
+or more performant.  On the other hand the amount of maintenance needed
+to keep the programs safe indefinitely for an user is much lower
+thanks to the small dependency footprint.
+
+What I'm asking you to give a try in the advent days[^advent] is not as drastic.
+Look through your works, find a library you require for a small portion
+of its [power], or something can be implemented specifically for your project
+using reasonable effort (w.r.t. the whole codebase).  This is not just
+for the sake of maintainability: [being less general, the new implementation
+can likely outperform the replaced public library][context].
+
+![Multiple types of sockets installed on the same wall](/assets/outlets.jpg)
+
+In many cases, you will find yourself making use of the standard library.
+Standards make life much easier, [if only][standards] people can come up
+with an agreement.  Maybe they don't have to.  Maybe each could choose
+among utilities libraries.  At the end of the day, it's the total number
+of packages that can have bugs to be reported upstream and patched that matters.
+
+That being said, please keep an eye on the standard library the same way
+you (should) watch your other dependencies, just in case what you need
+is finally added.  Worry not of backward incompatibility, users of LTS systems
+are content with older versions of your software.
+
+## Fall and Catastrophe
+
+I hope not.  I look for [answers], not [tragedies].
+Though winter is coming, a lit De-Dependency December awaits.
+
+[^rust]: Unless you use Rust.
+[^advent]: I'm not Christian, but I had fun with [AoC] and [Neopets] before.
+
+[occasional fights]: https://www.youtube.com/watch?v=stChOsejLEQ
+[ipwhl]: https://man.sr.ht/~cnx/ipwhl
+[vendored or pinned]: https://blogs.gentoo.org/mgorny/2021/02/19/the-modern-packagers-security-nightmare
+[debian]: https://wiki.debian.org/Hardening
+[fedora]: https://fedoraproject.org/wiki/Changes/Harden_All_Packages
+[arch]: https://wiki.archlinux.org/title/Arch_package_guidelines/Security
+[gentoo]: https://wiki.gentoo.org/wiki/Hardened/Toolchain#Changes
+[opensuse]: https://en.opensuse.org/openSUSE:Security_Features
+[nixpkgs]: https://nixos.org/manual/nixpkgs/stable#sec-hardening-in-nixpkgs
+[openssl]: https://xeiaso.net/blog/openssl-alarm-fatigue
+[safe place]: https://www.youtube.com/watch?v=205ODJgAEik
+[certain software]: https://issues.guix.gnu.org/55903
+[micro packages]: https://raku-advent.blog/2021/12/06/unix_philosophy_without_leftpad
+
+[effort]: https://xkcd.com/303
+[heartbleed]: https://heartbleed.com
+[simply exists]: https://ludocode.com/blog/flatpak-is-not-the-future
+[tron]: https://en.wikipedia.org/wiki/Tron
+[distros]: https://drewdevault.com/2021/09/27/Let-distros-do-their-job.html
+[go]: https://github.com/NixOS/nixpkgs/blob/master/pkgs/build-support/go/module.nix
+[node2nix]: https://github.com/svanderburg/node2nix
+
+[Phylactery]: https://git.sr.ht/~cnx/phylactery
+[CBZ]: https://en.wikipedia.org/wiki/Comic_book_archive
+[Fead]: https://git.sr.ht/~cnx/fead
+[SSG]: https://en.wikipedia.org/wiki/Static_site_generator
+[power]: https://www.youtube.com/watch?v=3Mpyias9ek4
+[context]: https://media.handmade-seattle.com/context-is-everything
+[standards]: https://xkcd.com/927
+
+[answers]: https://en.wikipedia.org/wiki/Three-act_structure
+[tragedies]: https://en.wikipedia.org/wiki/Dramatic_structure#Freytag's_pyramid
+[AoC]: https://adventofcode.com
+[Neopets]: https://breezewiki.com/neopets/wiki/Advent_Calendar