Article by figosdev

Summary: "...I don’t want to help them help Microsoft control my computing by proxy — by controlling the development platform itself"

For those of you who started complaining about this in late 2019, well done. You get the credit for early warning.

The name "Harfbuzz" is based on a translation of the phrase "OpenFont". Its lead author is Behdad Esfahbod, who is also the lead dev of Pango -- the GNOME thingy that (typically) makes text happen. I don't know (or very much care) about the finer details about that, I know that my Gtk applications refuse to run without it.

GNOME is not directly a Microsoft hostage, even though lots of its people have sold us out over the years. Many people have betrayed both Free software and rms, but the only person rms ever called a "traitor" was GNOME co-founder Miguel de Icaza. He should have simply called GNOME traitors instead -- a better warning to the rest of us.

But in fairness, most GUI toolkits require libffi and/or zlib1g, and both of those are hostages of Microsoft GitHub.

Both GNOME and KDE require Harfbuzz as well, and as of last year it looks like Esfahbod (or someone close to them) worked to make Pango -- which is not a GitHub hostage -- require Harfbuzz, which is.

Even people at Phoronix thought this sucked. Bitmap fonts -- those were an option. Harfbuzz, that was also relatively optional. Remember when Free software was modular, and things like this were typically optional? Yeah, less and less so all the time.

So while I am aware that GNOME is not the only problem here, this makes even firmer my resolve to rid myself of GTK where I can.

It is nearly impossible to boycott GitHub without boycotting Free software (GNU/Linux at least) -- I recommend people try anyway, and it didn't take long for people to ask me if I was boycotting my own.

The answer to that is "Yes". Sometimes, at least.

For example, my three favourite languages (all related) are fig, figplus and Python. For Python I have mostly switched to PyPy, and I basically (can't think of an exception) do not develop Python-based software that will not work in PyPy. For fig 5, I switched to PyPy for the default.

Figplus still uses Python (it will work with PyPy however) and it will work with Pygame if you install that. Note that if Pygame is not installed, it will just try to use text "graphics" instead.

For fig I actually removed Pygame and added support for full colour text. Figplus has a few other extra features, but I am largely boycotting it (not 100%, but I definitely avoid it regularly) in favour of relatively GitHub-free fig.

I have removed leafpad (GitHub, Gtk) and now lean towards Tkinter-based editors. On this machine (where I typed this article as well as my recent book) I have not used xterm in a while.

There are certainly things I need xterm (or something like it) for, such as doing "graphics" in fig 5.0. But for most command line tasks, I am using a text editor. For example, if I want to know how much free space there is on the drive:

    df -h | grep sd

I type that line and hit CTRL-T, then it gives me the output of the command. Errors are ignored (I could fix that, I haven't) though I can say "df -h 2> log | grep sd"

Then cat the log.

One of my favourite tools is gdmap, though it needs Harfbuzz and Gtk so I am eager to come up with a simple, homemade-quality replacement.

I can do a GUI app, but I'm always loath to because they're really kind of a pain to make in my opinion. I do like CGI, old-fashioned though it is. Everyone uses frameworks now.

Gdmap creates a treemap that shows grouping (by folder) and (relative) sizes of files, giving you a really great idea of what stuff takes up the greatest amount of space on your system. I used screencaps of it on this page.

I could just look up that project to create a treemap of folders in Tkinter -- I wasn't thrilled with it, but it does what it claims. MY thoughts on a simple tool to create an "overview" like Gdmap while accepting many imperfections (favouring simplicity) goes like this:

* Use find and/or du -k and/or PyPy to get the filesizes for every file

* Get the int of the SQRT of the filesize as a variable

* Create a div of that integer (height/width, square) in whatever background colour is associate with the file extension (Gdmap lets you configure that)

* Use float:left or float:right CSS (try both) to make it so as many squares fit together as possible. This will probably be really lame and result in single rows where we want several.

But up to a certain size filesystem, this would probably be better than nothing. For the moment, I'm using this:

    for p in $(find / -type d) ; do echo $(find "$p" |
    egrep -v "\.html" | 
    wc -l) " " $(/mnt/sda1/usr/bin/du -k "$p" --exclude="*.html" | 
    tail -1) ; done | sort -n 

What this does is create a list of all folders in /, which it then lists with first the COUNT of files under each folder, followed by the total SIZE of the files under each folder, sorted by count. Excluding certain filetypes is optional; you can also exclude more than one.

If you page up through this list (I use a text editor, you could also use "more" while possibly reversing the list) you will find the file count gradually and smoothly lowers, while the size also tends to lower but occasionally jumps back up.

The places where you notice the total size "jump" are the places where the "big" files are. So graphics, sound, video, very large program binaries -- those will cause such jumps in size relative to file count.

You can go through thousands of folders in a few minutes and find where the largest files are. You can do this with "du -k / | sort -n" as well, but now you have tens or hundreds of thousands of files to process, rather than folders.

Gdmap will not show you all of your smallest files, what it does best is show you where the biggest files (and biggest groups of big files) are. This will do that as well.

I can think of various ways to display this information, I've played with graphics for more than 25 years, but sometimes I'm trying to get a task done rather than create something that's very attractive.

My priority here is boycotting software that I can manage without. Gdmap was always good to me, though Gtk was always a liability. "No" is about the only currency we have against this takeover, and if effort isn't sometimes made then progress isn't either.

As for Behdad Esfahbod, the funny thing is that they (I'm happy to use "they/them" as preferred pronouns, I've never had a problem using singular "they" at all) do not approve of Microsoft's practices, which they consider unfair -- they even tweeted Satya Nadella to complain.

So it's funny then, when someone who (unless I read this wrong) worked at Google, Red Hat AND Facebook -- that's one HALF of GIAFAM, has a problem with Microsoft over monopoly abuse.

Hello... the rest of GIAFAM isn't exactly working for our freedom either. I don't deny that Microsoft is among the worst on the list.

Considering that they are forcing GNOME closer to Microsoft GitHub, the truth is that Esfahbod has worked for TWO THIRDS of GIAFAM -- including Microsoft, for whom they develop.

I may not be able to remove Gtk from my system, though I can minimise my use of Gtk applications -- and that helps to boycott GNOME (which is evil and toxic, Open Source and anti-freedom) and Microsoft Harfbuzz at the same time.

I hope they #deletegithub rather than continue to help out a company they claim to dislike. I know I'm putting in a great deal of effort to avoid this garbage, but nobody (certainly not the president of the FSF, who was a Microsoft GNUStep developer) cares if they're helping Microsoft control my computing or not.

But I don't want to help them help Microsoft control my computing by proxy -- by controlling the development platform itself. That can't be how the FSF intends to spend your donations "fighting" for your freedom -- by putting a monopoly in charge of it?

If this isn't a parallel universe to the one with the FSF I thought I knew, YOU explain how this happened.

Long live rms, and happy software boycotting. ⬆

Licence: Creative Commons CC0 1.0 (public domain)