fig os: a less superficial fork, for less superficiality

fantastic entry from linuxmender today, check it out:

it has the advantages of being shorter and much more to the point than the following (hopefully interesting) ramble:

but boy do i have a lot to say about this subject– im not sure where to start.

my favorite part of the post from andy mender is how do we get past the superficial, and get into the technical justifications for forking?

i would broaden this question to apply to much more than forking. how do we get computing to be more technical and less superficial? i will get back to the matter of forking, but i want to explore this bigger picture and why i think its important.

western society is now so permeated with technology in almost everything that we do that not having a firm enough grasp on how this stuff really works (and i mean the concepts, not the schematics of the ics) is a detriment to the individual, and society.

if you dont understand technology, you are increasingly helpless. the good news is, that people are managing to operate increasingly sophisticated machinery. the bad news is, that people still dont understand this machinery and the sophistication obscures functionality that (for its legal and philosophical and society-impacting implications) we really need to get some kind of handle on.

the out-of-the-box solution is “more training,” but this is almost like being told what to think and do instead of having real choices.

in other words, it isnt just the user thats becoming more superficial. its the choices themselves. we are designing a more superficial world, and we need to stop doing it like that.

but thats all very pie-in-the-sky. all these endless (thank you all) topics about “learning to code” are absolutely as vital as people say. yet as fellow wp blogger maxwell flitton points out: its not necessarily wise to assume that learning to code will advance your career in a non-it industry any more than learning to set up microphones will advance you as a singer.

as someone constantly trying to convince people that they should learn to code, i think the metaphor is a fair one. i do think learning to code will teach people things they need to understand to survive and thrive in the 21st century– whether it helps your non-it career or not? i dont really know.

but i do believe that computer literacy (not just computer “training”) is vital to the 21st century citizen, and that the shortest, easiest route to such literacy is learning code.

for that reason, i think we need a variety of languages with different strengths and levels of difficulty. its not that we should make that our priority in design– i think we simply need more languages to choose from. i think we need a lot more people designing computer languages, and i think we need livelier debates about what features are vital to a language for a particular purpose.

perhaps the best word here is not “computer languages” and instead is “document specifications.” because for every industry standard like javascript (ok, ecmascript) and every mainstream tool like bash or zsh, there are various document formats, makefiles, ini files, schemas.

its all very (very) much like code, and while im not fluent in .gtkrc or whatever opaque nonsense gnome is using these days, i know enough to get myself into trouble– and thats a good start.

the worst thing that could happen to a technological society is that everyone would be afraid of tinkering because it might “break” something. i think there is a place for great care and strong typing– i think languages like ada are some of the best things weve ever designed. it would be nice if more critical systems ran on stricter setups, but top security and best practices are worthless to people that are afraid to type in commands.

when i was a small child, we got our first “modern” pc. not your typical 8-bit beauty, in a world around the corner from 16 bit data lines we still typed single words to start programs.

no matter how much you want to make fun of it, its a special magic when a few words make all these things happen. and whats the big deal anyway? why not make it an icon?

the thing is, you can only have so many icons. but words are like lego bricks: simple pieces that even in small numbers can be combined in ways that multiply far beyond simple intuition.

you can of course, bypass the direct need for typing or learning languages by having drag and drop pieces– by taking the lego metaphor more literally, and using more graphics.

this has wonderful uses for a younger or less educated crowd, and i never want to dismiss it entirely. but its still a way of running from something fundamentally useful to computing– not just the command line, but text and code.

to make any aspect of computing less superficial, we simply add words. as beautifully as words and pictures coexist, the superficiality of computing is rooted in pictures. rather than run away from graphics, we need to run right back to code. we also cant do this (except as an inside joke) without making more ways for everyone to code. believe me, no matter how much i love fig, it is still an example of what i think we need– the world doesnt need to run on fig any more than the linux kernel needs to be written in basic. but i firmly believe we need more languages for more people, as funny as that sounds.

to get back to the topic of making less superficial forks, i started a project several weeks ago, which had a non-superficial, but also not-very-serious goal:

it wasnt to fork debian. it wasnt to add wallpaper and icons (although thats definitely part of it! because thats practice.) it was to figure out if you could update an “aging” version of puppy linux by automatically remastering it with another more “mature” distro.

about a decade ago, i learned a lot about gnu/linux from using puppy. it was my fun and friendly introduction, and eventually i became skilled enough to want something a little closer to debian. the transition went through quite a few steps. ive always liked lightweight live distributions, and also lots of package options.

theres not a lot you can say against puppy that you couldnt say a decade ago. if anything has changed at all, its a more serious project now than it was then. but could you make it serious enough for a debian user, and still have it be puppy?

probably not. and still there are projects to “puppify” debian (or devuan) and debianize (or devuanize) puppy. since all of those are too tedious for me to spend time on, i decided to go about it this way:

1. download 2 isos: librepup and refracta (devuan)

2. mount the isos and the key squashfs files

3. copy and sometimes even download selected files to update each system

4. combine the two systems into a hybrid distro (hybrid as in two distros in one, and also as in the tool that makes it dd-able to usb) with two modes: “puppy mode” and “refracta mode.”

puppy mode has updates and features from refracta (not all of them, whatsoever.) and fig os is the only devuan derivative ive ever known to natively open and install .pet packages from puppy linux. you can apt-get install in refracta mode (and you probably should) but i do prefer .pet packages to ubuntu ppa, and if fig os becomes wildly popular (it started as a proof of concept, so i have yet to be so ambitious) you could create .pet packages for both modes at the same time.

ive learned far more about live distros from this little experiment than i ever dreamed i would bother to learn. whats more, i dont have to install and configure icewm anymore, because its the default in my own little distro.

now, the whole point was to get away from the superficiality of forks, right?

well… fig os is nothing more than a script written in fig, compiled to python, and its 50% bash anyway.

it upgrades pam, it upgrades 575 binaries just by copying from refracta– and then it fixes some of what that breaks, as hundreds of lines scroll down the screen of a 5-year-old pc (running fig os, though mkfigos works in puppy too) in only a few seconds.

resquashing the folders to put the iso together takes at least 10 minutes. but this is not a manual remaster– this is a fully automated script you can change. you could put more options at the top (fig imo, is much better for this than pure bash) or you could do a search for icewm and simply remove (or edit) the lines that replace the default window manager.

this “automation” was inspired by devuan, which has to do more to automate their building than debian can even switch to doing at this time. (ubuntu does at least slightly more automation of development than debian.)

mkfigos is in the public domain– i dont think everyone should have to learn how to create such a script. i was impressed at what did for hobbyists that wanted browser extensions without learning how to create more than javascript.

id like there to be a similar (hopefully longer-lived) ecosystem of scripts to modify distros or even .isos, so that instead of true forks, many of us could just automate the editing and rebuilding of existing distros.

right now, thats my favorite reason to code. but its just one more thing you can do with a basic-inspired language, designed for education, which compiles to a powerful all-purpose scripting language like python– with a shell feature to run bash commands in gnu/linux.

and thats a pairing of two ideas that i consider important: giving users more control over their favorite distribution, and getting more people to learn a friendly language so everyone can understand code… for whatever reason it serves them.

you can download the latest version of mkfigos here: (52k)

and you can get the iso my friend ally uses it to create here: (750m)

and while i was writing this, it looks like maxwell flitton has just written a sequel to the post i mentioned here. so heres the title, as a link: tips for clinicians who want to commit to learning code




this is what happens when you make coding elitist

people are declaring themselves “NON-PROGRAMMERS” while programming a computer:

I am writing in bash and gtkdialog.

theres a word for writing (code) in bash and gtkdialog. but weve overloaded its meaning so many times over– resulting in the simple misunderstanding that so many things arent “really programming.”

its ok– you dont have to label yourself anything you dont want to. but if youre working with code, thats the thing– youre really quibbling if you want to talk about non-programmers that program.

elitism is only partly to blame. i take responsibility for my part, talking about “languages and introductions for non-coders.” but that means “for people that arent working with code yet; people that havent tried it before, or people that gave up quickly.”

if youre in training, youre coding. and most “programmers” are always in training anyway. people are still more concerned whether they qualify or not, the end result of which is people arguing with me when i say “everyone should learn to code” that “i dont ever want to learn to code! im happy writing and editing bash scripts.”

this has actually happened several times, despite the fact that some programming languages are easier to learn than bash. bash scripts do provide endless examples and let you learn-as-you-go, so if you dont run windows theyre still a good way to learn: bash is “learnable.”

but what theyre saying isnt that far from: “i dont ever want to learn to drive, i only deliver pizzas in my car.” in the future a new metaphor will be required, but for now its just as silly.

in case im not clear, using the command line (depending how you use it) may or may not be “coding” per se. theres some gray area. but at a certain point it definitely is coding, and the line between the two is a thin one. in other words, if youre comfortable with (or need, or are using for whatever reason) the command line, youre close to coding or “programming” already.

what is “scripting?” its a kind of programming. arguably lesser perhaps, but the line between “scripting” and “programming” is artificial, was always quibbling, and gets smaller every day as scripting languages get more powerful.

can you program without the command line? yes. can you use the command line without programming? yes. but theyre still related, and people are putting a very strange amount of effort into separating things that go together pretty naturally and easily. you can if you want to, but really, why?

ive only found one good reason for this much effort to distinguish the two, other than the need to quibble. by saying “im not a programmer” you shield yourself from the endless critiques of know-it-all coders constantly telling you to do it a better way (sometimes helpful, often used as a bludgeon or critique, and often arbitrary and useless– personally i find it annoying and practically useless when people tell me dont put “cat file” in front of a pipeline.)

but since this sort of nit-picking happens at least as often in bash as any other language– it doesnt really work. either way it brings me back to how elitism is robbing people of the chance to realize theyre programming. thats a very needless shame. i was lucky enough to teach myself how to code– i doubt i would have continued to enjoy it for 30 years if id had that nonsense to contend with every step of the way.



fig os 1.4 updates over 500 binaries in librepup


fig os 1.4 replaces 575 binaries in librepup with ones from refracta; so if youre using librepup and you run busybox, it will tell you the version is:

BusyBox v1.22.1 (Debian 1:1.22.0-9+deb8u1)

bash is updated to version 4.3.30(1)-release, and the “connect” icon is fixed (all the other desktop icons worked.)

fig os in default “puppy mode” includes jwm and pcmanfm desktop, while typing “live” at the boot prompt boots into “refracta mode” which gives you devuan with icewm and pcmanfm desktop. the iso is 750mb and available here: …if you have fig and wish to remaster fig os yourself, you can get the script here: