add temp bloat crap

posztok/2023-Jun/bloat.org

@@ -0,0 +1,69 @@
+#+title: Some notes on "bloat"
+#+date: <2023-06-24 szo>
+
+Hey, I don't have philosophy studies behind me, so others should correct me on this stuff.
+
+Much of this is straightforward af, so please don't blame me for not thinking a lot.
+
+** Backstory
+
+I first met the idea of "bloat" when I still had a Pentium IV machine, somewhere between 2010 and 2013. I used multiple softwares that could be considered "bloated".
+
+Minecraft was a game I started playing back then, and it was interesting to see how between somewhere 1.2 and 1.3 the multiplayer server was started being used as the backend for even "single-player" worlds. The event made the game much less playable on my machine, and it made me think about how a game with this bad graphics could run badly on my computer.
+
+Another case was the issue of "web browsers". Back in 2008-2010, my Pentium III machine ( running a particularly strong CPU codenamed "Tualatin", which had more freqs than the rest of the PIII lineup, and had double the cache size ) still had some trouble running facebook on K-Meleon, a gecko-based browser focusing on low resource usage, but I didn't really take notes back then, and the issue came back when I switched to linux and I had multitudes of browsers to choose from. It wasn't really noticeable at that time, and after a two-year "excursion" on a back-then modern i5 laptop, I switched back the a Athlon 64 X2 ( one of those on 65nm, which ones had half the cache of the top-of-the-line models ), and it was REALLY bad running a browser on that crap.
+
+I also saw the slow creep of OS sizes ( especially on windows installs ), and that systems started using more RAM in htop. While the htop phenomenon turned out to be about filesystem caching when enormous amounts of ram are available ( first 8GB on a later machine I owned from 2016, then 16GB on my current desktop ).
+
+** Current thoughts
+
+I've read a bunch of articles, news items, etc. during my lifetime, and a few of those resonated with me pretty well. For example, computers can feel really sluggish due to response times: [[https://lwn.net/Articles/749992/][terminal latency, pt1]] and [[https://anarc.at/blog/2018-05-04-terminal-emulators-2/#latency][pt2]] and
+
+My big gripes with the idea of bloat is: it's arbitrary af.
+
+First of all, it depends on the machine you own. What runs uncomfortably slow is bloated. Whatever takes up a lot of avaiable space is bloated. Another case: with compilers, "optimizing for size" can outmatch "optimizing for speed" in terms of runtime speed when the smaller program will fit into the cpu cache as a result.
+
+Second of all, it depends on the circumstances of the user. If you machines uses up a lot of energy computing the stuff you want, the software it runs might be bloated. If it runs for a lot of time but you rent the computer only for a given timeframe, the software might be bloated.
+
+If you are the one designing the piece of software, you have to know the target audience and their circustances. This is where the big problem of IT comes in: everybody is designing /general/ software meant for /all people/. As "the user" doesn't exist if you design for /all/, the software makers' inherent biases affect what they imagine as "the user".
+
+For example, I think it's an asshole idea to create a piece of software that can only use 8-bit ASCII and not unicode. Others consider non-english language support a bloat -- my guess is they think learning English is easy and should be mandatory or somwthing. Even just supporting Unicode adds a lot of complexity, let alone supporting locales.
+
+I think this is mainly an issue of empathy. The programming world has long been contaminated by elitism, disdain for "the user" and their skills, etc. i think [[https://protesilaos.com/codelog/2023-05-11-accessibility-software-freedom/][Protesilaos Stavrou]] put it well in his essay. This perspective can also help understand how this could manifest in the elitism culture of "less bloated" software.
+
+** A different perspective
+
+I do believe that for phenomenons that exist society-wide:
+
+1. one cannot really just blame the individuals' failures for them
+2. there are material factors that play into the systemic emergence of them
+
+In this spirit, I'd like to show my hypothesis, that the political-economical climate is what causes the "less bloatet" subculture's existence.
+
+We know that the great boom of IT coincided with the thing called neoliberalism, which, among other things, encompasses the following ( I think relevant ) ideas:
+
+- emphasis on individuals and their responsibility
+- emphasis on dismantling and discouraging workers' organizations like trade unions
+
+I we wanted to make a software company with a software product, we want to reach the biggest possible audience, and for that, we need the greatest available generality in the software.
+
+If you don't criticize the underlying neoliberal principles, but have problems with the present of "bloated software", the natural conclusions are
+
+- blame individual programmers for the failure to produce less bloated pieces
+- you become elitist because of the above
+- you can't really think in communities ( emphasis is on individuals ), so communities as solutions only appear rarely
+- create your own alternative small software tools /by yourself/, /for yourself/, /in your scope of possibilities/.
+
+Atomized individuals are less powerful than communities and because of that, the code they can work on is necessarily smaller. So you make the code smaller not only to make it less bloated, but also with the aim that you'd be able to understand it and work on it. The essay [[https://applied-langua.ge/posts/terminal-boredom.html][Terminal boredom]] elaborates on this idea. The basic premise is that since individuals can't control the complexity needed to handle today's aims for software, the aims must be wrong, they are too ambitious ( the blame can't rest on the fact that groups of individuals could handle it ).
+
+One of the shortcomings of this approach is that while the software will be less complex, the processes by which we handle them ( including thought processes and software scripts that wrap the less-bloated software pieces ) will become more complex or complicated. This is why suckless software pieces have SO MANY patches  and you need to apply them yourself, individually. Complexity manifests itself elsewhere because the complexity required by the problem didn't really get lower, you just redefined the problem and thought you are done -- but it turns out that we might actually want some of our software to be general ones.
+
+** Conclusions
+
+I think these are the other causes why more empathy in programming is needed. You need not only to know your users well but also your future users. You need to know their machines as well, and also their possible future machines ( which might be "slower" than the current ones ). You need to figure out which particularities you can use to optimize your software ( maybe only x86 machines will ever run your stuff ). If you have more empathy towards people, you will be able to reach more people with your software tools.
+
+More empathy can not only result in cpaital gains due to larger userbase, but if your software is either aimed at fellow software creators, or rely on users for bugreports, or if your software is programmable by the "average users" as well, you can gain a more active community, which could improve the overall quality of your software, or you could get addons written by them that even you might use in the future.
+
+I think that a good example is Emacs. Its aim is the be programmable for the user, it provides a lot of documentation, exploration options, and naturally leads you to programming it. It's also a huge piece of software that is managed by a very active developer community and as a user, it seems to me that it's reasonably fast, I have many pathways to optimize it when needed, and it also has very few bugs. Also, being able to access documentation AND the code from the editor at the same time is a killer feature.
+
+As a final thingy, I think that the current emphasis on licensing misses the biggest point of free and open source software: community involvement. Even in the GNU manifesto, Stallman dreamt of a community in which you can ask better-at-programming people to do the coding for you or look at issues for you, not single individuals working at separate pieces of software, alone, separated from others.