Article by figosdev

Summary: "The idea of the GNEW Project really is about keeping the goals of the GNU Project alive -- hopefully, they won't destroy or co-opt too much of the GNU Project, that people like the Hyperbola devs can't fix it with BSD."

This article is serious -- mostly. There's a slightly tongue-in-cheek exaggeration to it, just a little.

I've lived my life ignoring mostly the differences between "real programmers" and everybody else. To me, programming is telling the computer what to do -- it's getting the computer to do what you want. You could even say "If I install software, that's like programming -- because then the computer is doing what I want" -- sure.

When you want to do something the software can't do, then you go find other software that does it. This isn't entirely unlike trying to find a library that accomplishes the bulk of what your program needs to do. It's a bit glib and oversimplified, but there are similarities.

The nice thing about programming is how flexible it is. Software breaks, and programming bends software to your will. Sometimes this bending takes incredible effort -- other times it's ridiculously easy. I spent years looking for ways to make programming easy -- I researched dozens of BASIC dialects, looking for the "Basic" of the 21^st century. When I started learning Python, I gradually realised that I'd found it.

Yes, I've tried several modern dialects of Basic (and written one of my own) and I've ported my favourite language to the newer Python. But what Python 2 made easy, Python "best practices" now discourage. I think that's a shame. And I'll never convince the Python community, so I suppose it's nice that I'm happy with the tools I've got.

We live in an enormous forest of free software tools, where I've spent weeks or months talking about various ways in which our forest is being chopped down, being managed unsustainably, and being deliberately set fire to. We know who, why and we know how.

Roy is the optimist in all this, and I'm... not? Underestimating the problem is lethal for software projects. I've watched many get attacked, and those projects are never coming back.

But Roy is smarter than I am -- and I know, because he's happier. I know because he can work on code I don't have the patience for. I know because he works harder, not just smarter. And I know he knows more about what's going on -- because I've tried keeping up with him not for a week, not for a day, but just a few hours -- Roy is a freaking machine.

Stallman too -- coding in LISP, C and various other languages. I won't ever approach that. And honestly, I'll never try.

We are very, very lucky that people become sufficiently interested in coding in C, coding Bash scripts, writing mountains of LISP and can even write kernel modules and operating systems. I've dipped into those things just enough so it's not completely alien. Heck, I grew up with DOS and just missed the 8-bit era.

It's not like I don't lament that, or don't respect lower-level coders. It's just that anytime I could be playing with lower-level code, whether it's a Hello World program for the Linux kernel, or operating system code running in Qemu, I find other stuff to work on. I've always got something that needs to be done, and I really do enjoy finding and especially making tools that help.

I love the command line, I love the VT (with or without a framebuffer) and I do most of my coding in Leafpad, because I like things that open instantaneously and work very quickly. I don't like multi-tab editors, though even then I am very impressed by the design of Geany. I've tried Emacs and Vi. I've tried a few clones, as well.

I was honestly pretty happy with DOS. If FreeDOS was completely free (it needs a non-free compiler to compile some parts of it) and had good hardware support (never going to happen, except via emulators) I'd probably still be using it. I used Arachne to put an old 386 on the internet, with JPEG support and everything.

I totally appreciate these people creating virtual hard drives over network connections and getting their C64's online. That's slightly more sentimental and slightly less practical than what I try to do, but it's very cool. Just being able to do a quick search online on a C64 is pretty awesome. Of course I used dial-up BBS (9600bps modem -- I wasn't doing 56k until I was on the Web).

It wasn't until 2007 that I finally made the full migration to GNU/Linux, but I'd spent years working on that. I had to migrate my entire workflow, and while I looked for new tools, I had no intention of replacing everything at once. If I was happy with that idea, I might as well just let Windows keep pushing me around. After all, the people saying Windows is better are Real Genuine Microsoft Engineers, and I'm just a lowly user and tinkerer. How should I know if software is good or not?

I love the "Suckless" philosophy, but I'm sure that I don't follow it. I have fallen in love with dwm again, which I think Steve Litt tried to get a bunch of people into a few years ago -- it's from suckless.org, and I'm writing this in Leafpad with two term windows and two other leafpads tiled on the right.

I almost never resize my windows anymore. It's fantastic. But I do use ALT-h and ALT-l to change the work area size.

When a simple tool just works, I use it. When it gets too complex, I only use it under protest. My thing was refurbishing old computers that people like to throw out. It fights e-waste and it's fun. I was using it to promote Debian (with LXDE) but Debian got taken over by IBM, and LXDE got taken over by Microsoft. These guys just never quit. (Big Corporate: I don't LIKE you people, you know that, right?)

When I was a kid I loved Legos and other similar building toys, when I was dating a millionaire we both marveled at the girly Lego Friends sets -- as a long-time Lego fan I thought the design of them was truly impressive. I typically went for the space-themed sets and mechanical Legos, designing my own gearbox that would both accept and replace (in terms of width and the dimensions of one corner) the ungeared motor Lego provided. But we put together a big cruise ship and it had a dolphin -- this was wayyyyyyyy cooler than Barbie. Honestly, the real geniuses of the world work at Lego.

I like to put all my software together the same way. Debian (used to) let me do that, but it stopped supporting things in such a "universal" way, so I started looking for ways to compensate for that. I switched to Devuan, only to start remastering other distros.

I don't have the patience for manually moving loads of files around and creating snapshots -- I was only happy remastering if I could create a script that could be distributed instead of an ISO image. That way you could just modify the script, let it download a base ISO and make all the changes automatically, producing a new ISO from the original one. That's what I call "automated remastering". And I didn't invent it -- OLPC did the same thing to Ubuntu ISOs.

So if I like any version of Debian, or Puppy Linux, but I want something added or gone -- I just take the script, change some lines, run it and voila -- new ISO. But reproducible as well. (Not in the sense of reproducible binaries, but those are a very good idea).

My main concern at the moment is protesting the GitHub takeover of all free software -- including the GNU Project. So I want to remove as much GitHub-related stuff as I can. I've nearly got the new editor I need, thanks to tkinter (Tk gui library) and PyPy. I don't need lots of features -- I need to edit text.

Tk is the least GitHub-encumbered GUI library, of course they all need either zlib1g (GitHub) or libffi (GitHub) or both. The first one can probably be avoided by dropping png support. Tom's idea about mirroring things like zlib1g is a good idea. Then do Perl, because the GNU Project relies heavily on it. There should be a fork of Perl that Microsoft doesn't control.

I don't know when we are going to have a serious next-generation GNU project that cares about the Fifth Freedom (the freedom to NOT run the software -- or preserving the de facto idea of the modularity that made Free software possible, even if it now needs to be more explicit and de jure).

I've written several articles with the phrase "de facto" -- meaning it's what actually exists or happens, even if it's not a rule. But I have to look up "de jure", suspecting it of being the opposite. De jure means that it's a rule, even if that rule has nothing to do with reality. The whole idea of modularity needs to become a rule (within sane limits of course) but more than that we need it to become a reality again. Then people can go back to sticking their system together like Legos.

Not everybody wants to do that? Oh listen, I'm aware of this. But it's not just home computer setups that are becoming less modular -- this is also letting various people take over how GNU/Linux distros are put together. So whether you care about Legos or not, or just want to buy a toy cruise ship already put together, our ecosystem depends on software being in Lego form. Without that, we lose.

When I was in high school, I didn't get to do wood shop for an entire year like some lucky people. It was an elective, for only part of the year. I loved it, and I designed a simple box for holding about 60 CD's. I designed (and was required to first draw, on paper -- with measurements) beveled corners and whatever you call the the L-shaped place where the bottom of the box (made of four pieces of wood) nests in the lid. Maybe if I'd taken a year-long class, I'd know what it's called. It also had 4 or 5 evenly-spaced dowels as separators inside the box.

But the point is, it was designed to work exactly the way I wanted it to.

And that's how I like my software. I don't always take the time to polish and stain it, but I like it to work reliably (within the specs I need it for) and I like it to be simple and do exactly what I want.

Corporations don't always have time for that. Like Wayne Campbell said about Benjamin in Wayne's World, "It's like he wants us to be liked by everyone... Led Zepplin didn't worry if they were liked by everybody, they left that to the Bee Gees".

I like both -- mostly the Wyclef Jean version of Stayin' Alive, but definitely Zepplin a lot more -- but what I really want is for people to be in control of their computing. With wood, you can pretty much do what you like -- you absolutely MUST use power tools (and other tools) with proper safety precautions, because they can cut your freaking hand off. Though if you're careful enough, you can just take a big knife and whittle the wood you use into a table or a canoe, if it pleases you. I've tried clay as well. I like the slab method, naturally. It's like clay Legos!

If you make little command line tools or program routines, and eventually you make enough little command line tools or program routines, you might decide you want more control over how they're put together when you call them. A little program that reads text and calls subroutines or outputs different text is just one more little Lego, and -- oh, you've created a small programming language or command shell.

Of course it used to be more difficult. With all the programming language Microsoft has currently tried to take control of (Python, Perl, most of the Javascript ecosystem) some are bound to either avoid them or get loose again. I'm using PyPy, you may prefer something else. I worked on a language in pure Javascript, but that's not my favourite language and I only spent a month on it. I started out small and got much farther than I planned in a month. And I documented a lot of the process.

This isn't about my own tools more than woodshop is about tables and chairs -- it's about making wood into things you want, and having the freedom and the ability to make things that fit you in a bespoke way -- even if you don't have the skills, training or experience of a professional tailor or woodworker.

I have no formal training in programming -- none. I took a high-school class in Basic, which I'd already coded in for years -- but switching to Python taught me more than that. When I designed my own language, I made certain it had some of the features that made Python a great learning opportunity for me. And I kept the list of features below 100.

The best way to keep stuff modular, is that once your program tool reaches a certain level of sophistication -- you stop, and make something else. That sophistication can be very low, if it does what you need. If you need something else -- make something else. If you need a tool that ties several tools together -- make one, or find one, or adapt an existing one.

Right now, I'm running more commands lately from an editor. Yes, you can do that in Emacs. I tried Emacs. You know what I don't like about Emacs? It's a wayyyyyyyy more complicated thing that what I need. That's not a diss -- Emacs is incredible! It's just not what I need. I want something more like Leafpad, but you can take the text on the line you're on and just run it -- just like that. And the output gets typed in right under that line.

You know how many lines of code that takes? Depending on what you modify to get it, it takes about 5 lines of code. Maybe you spend an afternoon on that 5 lines, but now you have a simple text editor that can run shell code (or if you already have you own programming language, you can make it parse that as well).

Sure, there are IDEs that do this. And they're far more complex and have far more dependencies -- and many of those dependencies are not being maintained by people or groups who care what I want or need, so maybe they'll drop my favourite feature and tell me if I don't like it, too freaking bad. You know like those Debian jerks. I remember when Microsoft used to treat me that way. And now free software devs do too. Like Officer Koharski said after Wayne's show was co-opted so it could be sold off to Noah Vanderhoff:

"It's a damned shame what they did to your show! Nice little... programme. Not that I ever watched it."

It's a damned shame, Debian.

So this is me rebelling and making more tools of my own.

Don't I understand that when you make programs for a much larger group of people, they get more complex? Of course. That's why grep is often faster when you use it on 30 GB of files (ask me how I know this) and why it has a larger number of useful features, which somebody uses (and I don't blame them for that).

But you know what? I've used grep for more than a decade, and there's one thing that either it's not very good at, or I'm not very good at using it for that. Either way, I wanted a way to get EXACTLY what I wanted out of one particular feature of grep, and the easiest way for me to do that was make a small tool for it.

So I spent about 30-45 minutes writing it, and a total of 75 minutes writing and debugging it. I don't code in Python as much as I used to, but I am getting an increasing amount of use out of PyPy, so I've spent a fair amount of time this week coding in Python (via PyPy) itself.

I was ready to code in something else instead, so I used my (own) favourite language, which compiles to PyPy-compatible code. It's not (quite) 60 lines. The wc command says it's barely over 1K of text (1108 bytes). It compiles to 14K of Python, of course (but then that's solid gold!)

And what does it do? Something you can do to some extent with grep and xargs, or even with find and -exec, but I use those all the time and believe me, there are plenty of times those do almost -- but not exactly what I want. I've spent more time trying to get Bash to do exactly what I want it to than it took to write this.

So it takes input from the find command:

find | sgrep

And now you can put anything you want to restrict the list -- yes, I do that with find -exec and xargs sometimes as well. Now you can put tokens to search for after the command:

find | sgrep find these words

We aren't looking for filenames that have these words, I've already got a highlighter program that lets you give its several things to look for (and highlights in several foreground and background colours, or just yellow I think, if you don't specify. The grep command does red usually) and I like to keep syntax LEAN! You can do that with simple programs. Is syntax all bad? Of course not. Is it always necessary? Not really.

So sgrep takes the file list from stdin (from find) and then it takes tokens to look for as command switches. And it searches every file, and adds a newline when it goes to the next file. It puts the filename and the line of text it found:

/mnt/extdr/arc/highlight.py:print "words found"

And that's all it does. It doesn't do highlighting, as I've already got a nice highlighter program and I'm not too proud to pipe to egrep --color either. But there is one other nice feature:

find | sgrep 5000 find these words

Will only bother searching files 5000 bytes or smaller. If the first token is a number, it's a size limiter.

Right? While the existing tools don't LIKE to do exactly what I wanted, despite my very best efforts, this does. And seriously -- I've gone to more trouble to bolt together find or xargs and grep for this task, often to unpredictable results -- than it took to write this. Maybe it's not the tools, maybe it's the user -- that's alright, this is a tool for me. It's a LOT easier to explain, too. When I was first learning the shell... heck, I have my own programming language, and the syntax for find -exec still throws me. I typically get it on the third try.

So then I'm probably never going to code in Perl, eh?

But this experience without formal training, and you know the code I wrote is fugly as heck. The variables are the worst part. The rest of it simply works the way the language is designed. You could make a much tighter version of it in Python. But you didn't. (Or maybe you did). Either way, you certainly could.

And that's the real point here. Not to try to make something that is so complex it takes years of dedication. My programming language is just 5 years old. It's inspired by both Basic and Logo, so the syntax is incredibly simple. It keeps parameter counts low, and typically fixed -- it's extensible with inline Python, and has fewer than 100 commands.

So what if it needs Python to compile and run it? Actually, it works quite nicely in PyPy, so I think that's a victory for simple design. I keep waiting for a PyPy fan to complain that I underestimate how compatible it is. Great! So it's even more awesome than I realised then.

But suppose you have a program shop like mine (I can't afford a wood shop). You make very simple tools that do nice things for you, but nobody is going to put this in Debian -- and I don't figure Debian needs it anyway. In a few years, they'll probably just dump something else I need, and I'll have to automatically remix it to put it back (I automatically remastered Debian Live to put sysvinit back in the Live ISO, but obviously there's more to being systemd-free than that...) And they're very uppity about it. Like "Who dares to want software supported by the Great and Powerful Oz?"

I know it wasn't always like that, and I know it still isn't always like that. But I also know what really goes on over there, and it's bad.

Not every distro is so self-important. Mx for example, is (usually...) loads more chill than that. Now that's a hobbyist distro. But they're also developed on GitHub (Ugh!) and they just decided the Geoclue was a great dependency to have, as Debian pretends to have deps they have (yet don't have) due to installing so-called "recommends" as a matter of policy. Of course you can turn those off... (But I haven't checked recently).

With the GNU Project forest on fire, and GitHub crop spraying gasoline over it, how will we rebuild?

Mostly I think we will move to BSD. And honestly, that's alright. But I think for people who are interested in these things but aren't going to commit to the strictest corporate-like processes, we should have our own project to rebel, to do R&D, and just to you know -- learn more about software and have fun. So we can call it the GNEW Project -- just for a laugh, and just to keep the idea of GNU philosophy alive.

Mostly it's to have some tools as a backup for when GitHub and the (minority of) GNU developers decide it's time to break more of what we rely on. We can at least preserve some parts of our workflow. This idea is sort of like what the VUAs did with DeVUAn, except:

1. We aren't pretending to be sysadmins 2. It isn't about a single distribution 3. No real specific goal, except learning, having fun and creating (sometimes useful) software 4. I'm not really interested in promoting non-free software.

This isn't a real project at all. It's an idea, and you can do whatever you like with it.

But the idea of the GNEW Project really is about keeping the goals of the GNU Project alive -- hopefully, they won't destroy or co-opt too much of the GNU Project, that people like the Hyperbola devs can't fix it with BSD. (Honestly, I have some faith in them. Though if it turns out they can't do it, someone else probably can).

It needs a recursive acronym, naturally. The best I could come up with in 30 seconds was:

"GNEW's Not Ever Windows"

Seems like as good a place to start as any. I guess the biggest problem is that while GNU is actually very Unixy, (it used to be moreso) "Windowsy" is not necessarily something we ever want. So maybe you can start by coming up with a better acronym.

"GNEW's Not Evil, Wingo."

Well, you try it.

What we do want, is more GNU. Or GNEW, because it takes seedlings to replant a forest.

Richard Stallman is a bit like the Lorax of software freedom. Free software started after software freedom, once abundant, started to dwindle as the truffula trees were no longer free -- they all became products, which EVERYONE NEEDS!

You're in charge of the last of the free software seeds Digital freedom's what everyone needs! Plant a GNEW project. Treat it with care. Write some instructions, for using software.

Grow a forest. Protect it from silos that trap. Then the GNU, and all of its freedom, comes back. ⬆

    # sgrep 2020 mn ## license: creative commons cc0 1.0 (public domain) 
    function pathsize p
    python
    import os
    try: return os.path.getsize(p)
    except: return -1
    fig
    fig
    filelist arrstdin
    c command
    limit -1
    clen c len
    ifmore clen 1
        try
            vc c mid 1 1 val
            ifmore vc 0
                now clen minus 1
                c right now
                limit vc  
                fig
        except
            p
            fig
        fig
    forin each filelist
    found 0
    s pathsize each
    ifequal limit -1
        ifmore s -1
            s -2
            fig
    else
        now s minus 1 swap now s
        fig
    ifless s limit 
        try
            openf arropen each
        except
            openf "" arr
            fig
        forin eachline openf
            forin qe c
                iftrue eachline
                    textfind instr eachline qe
                    iftrue textfind
                        now each prints ": " prints get eachline print
                        found 1
                        break
                        fig
                    fig
                next
            next
        fig
    iftrue found
        now "" print
        found 0
        fig
    next

Licence: Creative Commons CC0 1.0 (public domain)

(Except for the small but shameless ripoffs of famous fictional works from LorneCO and Dr. Suess)

IMPORTANT NOTE: I DON'T think we would be better off if the entire GNU Project was permissively-licensed. But even the GNU Project recommends copyleft for programs with "300 lines" of code or more.