💾 Archived View for gemini.dimakrasner.com › re-on-bloat-and-ingrates.gmi captured on 2023-04-26 at 13:21:34. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

Re: On Bloat and Ingrates

gemini://gemini.ctrl-c.club/~stack/gemlog/2022-05-09.lagrange.gmi

re-bloat.gmi

gemini://ainent.xyz/gemlog/2022-05-07-critique-of-lagrange.gmi

Sometimes I hate numbers. I've seen many products with good test coverage (> 80%), which don't work at all or have rotten tests that pass without testing anything. And most software projects can be "cleaned up" to drastically reduce their LOC counters: sometimes, without any change in binary size or general clarity. Yes, LOC is a bad indicator of code quality or readability: you can always find counter-examples, and I'm not a big fan of dwm's coding style.

Maybe I wasn't 100% clear, but I disagree with Ainent's critique of Lagrange. I use it on my more powerful laptop, and I think it's great. "Bloat" is bad in some contexts, but it's interoperability and not "bloat" that matters in this case: old machines with little RAM can run other clients, to avoid things like software acceleration (my Thinkpad X60s doesn't like that). Separate Gemini and Spartan clients are a waste of space and memory, if 99.9% of the code is shared and many Spartan users are likely to use Gemini too.

It's nearly impossible to build a small Gemini client in first place (before extra protocols, etc'), because TLS libraries are big: without the UI and other great things that make Lagrange so popular, it's probably just as "bloated" as most other clients: the example of gplaces (basically, a Gemini->less pipe) shows that even a minimal client (which most Lagrange users would find unusable) hits the 3 MB mark, and LOC counters or supported protocol counters are useless when you look at the final product. Relatively, Spartan support adds a negligible amount of "bloat" to the AppImage contents:

    2.9 MiB [##########]  libcrypto.so.1.1
    1.5 MiB [#####     ]  libunistring.so.2
    1.2 MiB [####      ]  libSDL2-2.0.so.0
    1.1 MiB [###       ]  libgcrypt.so.20
  677.0 KiB [##        ]  libvorbisenc.so.2
  583.5 KiB [#         ]  libssl.so.1.1
  542.0 KiB [#         ]  libsystemd.so.0
  530.0 KiB [#         ]  libpulsecommon-11.1.so
  489.0 KiB [#         ]  libFLAC.so.8
  484.0 KiB [#         ]  libsndfile.so.1
  457.5 KiB [#         ]  libpcre.so.3
  414.5 KiB [#         ]  libwebp.so.6
  324.0 KiB [#         ]  libdbus-1.so.3
  319.0 KiB [#         ]  libmpg123.so.0
  318.5 KiB [#         ]  libpulse.so.0

(and, a stripped Lagrange executable is smaller than many other clients)

Those who find Lagrange bloated should blame OpenSSL and SDL, and client developers definitely have multiple options to choose from. (Trying the console-based Lagrange is in my TODO list.)

But, I don't like the idea of one known-to-work client, especially when I have to mimic its behavior if I want to build a client that works in the real world, regardless of what the spec says. I'm not super happy to implement Spartan, because I support the idea of mandatory TLS. If I see lots of spartan:// URLs on Gemini, I will definitely clean up my Spartan port and add this "bloat", which shouldn't be more than 20 LOC (😉). Luckily, now I can compare the behavior of my Spartan client code with that of Lagrange 1.13.x.