free software resistance
the cost of computing freedom is eternal vigilance
### tcoyc-hacking-as-a-cure-for-bloat-and-monopoly
*originally posted:* dec 2023
people have tried to draw a line between "cracking" and hacking, which doesnt really bother me. im not sure how realistic the line is, hacking in the broader sense of the word is about exploiting the nature of systems- its not always something malicious or even illegal.
this chapter is about exploiting the nature of your own system- not in terms of breaking security, but in terms of "hacking together" solutions as an alternative to having everything done for you.
this is not a treatise against good design. good design has its place, it is often cited without justification (when a design is terrible, but uses the trappings of good design as an excuse for the opposite) and sometimes a "bad" design gets the job done well. a great example of this is a field dressing- it may not compete with the resources of a good hospital, but if youre stuck on a trail a field dressing may make the difference between an infection or worse, and getting to safety.
with that said, the concept here is one of non-emergency first aid- of tinkering, and of simply playing around. playing around can be done for its own sake, or for the sake of learning. it can also be done to solve real problems.
before this abstract gets any more out of hand, i have a couple examples that maybe i shouldnt be proud of, but they did make me happy. one involves a toy truck i owned decades ago, along with a voice activated radio- just for fun, i tried connecting the antenna of the voice activated radio with the antenna of the radio-controlled truck to see what would happen.
my understanding of electronics falls short of circuit design, though ive been introduced to some of the basics. based on what happened, its reasonable to assume that the truck was controlled by certain audible frequency ranges transmitted over the carrier wave produced by the controller. there are specific ranges of radio spectrum that commercial toys can use, and the two were either in the same range or close enough.
by connecting the antennae together, i ensured that the signal of of the transmitter was strong in the receiver. this probably matters for some reason, but i was able to control the truck by making differently-pitched sounds into the radio.
a higher pitched "OOOOOOOOOOOOH" would make the truck move forward, and a lower pitched "EWWWWWWWWWWWW" would make the truck back up and turn. why did i connect the antennae together in the first place? to see if it did anything cool. i wasnt sure anything would happen, and i still think i had good cause to doubt. i was between 10 and 15 when i tried this.
many years later, i decided that i would like to recreate "program manager" from windows 3.x, just for fun. it wasnt a particularly good program, though it was a familiar thing that i thought would be fun to recreate.
the desired result wasnt something i thought id be able to share, let alone sell, and it wasnt my desire to write an actual gui program with the full functionality of program manager- which is really just a file manager in icon mode, with shortcuts to favourite programs in groups. i simply wanted it to be identical to program manager, and open programs.
the first thing i did was get a screencap of program manager and cut it up into separate images. i intended to use a table for layout- this was before i ever made much use of css. icons would be their own images, and everything else would fit around them. adding icons would mean changing the table- once again, i had no desire to recreate the full functionality of program manager, only the simplest feature of opening programs.
i could have written a cgi script, run a server and monitored files created by the script to trigger files being opened with the correct user and permissions. i didnt go to all that trouble. instead, i added a certain filetype to be opened automatically by the browser when clicked, and had that filetype open a batch file, which started the program i wanted to open. so i configured a browser to open a file which opened a specific batch file, to open a program.
this was just to play around, and i was aware that if many people started using their browser this way, it could possbly be exploited to open programs on other peoples computers. i didnt want that for myself or other people, but i didnt intend to distribute this thing, just to make it and try it for fun.
ultimately i had my own program manager in the browser, and i could open a program by clicking on its icon, again, just for fun. the result looked exactly like program manager. this was a silly project- but it did exactly what i intended it to do, albeit in a way that wasnt worth doing routinely. it was not much of a project- it was more of a hack.
i freely admit to doing some things just to see if theyre possible- there are plenty of people who do that for the sake of mischief, and im neither condoning nor judging that in such broad terms. i didnt do it for mischief, i did it to amuse myself and occasionally learn something.
a more political example of this was when i made a simple programming language just to make a point- diogenes was a person who took issue with sloppy philosophy, and responding to a claim that a "man is a featherless biped", he reportedly plucked a chicken and presented it exclaiming: "behold, a man!"
for me personally, diogenes was a toy programming language that interpreted richard stallmans verbatim-copying-only essays into programs you could actually run on a computer- demonstrating that practically anything could potentially be source code.
stallman felt that proved nothing, but i wasnt trying to prove he was wrong, i was trying- and failed- to get him to look at the situation differently. he told me i was "playing a game" with him. yes, the game was called "see if you can make stallman think."
i dont believe that his "works of opinion" schtick is a reasonable distinction that justifies, let alone necessitates a no-derivatives clause. it has always irked me that he pushes such restrictions, when the attribution clause of the cc attribution-sharealike license can be used to demand disclosure of edits to source material- as in, "this version is edited from the work of the original author".
in other words, i think its better to allow derivative works and demand that changes be noted by secondary or later co-authors or makers of derivative works. and i stopped funding the fsf because i thought they did too much to attack free culture and misrepresent the arguments it made- disagreeing is one thing, but i didnt feel the disagreements were intellectually honest or fair. i thought they were petty nitpicks and solutions in search of a problem.
furthermore, i think of writing as software for the mind- it may not run 1:1 without further interpretation, but theres no law of the universe that says a computer cannot refuse to run code that fails to pass a check (software already does this) or that interprets code in any way other than black and white- some software does this already in its parsing of verbal commands, which i dont consider "code" but i think its not far-fetched to anticipate some languages interpreting things based on personalised context in the future.
im not necessarily in favour of such an approach, just that its not too far-fetched to imagine someone doing that.
but stallman obviously does not agree that his essays are source code, because they were not intended to be. personally, i think its something he should reconsider only because why should i be barred from making software that does EXACTLY what his essays do, when that software is only a simple and automatic translation of his written work?
this is not intended to be a simple question- i can easily imagine a more thorough rebuttal. what i did not get was a thoughtful reply, but a knee-jerk reaction. and i think thats a shame. but diogenes was also a hack- for the sake of illustrating a point.
with the example of the radio-based toys that worked but perhaps surprisingly, the easy program manager clone that worked but was sort of pointless, and the toy programming language that worked but was done mostly to illustrate a point, i hope to establish some sort of pattern that can be pointed to.
of course im a little proud of these hacks, but i think if they demonstrate any sort of cleverness they also illustrate limitations of skill- thats okay, its a point i actually prefer to and want to make here. sometimes you dont need a the full set of a particular skill to do something fun or useful and slightly unexpected.
brazilian culture has a concept called "jeitinho brasileiro" or "the little brazilian way", and the english speaking world has the well-established concept of "taking a shortcut". obviously taking too many shortcuts can get you lost, and some conventions exist for a good reason, but theres absolutely a time for being unconventional- or when its necessary.
i think computing is more fun with this option, than without it. one of the reasons i like openbsd is because it tries very hard to do things right, and there are situations where i absolutely respect that- rules are made to be broken, but many rules are not worth breaking all the time.
when it comes to security, some rules are important- i didnt think it was good to keep the program manager "replacement" set up, because of possible future exploits. but it was good fun and probably could have been improved in a way that made it less terrible from a security standpoint.
making the thing was the first step either way- otherwise, i might as well have done the same thing with python and sdl or something. but that would be more work, and i didnt really need a program manager clone.
the spirit of hacking i want to inspire here is in terms of real problem solving- but quick and dirty problem solving.
i didnt set out to remaster bootable isos with my own programming language, i actually just wanted to catalogue specific information- basically, specs- about countless different versions of puppy linux: included applications, versions of libraries that may be outdated or vulnerable, default window manager, dates of certain files- i set out to make a program that would open countless isos and then open the squashfs systems those isos contained, to get information which would be spit out into an html table so you could compare version after version after version.
and i hoped to get people to think about what really goes into a version of puppy linux, i wanted to be able to show what versions do and dont have in common- and what the conventions are. but i wanted to show it concretely, i didnt want anyone to take my word for it. i sort of wanted to "prove" that puppy was this way or that, at least conventionally.
and i wanted people to think about what they would change.
but it was a fair bit of work with zero direct payoff, it generated no real interest in the community and it immediately inspired a project that went in a different direction- now that my program was good at taking apart different sorts of isos, could i put those isos back together?
i would have never gone to the trouble of remastering isos with my own scripts if i had set out to do so. only through tinkering did i find myself with half or more of a remastering script.
so i started playing with distros i wanted to transform, there was a version of puppy that avoided all non-free software and drivers, and i wanted to update it using pieces of a new fully-free distro, but with the rest of puppy linux still intact. in other words, i wanted to make a script that could either update an existing iso or get as close as possible.
if that sounds like a sloppy way of updating an iso, it is- but nothing i hadnt seen people doing manually, and i wanted to automate the process.
what i got from this was a way of automating several distros from different families, even mixing them together. its always better to recompile everything if youre creating a new distro- but i didnt want to create new distros as much as PROTOTYPE new distros. i wanted to make proof-of-concept distros, and sometimes tinker and experiment or occasionally change something just to demonstrate a point.
one of the cool things about it was that you could distribute a script that was only a couple hundred kb, rather than a binary iso, and that script also constituted a full receipt of everything that was done TO the "source" iso. by "source" iso i mean the binary image of an already trusted public iso, not source code.
someone actually took my remaster scripts and made the isos and put them online. he was not a coder, but he managed to get the scripts to work. i would then check most of the iso (not the initrd though) using a program i made to compare every file including the contents of the sfs images.
i do want things that work well enough to show whats possible- but im not setting out to found big projects, but to demonstrate ideas using working examples.
the ideas i want these hacks to inspire in this chapter is nothing so complex as remastering bootable isos or mixing two distros together, but i want people to think more about how they can resist developers soft-"forcing" users to do things a certain way, and how users might thwart that by just insisting on doing something their own way instead. again, theres a good time to follow convention! and also a time to rebel.
in the past ive called this "software disobedience", arising from the shift in projects where things used to give users more options and suddenly new developers make changes and insist "users should do this instead". sometimes that advice is sound of course- sometimes a project makes a change for the sake of security- and they abandon the older, less secure way of what they were doing before.
i absolutely think thats justified sometimes. its also the perfect excuse to take users for a ride. im not advocating paranoia here, i actually think its good to consider the implications of a previous design in terms of security- and, i like to think that sometimes developers find they can improve on previous designs. im not against that, no matter how many times my ideas are painted that way.
but i do think if we are talking about software freedom, that users do not exist as pawns to carry out the plans of developers unquestioningly. they should have options, and preferably make informed decisions, which some developers are cynical enough to laugh at the thought of. i think thats terrible. i wish fewer such developers actually wrote software, i think we would be better off.
if users cant be trusted to make decisions for themselves, then the whole concept of free software is over. but i do see projects take that sort of line, such projects usually favour "vertical integration" as theo de raadt calls it- ive called it other things, and ive heard still other people refer to their own version of this idea.
whatever you call it, sometimes you can get rid of a big piece of software by finding a solution that just does the few things you want (or a small number of programs, even from different places that do what you want) and simplifying. sometimes a few tweaks are needed, or even a little program of some kind- just a small, new tool that serves as the missing piece of the puzzle.
the more people who are ready to do this sort of thing, the harder it will be for those promoting bigger, fancier solutions to drag people into corporate-funded projects that will effectively shut down competition, then walk away when everyone has switched.
the purpose of vendor lock-in isnt to make people use the same thing forever. its to drag people over to relying on developers who dont care about your freedom- whether the source code is freely licensed or not- so that when theyre done maintaining something you need, youll have to go to them for the next solution- and the next one, and so on.
when you can make your own choices, its not only harder to make people accept proprietary software, its harder to drag them into relying on monopolies.
it may seem a bit cart-before-the-horse to say "if you want more choices, make them"- rather, if you want to make more choices, consider taking a shortcut, just to avoid a path to lock-in by a large vendor with a long history of not caring what users want- only about their own goals for users.
even if its just a small protest, a small act of rebellion, it could start you on the path to thinking about how to solve bigger problems. and try to have fun with it, this stuff is supposed to be fun. we arent supposed to just give up and do what we are told to with our setups all the time, with no exceptions. freedom exists only as it is practiced.
being TOO conventional leads to kitchen-sink solutions, which are not sustainable- they will always be offered by groups that are forced to abandon what theyre doing, to drag users along from one swindle, to the next, to the next. being a little unconventional will help you avoid kitchen-sink solutions, and the consolidating, monopoly-creating effect that such solutions lead to. it will also help you cut out a lot of unwanted bloat, if your solutions generally make that a preferred goal.
license: 0-clause bsd
```
# 2019, 2020, 2021, 2022, 2023
#
# Permission to use, copy, modify, and/or distribute this software for any
# purpose with or without fee is hereby granted.
#
# THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
# WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
# ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
# OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
```
=> https://freesoftwareresistance.neocities.org