fig os: a less superficial fork, for less superficiality

fantastic entry from linuxmender today, check it out: https://linuxmender.wordpress.com/2016/09/08/forking-the-mirrored-efforts/

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: https://maxwellflitton.com/2016/09/02/should-i-a-clinician-honestly-learn-how-to-code/ 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 userscripts.org 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) https://archive.org/download/Puppy_Linux_Refractapup/mkfigos15.fig

and you can get the iso my friend ally uses it to create here: (750m) https://archive.org/download/Puppy_Linux_Refractapup/figos1.5.iso

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

 

 

 

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s