Just ignore GNOME

Posted on July 4, 2025 by antisol

Dear Application Developers

You need to start ignoring GNOME, and GTK.

It’s an unfortunate situation. Made even more unfortunate because I and people like me were complacent – I didn’t try to do anything to stop them at any point. I simply switched away from GNOME in 2011. I was naieve enough to think that just not using GNOME was enough, and that we could all let GNOME do their thing and make a horrible, user-hostile desktop environment with all their shiny and horrible new UI paradigms, and everybody would be happy.

But I was wrong. I was very wrong.

See, GTK is a very commonly used GUI widget toolkit used for building software – software that isn’t only part of gnome. And GTK is controlled by the gnome people.

And, as I established in ~2011 and have repeatedly been proven right about, the gnome people don’t give a fuck what you want. They know better than you do about UI and UX, you see, and their spiky-haired youths all had a meeting sometime around 2010, and decided that what they wanted was for UIs to be terrible.

It started with the abomination that was gnome 3, which was basically a reaction to smartphones becoming a thing. Suddenly, the gnome people said “Hey, if we make the desktop UX a million times worse, we can perhaps make a mobile experience that’s marginally tolerable, and then you can have the same software run in both places!”

Of course, like everybody else who has tried this, they failed. Because desktop and mobile devices fundamentally different UI experiences: Desktops have large, good screens with lots of real estate, and actual usable, precise input devices, whereas mobiles have postage-stamp-sized touchscreens, and no mechanism for precise input (though apple has started innovating and adding physical buttons to their devices, so maybe in another couple of decades we’ll see a revolutionary new device with both a touchscreen and a keyboard, wouldn’t that be grand?).

There have been some valiant attempts over the years to unify desktop and mobile. Some more laughable *cough*ubuntu phone*cough* than others. I’ve looked at quite a few of the offerings over the years, and if I had to put my money on someone who’s doing it the correct way, I’d put my money on Enlightenment and EFL. Their UI acknowledges the differences between mobile and desktop, rather than trying to ignore them, and unlike other projects like gnome, it respects user preferences and tries to do what’s appropriate for the device you’re running on.

This is in stark contrast to the gnome approach, which is: pretend everything is a mobile device in defiance of user preference, destroying the desktop user experience, while making a mobile experience that simply doesn’t stack up next to UIs which are genuinely designed for mobile.

Gnome’s hostility to users started a long long time ago, and it hasn’t changed to this day. If anything it’s gotten worse. It’s always sad to see these organisations who fuck up their software, and then rather than admitting they’ve fucked up, double down and continue on the same route (Oh Hi, Mozilla!).

And when this was just limited to gnome3 being a piece of shit, that was fine. But now they’ve started mandating it in their UI toolkit. Now they’re working towards making it impossible to use GTK to make software with a good UI.

It started around the time of gnome 3, when they decided that scrollbars were a bad thing, and they implemented the “hidden scrollbar” paradigm, where you can’t see scrollbars on scrollable windows until you move your mouse to the side/bottom of the window, then the scrollbar pops into existence. This was not at all all fine and good, because apparently nobody working on imposing this revolutionary new interface on everybody ever bothered to actually, you know, try using it. I think my favourite bug created by this is the issue – which still persists now, over a decade later, where it’s now very difficult to select the final item in a list, because hovering your mouse over about 80% of that list item’s vertical area will cause a horizontal scrollbar to pop into existence. But I didn’t want to scroll, I wanted to select the last item in the list. And now I can’t, unless I very precisely hover my mouse over a 3-pixel area where the scrollbar won’t activate. How I’m supposed to do this on mobile with no precise pointing device is left as an exercise for the imagination (in large part because nobody ever built a mobile operating system or device which uses GTK*, because you wouldn’t – instead you’d use a toolkit designed for mobile, so that the UX isn’t shit).

(* OK, fine, this is hyperbole – there have been operating systems intended for mobile devices which used GTK. I tried out a bunch of them on my Pinephone Pro a couple of years ago. They were uniformly terrible. Here’s a video I made demonstrating exactly how well that went. Note the near 10-second lag between pressing “play” and music actually starting. For comparison, I was playing MP3s with excellent quality and no skipping or input lag with an interface that I consider superior in every way on a pentium 90 in about 1997, and the MP3 player PC I built into my car around 2000 or 2001 took somewhere around 15-20 seconds to boot into the OS from power-on and start playing music)

It continued when they decided to break the windowing paradigm by treating this “client side decorations” nonsense as a legitimate way to do a UI. Which is IS NOT. It’s broken in so many ways. I think the biggest and simplest flaw to point out with this is the way that now when your application is hanging, you can’t just click on the “X” close button to kill it. Because now that close button is drawn by the application, not the window manager. And the same goes for trying to move, resize, or shade your window.

The stupidest thing about all that is that they have to support both mechanisms, because you can still signal to the window manager “hey i want to close/minimise/maximise/resize this window”, because you still need to be able to do that stuff by right-clicking on a task bar. So now they have the same logic in BOTH the window manager AND the application.

Client side decorations were created by the devil. If you like them, you are wrong. They fundamentally break how the windowing system is supposed to work by breaking the separation of concerns between what is managed by the application and what is managed by the window manager: The window manager is supposed to be in charge of windows, and how they’re – you know – managed. Not the application. This is all stuff that was thought through and decided on back in the 90s, or earlier, by people way smarter than you or me or especially anybody who has ever worked on gnome.

When you have client-side decorations, what you’re really doing is taking on the job of the window manager in your application. Where it doesn’t belong. And this has several consequences, as outlined previously there’s the issue of now your close button doesn’t work when your application is hanging. But you’ll also see fun bugs with window movement, where the window doesn’t draw itself properly while being moved. Not to mention that now you’ve got a different title bar theme to every other application the user uses, and that when you’re drawing your client side decorations there’s no way to do that in a way that’s backwards compatible with decades worth of themes.

“oh but the window titlebar represents a huge amount of unused screen real estate!” I hear you chorus, as if you need all 1080+ pixels of vertical resolution to get anything done, despite that fact that we once upon a time 268 vertical pixels was called “high resolution”:
Amiga 600 'Screenmode' program, calling 674x268 'High-res'

Client side decorations break another very fundamental piece of UI design, which is that the user expects window management functions to be in the titlebar, and application-specific functions to be inside the application’s interface. These are not the same thing, and they shouldn’t be. This has been a convention for about forty years at this point – you’re fighting 40 years of muscle memory every time you place a hamburger menu inside a titlebar. I don’t look in an application’s titlebar for its menu, and I never will, because that’s fundamentally not where it’s supposed to be. Further, when you clutter your application’s titlebar with controls, it becomes more difficult to move the window around, because now half of the titlebar which I would normally use to move a window is filled with buttons.

But, look, I’ll be charitable, and I’ll concede that sometimes, in some rare cases, it might be appropriate to add a custom, application-specific button to the titlebar. I’ll even concede that some people might want to have a silly hamburger menu in their titlebars, and these people should ~~be sterilised for the good of humanity~~ totally be allowed to do that if they’re sure that’s what they want. In those cases, here’s how this should work: your application should send a message to the window manager, saying “hey add a button/menu/whatever to the titlebar with this label, and send me this signal when it’s pressed”.

Yes, this will involve working with the people who make window managers, and coming up with a standard for how to do this. You’ll need to standardise on what control types are allowed in the title bar, for example – you won’t just be able to place arbitrary widgets there. Ideally this should become a new ICCCM or EWMH type standard which many window managers could adopt.

But Noooooooooooooooooo, the gnome people decided to go a different route: essentially do away with the concept of window managers, instead letting the toolkit and application do a bunch of the window manager’s job. This is terrible design, and fundamentally breaks a bunch of stuff.

(Incidentally, check out this list of ICCCM-compatible window managers. Notice how metacity (gnome 2) is on the list but not mutter (gnome 3)? That’s because gnome have decided that they don’t give a fuck about established standards – they’ll do what they want, and they’re not interested in playing nice with the wider software community. Or in what their users want)

As a bonus, if client side decorations* were implemented in this more correct way, it would be simple for window managers to provide options to separate the window management controls from application-supplied menus and buttons – your window manager could have a “menu type” setting with “sensible hierarchical menus” and “terrible hambburger menu” options, and it could draw your application menus in the way the user prefers. It could even emulate the mac way of doing things and put your application menu up at the top of your screen, if that’s what you want, and not in the application at all.

(* note that they wouldn’t actually be “Client Side Decorations”, anymore, because that means “my application is going to take on a bunch of the window manager’s responsibilities, such as drawing window decorations”. Instead they would be a more sensible thing, that you might call something like “titlebar controls” or maybe “window manager widgets”)

Interestingly, the one saving grace that GTK has when it comes to the destruction of good user interfaces is one of the other user-hostile things that the gnome people have done with their toolkit – decided that backwards compatibility is for losers.

This has meant that for a decade, I could just continue to use my gtk2 software, with decent interfaces, because nobody wanted to port their software to gtk3 or gtk4 for no reason. It was only when gtk2 went EOL and then subsequencly started losing support in distros that everybody started going to the (massive and unnecessary) effort required to port over to gtk3. And that’s when we saw appilcations that has had great interfaces for 20 years turn to shit.

But now I’m seeing it everywhere. All the software I loved for ages has turned into trash, with shitty, buggy interfaces that have had to be reworked in nasty, unintuitive ways in order to accommodate the dictates of GTK. Apparently in gtk4 menu bars of the kind we’ve been using for decades and decades are now difficult or different to do.

There’s no reason for that other than to push application developers to use gnome’s preferred UI paradigms.

Which are all terrible.

And the gnome people aren’t interested in your opinion – they’re doubling down on the terrible UI that they prefer.

This isn’t (just) a case of “oh sorry we couldn’t be bothered being backwards compatible, again, so you’ll have to re-write your entire UI”, this is the maintainers of a UI toolkit intentionally trying to push application developers to adopt new UI paradigms, regardless of what the application developers or their end users want.

But, luckily, there’s a simple solution!

Just start completely ignoring GNOME. And GTK. Pay no attention to anything they do. Do not migrate your software to use their new toolkits, just stay on whatever version you’re on.

I’ve heard people claim that “oh we’ll need to migrate to gtk4 sooner or later, gtk2 and gtk3 will stop being shipped”.

To which my response is: “only if people like you let them do that”.

As long as there’s still a bunch of software using gtk2 (which there is, a decade after it’s end of life), GTK2 will still be packaged and shipped in distros – even if it’s not installed by default anymore.

Hell, I found out not long ago that the cinepaint project still maintains their own fork of GTK1. Respect.

GTK2 isn’t going anywhere any time soon. Instead, we’ll just have a situation where lots of users have gtk2, 3, and 4 installed and coexisting, and a bunch of interfaces that are inconsistent, all because the GTK/Gnome people couldn’t be bothered being backwards compatible and respecting user wishes.

I won’t ever be rewriting any of my gtk2 software to use gtk3 or 4. Instead I’ll do one of two things:

Migrate my software to another toolkit like EFL or wxwidgets, or
perhaps, if I get really bored, implement my own gtk2 compatibility layer on top of some other toolkit like EFL, or wxwidgets

I think the second option would be really nice. I’d like to see someone do it. Maybe I’ll have to. What you want is something that’s API-compatible with GTK2 so that application developers can simply swap out some old gtk includes for new ones and recompile their code against the compatibility shim, rather than having to rework their entire UI.

But that’s a nice-to-have. The core thing here is that we need to start simply ignoring Gnome and Gtk, and migrating away from both.

Don’t rewrite your interface in GTK3 or GTK4. Instead, if you really do need to rewrite (hint: you don’t), rewrite your interface on another toolkit. One which respects their users. One which is interested in backwards compatibility. Gnome and GTK have demonstrated 3 times now that they’re not interested in being backwards compatible. Instead they expect everyone else in the world to rewrite their interfaces every few years, and they’ve decided to make user interfaces worse in every respect.

This is unacceptable. Don’t let them get away with it. Don’t play their game.

Including command duration in your bash prompt

Posted on May 7, 2025 by antisol

For a long time I’ve had a dream: including the length of time it took for each command to run in my bash prompt.

Over the years I’ve looked into it a couple of times and seen partial “solutions” that were never quite what I wanted. The core of the problem being that there didn’t seem to be a way to get bash to run code before running each command, so there was no way for me to know when the command started – it seemed the best I could do was “how much time has elapsed since the previous command finished”, which is pretty useless info, because that measurement includes the (unknown) time it took me to type the next command.

The other day, I finally cracked it. The trick is to trap bash’s DEBUG signal:


# Include the duration of the previous command in bash prompt
# By Dale Magee

# Put (something like) this in your ~/.bashrc:

# vars for command timing / info
CMD_STARTED=""
LAST_CMD=""

time_me() {
	# this function runs before *each line* of your bash script.
	# we need to set the "command started" time at the beginning of the script
	#  so we only set it once, if it's unset, and then we unset it after the
	#  command has completed (in our promptcommand)
	if [ -z "$CMD_STARTED" ]; then
		CMD_STARTED=$(date +%s%N)  # %N - nanoseconds
		LAST_CMD="$BASH_COMMAND"
	fi
}

trap 'time_me' DEBUG

myprompt() {
	RESULT=$?
	
	if [ -n "$CMD_STARTED" ]; then
		# figure out duration of command
		TOOK=$(($(date +%s%N) - CMD_STARTED)) # get duration in nanoseconds
		TOOK=$(echo "scale=3; $TOOK / 1000000000" | bc -q 2>/dev/null) # nanoseconds -> fractional seconds
	else
		# unknown duration
		TOOK="??"
	fi
	
	# empty CMD_STARTED so that it will be set next time time_me is called
	CMD_STARTED=""

	

	# your custom prompt stuff goes here 
	# you can also use $LAST_CMD here too if you like
	#  (but note it's the full command line - might be long)
	
	PS1="\u@\h:\w $WHITE(${TOOK}s)$NO_COLOUR $ "
}

PROMPT_COMMAND=myprompt

Notes:

1. This only works if you use tab for indentation.

CADT is still going strong

Posted on January 28, 2025 by antisol

21 years later and it’s just exactly the same thing over and over and over again. And look! it’s even the same project Jamie was complaining about!

https://gitlab.gnome.org/GNOME/zenity/-/issues/22

https://www.jwz.org/doc/cadt.html

To be fair, this one lies squarely on me: Jamie warned me that this is how the gnome project operates literally 17 years before I filed my bug report. I have read and spread his CADT post many many times over those years. Basically it was silly of me to file a bug thinking that things might go any other way.

I’ll just add gnome projects to the list of projects that I don’t bother filing bugs for, and that I try to avoid wherever possible.

Command Of The Day

Posted on November 2, 2022 by antisol

The other day I learned about a new command that I wish I’d known about years ago: mountpoint

I’ve done all kinds of things grepping /proc/mounts (or the output from ‘mount’) in the past to try to determine whether a directory is a mountpoint or not, and there was a simple command for it all along.


$ mount

/dev/sdb2 on / type ext4 (rw,relatime,discard,errors=remount-ro)
/dev/sda2 on /home type ext4 (rw,relatime)
/dev/sdd1 on /media/external type ext4 (rw)

$ mountpoint /home
/home is a mountpoint

$ mountpoint /home/antisol
/home/antisol is not a mountpoint

$ umount /media/external

$ mountpoint /media/external || echo "Dammit"
/media/external is not a mountpoint
Dammit

# A Better Example:
$ mountpoint -q /some/dir || echo -e "\n** Setting up bind mount, sudo password may be required **\n" && sudo mount --bind /src/dir/ /some/dir

The State of Pulseaudio in 2021

Posted on July 21, 2021 by antisol

Every now and then I like to revisit an old topic.

So, let’s revisit pulseaudio and my hatred for it, shall we?

Now, you’re not an old greybeard like me, so you’re probably saying to yourself right now “OMG still with pulseaudio?!? That attitude is sooooo 2008!”

Well, for all the people over the years who have repeated the line of pure ~~bullshit~~ propaganda that “pulseaudio is much better these days and almost sorta kinda works most of the time, if you squint”, I’d like to present my first, reflexive solution to the fact that today I had no audio in zoom on a laptop with a current version of pulseaudio. A solution which, I might add, solved my problem instantly:

$ sudo bash -c "while true; do pkill -9 pulseaudio; done" &

Sure, it might not be efficient or pretty, but it worked. And it serves as a perfect metaphor for the state of Linux audio for this past decade and change, which can be summed up as “If you have an audio problem on Linux, the fault lies with pulseaudio”.

There have been multiple occasions where I’ve been trying to figure out some weird audio behaviour, only to realise “Oh OF COURSE! How silly of me! this machine has pulseaudio installed!”, and disable pulseaudio, and the problem goes away.

I’d file bugs for all this stuff, but I’m sure the fault lies with gnome (which I don’t use), or KDE (which I don’t use), or nginx, or my distro, or perhaps Microsoft Office. I’m sure these things are not actually problems with pulseaudio, because Lennart’s software never has any bugs.

I for one welcome the next decade’s worth of “if there’s a weird issue on Linux, The problem lies with systemd”, and being told in my bug reports that the problem is in the default configuration that comes with Mac OS X Server.

Now it’s off to go read the documentation (yet again) on how to disable this godawful dreck to stop it from automatically starting itself. Unfortunately we’re not in the days where just removing it is a simple option anymore (thanks for the totally unnecessary hard dependency, mozilla!)

Bye bye github

Posted on June 4, 2018 by antisol

Microsoft announces the ruination of github.

Because apparently destroying skype, linkedin, hotmail, etc etc etc wasn’t enough.

I can’t fathom the rationale behind this. Apparently there’s an accounting thing that having lots of users means you’re worth lots of money. So, 7.5 billion.

BUT surely there’s nobody out there who doesn’t think that MS buying github will immediately lead to an exodus of most of its users? As far as I’m concerned it’s a given: MS buys github, github users leave en-masse. I know it’s what I’ll be doing.

So basically MS is buying a website which will no longer have any users for 7.5 billion. Good luck with that.

I’d find it funny if it wasn’t so tragic. I liked github. Just like I liked skype.

kgrep

Posted on October 26, 2015 by antisol

Ladies and gentlemen, presenting: kgrep – kill-grep

This is a bash function which allows you to type in a search term and kill matching processes. You will be prompted to kill each matching process for your searchterm.

You can also optionally provide a specific signal to use for the kill commands (default: 15)

Usage: kgrep [<signal>] searchterm

Signal may be -2, -9, or -HUP (this could be generalised but I CBF).

search term is anything grep recognises.

kgrep() {
    #grep for processes and prompt whether they should be killed
    if [ -z "$*" ]; then
        echo "Usage: $0 [-signal] searchterm"
        echo -e "\nSearches for processes matching  and prompts to kill them."
        echo -e "signal may be:\n\t-2\n\t-9\n\t-HUP\n to send a different signal (default: TERM)"
        return 0
    fi  
    SIG="-15"
	#yes, this could be more sophisticated
    if [ "$1" == "-9" ] ||  
        [ "$1" == "-2" ] ||
        [ "$1" == "-HUP" ]; then 
        SIG="$1"
        shift
    fi  
    #we need to unset the field separator if ^C is pressed:
    trap "unset IFS; return 0" KILL
    trap "unset IFS; return 0" QUIT
    trap "unset IFS; return 0" INT 
    trap "unset IFS; return 0" TERM

    IFS=$'\n'
	for l in `ps aux | grep "$*" | grep -v grep `; do
        echo $l
        pid=`echo $l | awk '{print $2}'`
        read -p "Kill $pid (n)? " a
        if [[ "$a" =~ [Yy]([Ee][Ss])? ]]; then
            echo kill $SIG $pid
            kill $SIG $pid
        fi
    done
    unset IFS
}

Shameless plug

Posted on April 8, 2015 by antisol

This kind gentleman just helped me out with a problem I was having on IRC. his How to help page suggests linking to him, so that’s what I’m doing, because I’m damn cheap.

Go visit his website and give him money.

Future History of Init Systems

Posted on December 7, 2014 by antisol

2015: systemd becomes default boot manager in debian.
2017: “complete, from-scratch rewrite”. In order to not have to maintain backwards compatibility, project is renamed to system-e.
2019: debut of systemf, absorbtion of other projects including alsa, pulseaudio, xorg, GTK, and opengl.
2021: systemg maintainers make the controversial decision to absorb The Internet Archive. Systemh created as a fork without Internet Archive.
2022: systemi, a fork of systemf focusing on reliability and minimalism becomes default debian init system.
2028: systemj, a complete, from-scratch rewrite is controversial for trying to reintroduce binary logging. Consensus is against the systemj devs as sysadmins remember the great systemd logging bug of 2017 unkindly. Systemj project is eventually abandoned.
2029: systemk codebase used as basis for a military project to create a strong AI, known as “project skynet”. Software behaves paradoxically and project is terminated.
2033: systeml – “system lean” – a “back to basics”, from-scratch rewrite, takes off on several server platforms, boasting increased reliability. systemm, “system mean”, a fork, used in security-focused distros.
2117: critical bug discovered in the long-abandoned but critical and ubiquitous system-r project. A new project, system-s, is announced to address shortcomings in the hundred-year-old codebase. A from-scratch rewrite begins.
2142: systemu project, based on a derivative of systemk, introduces “Artificially intelligent init system which will shave 0.25 seconds off your boot time and absolutely definitely will not subjugate humanity”. Millions die. The survivors declare “thou shalt not make an init system in the likeness of the human mind” as their highest law.
2147: systemv – a collection of shell scripts written around a very simple and reliable PID 1 introduced, based on the brand new religious doctrines of “keep it simple, stupid” and “do one thing, and do it well”. People’s computers start working properly again, something few living people can remember. Wyld Stallyns release their 94th album. Everybody lives in peace and harmony.

Firefox Demographics

Posted on May 20, 2014 by antisol

Dear Firefox devs,

I’ve been using your browser for 10 years or so now – ever since I started to learn about open source software. The difference from IE was amazing – tabs!

Later, the difference became even more profound – Adblock! Firebug! and too many other add-ons to mention – eventually it got to the point where I had to limit the addons I use in order to not clutter and slow things down. Firefox really was the browser for power users.

I had my complaints – the CPU usage always seemed too high, and the memory usage was particularly absurd, but it did everything well.

Chrome happened. It closed the gap somewhat with its built-in developer tools and extensions. The one-process-per-tab idea was a good one. It was fast, and it didn’t require a gigabyte of memory to display one tab, but it just didn’t have the flexibility of firefox, so I could never quite make the switch.

There was one other thing about chrome I didn’t like – it had that sleek, minimalistic, “modern” interface. You know the type: they have pretty curved edges and nice animations for everything, but they tend to not be very configurable.

So it was with sadness that I updated my system the other day, only to see a shiny, chrome-lookalike interface on firefox.

I spent ages trying to turn the add-on bar back on and to remove the button which shows the awful new menu, to no avail.

Eventually I found the classic theme restorer add-on, which makes things sane again, but it’s not exactly awesome: Firefox is now using even more memory and I have yet another add-on installed just so that the interface isn’t terrible.

It seems that firefox is going for a new target demographic: they’ve decided to abandon the power users and go after the crowd who like chrome but think that it’s just too fast and doesn’t use enough memory.

Maybe they could use a new slogan: “Firefox: it’s just like chrome, only slower!”.

Personally, I think that this new demographic might be a limited market. If I wanted to use chrome, I’d…uh… use chrome.

Meanwhile, I wonder what the Opera team have been up to gor the last 5 years…

The Neo Freerunner – A Review

Posted on January 20, 2014 by antisol

I just emailled this to some guy who was asking about the freerunner on the openmoko lists, where I still lurk. I was proofreading it and thought to myself “hey, this is actually a pretty decent review of the device”. So here it is for all to see:

The freerunner is the worst phone ever made. It might nearly be usable as a phone now thanks to Radek and QTMoko, but you’re much better off buying an old feature phone or rooting an android phone. I think that while it might nearly be acceptable for a linux hacker, the freerunner software will never be a truly good user experience despite radek’s efforts – it’s too big a job for one person. I hope I’m wrong about that, but I don’t think I will be.

I was particularly appalled at the battery life. The battery used to last about 2 hours, but they have nearly solved all the power management bugs so if you’re lucky you might get ~6 hours out of it these days. It might even last all day if you keep it in suspend and don’t use it. In particular, using Wifi, Bluetooth, GPS, or having the screen on will significantly reduce the battery life you should expect to get.

It doesn’t have a camera, though I believe there’s a camera module for the GTA04.

An important thing to note is that due to a design flaw, the device is not capable of fully utilizing it’s accelerated graphics as bandwidth to the screen is limited. therefors it’s not capable of playing fullscreen video at the native resolution of 480×640. It will play fullscreen video if you’re into extremely crap resolution – 240×320. You shouldn’t ever expect to see much more than 10-15fps at full resolution.

The company went out of business because they made a buggy phone and couldn’t figure out what they wanted to do software-wise – they seemed to think that making the UI themeable was more important than being able to recieve phone calls or have working power management. The demise of Openmoko is a good thing.

If you’re looking for a phone, you do not want a freerunner.

If you’re looking for a hackable linux palmtop with a tiny screen, no keyboard, not very much power and a fairly awful battery life when you’re using it as a computer, then the freerunner might be an option for you, although you can probably buy something like a raspberry pi with 3 times the power for half as much money.

Nikolaus’ GTA04 project does seem much more promising and addresses a lot of the shortcomings of the freerunner and may be worth looking into. I have spoken to Nikolaus via email a few times and he seems like a very cool guy – I trust him and I’d buy a GTA04 in a heartbeat if I wasn’t put off by the price – I already spent $400 on a phone that doesn’t work, and I bought a nokia so that I’d have a working phone before Nick brought out the GTA04, so I can’t justify spending that much money to make my freerunner useful.

Routing everything via VPN

Posted on February 18, 2013 by antisol

I have a VPN.

I have it set up in a pretty standard way: when a machine joins the VPN it effectively becomes part of my LAN. But I don’t route everything via the VPN, that would be inefficient and would waste my bandwidth. I haven’t bothered with doing DNS over VPN, as I usually just use IP addresses anyway (one of the advantages of using a 10.x.x.x network), and when you do that you run into all kinds of complexities and problems (like how to resolve names on the lan you’re connected to)

But sometimes I’m somewhere where I don’t trust the owner of the network that I’m connected to: I don’t want to be spied on.

In these instances, it’s handy to be able to route everything out over the VPN connection.

But if you don’t stop to think for a minute and just try to add a default route which points to the VPN server, you’ll instantly lose your VPN connection and all internet access because there’s no longer any way to reach the VPN you’re trying to route through. Doh.

The solution is simple:

#!/bin/bash
#delete existing default route:
sudo route del default
#traffic to the VPN server goes out via your existing connection:
sudo route add <internet-ip.of.vpn.server> gw <your.existing.untrusted.gateway>
#...and everything else gets routed out via the VPN (assuming your VPN server is 172.16.0.1)
sudo route add default netmask 0.0.0.0 gw 172.16.0.1

OK, that takes care of routing. Next you need to send your DNS requests out via the VPN, or you’ll still be pretty easily monitorable – overlords will still know every domain you visit. To do that, edit /etc/resolv.conf and change the ‘nameserver’ line to point to the nameserver for your VPN and/or LAN:

#/etc/resolv.conf
nameserver 172.16.0.1

I recommend running your VPN on port 443. My reason is really simple: in oppressive environments, you can pretty much count on port 443 being open, since it’s used for https, and https is not something that a tyrannical sysadmin/policymaker can get away with blocking: it’s the backbone of e-commerce. In addition, https traffic is encrypted, as is VPN, so it’s less likely to be monitored by things like deep packet inspection, and any not-too-deep packet inspection is likely to come up with an outcome of ‘encrypted traffic, nothing unusual’ when looking at VPN traffic on port 443.

It should be noted that while this is unlikely to set off automated alarm bells, it will look somewhat unusual to any human observer who notices – your overlords will see a bunch of “https” traffic, but nothing else (not even DNS), which may in itself raise suspicions.

It should also be noted that you very likely just added a couple of hundred milliseconds to your latency and have now effectively limited your available bandwidth somewhat, depending on network conditions.

But I know from experience that the victorian government’s IT agency, Cenitex, is incapable of determining any difference between https traffic and VPN traffic going via port 443.

Though, of course, that doesn’t mean it’s impossible…

…In fact, that doesn’t even mean it’s difficult…

…but you should be reasonably safe from the spying eyes of your microsoft cerfitied sysadmin.

Teeworlds

Posted on January 24, 2013 by antisol

In today’s installment of “Awesome Open-Source Software”, I’m going to talk about Teeworlds.

A screenshot:

This game is a brilliantly playable, amazingly addictive, and hugely fun blend of a 2D platformer (a-la Mario) and a multiplayer FPS (a-la Quake3 or Unreal Tournament).

It’s not complicated: It’s multiplayer only, there are only 5 weapons, and the levels aren’t big or expansive – you won’t spend long looking for your enemy, you’ll spend more time lobbing grenades at him, and then running away frantically because you’re out of ammo and/or low on health.

That’s if you’re playing with only a few others. If there are lots of people in the game, it’ll just be frantic carnage, like any good deathmatch.

It takes its cues from “proper” deathmatch games – the old run-and-gun style: cover systems and regenerating health are for sissies; precision aiming is for people who don’t know about splash damage. Standing still is a VERY BAD IDEA. None of this “modern FPS” crap. This is evidenced most starkly in the fact that you can double-jump, and, perhaps coolest of all, you have a grapping hook, which you can use to climb and to swing yourself to/from places very quickly. If you play in a busy CTF server, you’ll see just how effective the grappling hook can be – these guys are SO FAST!

And it’s gorgeous and has a great atmosphere: cartoonish graphics and sounds. The sounds really do it for me: the cutesy scream your tee will make when he’s hit in the face with a grenade makes it fun to die, the maniacal yet cartoonish laugh your character will emit when your opponent cops a grenade to the face. It’s a really really fun atmosphere.

And I mean that: this is one of those games which is so much fun that you rarely feel like ragequitting, even when you’re losing badly: you will get killed mercilessly and repeatedly, but you’ll have a big smile on your face during the shootout, and when you die you’ll laugh.

And it’s quite well-balanced: none of the weapons are over-powerful or ridiculously weak. This is probably helped by the fact that the weapons have (very) limited ammo, even though running out of ammo sometimes annoys me slightly.

Downsides:

There aren’t enough teeworlds players in Australia, so I find myself playing on servers where I have a ping of 300 or more. This means you sometimes have a laggy experience.
You’ll come across killer bots sometimes. These bots are inhumanly good and can drain the fun out of being repeatedly stomped on, but the game has a voting system which allows you to vote on kicking players, so these bots are rarely a nuisance for long.
It has an ‘auto-switch weapons’ feature which switches when you pick up a new weapon, but it lacks a ‘weapon preference’ order a-la Unreal Tournament, and it does not switch weapons automatically when you run out of ammo. This is sometimes frustrating because you’re firing at your opponent but you only get an ‘out of ammo’ click, and while you’re trying to switch weapons your opponent kills you. But it’s one of those things you learn and it also serves to add tactics to the game – you’re always keeping an eye on how much ammo you have.

TL;DR: Teeworlds is a really really fun and addictive game which cleverly combines cutesy graphics and 2d-platformer gameplay with the frantic action of a golden-age FPS. It’s one of the better open-source games out there. Go and buy it now!

[EDIT: antisol.org now runs a Teeworlds Deathmatch server! ]

HOWTO: Write the worst piece of open-source software in the history of mankind

Posted on January 12, 2013 by antisol

…it’s actually pretty easy: All you have to to is write an open-source emulator (OK, fine, “API Compatibility Layer”) for the worst piece of software in the history of mankind.

In case it’s not completely obvious at this point, I’m talking about WINE.

Wine is a piece of shit. The only reason I don’t rate it as “worse than windows” is that the wine devs don’t expect you to pay for their garbage, whereas Microsoft does.

No, wait, I don’t want you to misunderstand me, so I’ll clarify my statement: wine is a godawful piece of shit.

Legions of freetards will quickly jump to defend wine: They’ll tell me how I have no right to criticise the hard work of all these people who are giving me something for nothing, and they’ll talk about how well the wine team keep abreast of the latest developments and how they’re in an impossible situation because they’re aiming at a moving target and how Microsoft’s documentation leaves alot to be desired in terms of reimplementing the entire Win32 API.

And they do have a point – the wine devs are not trying to do something trivial.

But that doesn’t change the fact that wine is a piece of shit.

I won’t dispute that there are some talented people working on the wine project – I don’t even want to think about how complex such an undertaking is, but if you can’t even make things work consistently when somebody upgrades to a new version of your product, it’s a shit product, and you’re useless, not doing enough testing, and not managing your project properly. Keeping existing features working is more important than adding new features.

Keeping existing features working is more important than adding new features!

KEEPING EXISTING FEATURES WORKING IS MORE IMPORTANT THAN ADDING NEW FEATURES!

Wine suffers from a completely retarded number of regression bugs: something which works just wine in version X of wine may or may not work in version X+1. This is an absolutely ridiculous situation.

Apparently “STABLE” doesn’t mean what I thought it meant: I thought it meant “Working, Usable, and tends to not crash horribly in normal use”. But the wine team seems to think that “STABLE” means “This alpha feature is almost feature-complete and almost works. Mostly. Except when it doesn’t”. I can’t fathom the decision to mark Wine 1.4 as “Stable” with its redesigned audio subsystem which lacks a fucking pulseaudio driver! And the attitude they take is “pulse has ALSA emulation, so we don’t really need to support pulse” – a weak cop-out at best. I mean, it’s not like the majority of distros these days default to using pulse… Oh, wait…

Application-specific tweaking. Oh, the essay I could write on the bullshit required to make any particular application work. Here’s the usual procedure:

Go to appdb.winehq.org, see that it’s rated as “garbage”
Note that the ‘Garbage’ Rating was with the current version of wine, and that there’s a “Gold” rating for the previous version of wine. Click on the gold rating to see that review
Scroll down through the review to see if there are any helpful tips as to wierd and wonderful esoteric settings you should change to make your app work
Try all the tips and manipulating all the settings in the previous point, to no avail
Revert wine to the earliest version available in your distro’s repos. It’s important to note here that you probably just broke every other wine app you have installed
When this doesn’t work, download and attempt to compile the version which got the gold rating. If you manage to get it to compile and install correctly (it probably won’t – it’ll depend on an older version of at least one library, which will lead you straight into dependency hell), go back to fiddling with esoteric settings for a few days
When you’re sure you’ve replicated all the tweaks, DLL overrides. and settings for your app as per the gold rating on the appdb and it STILL doesn’t work, scream loudly
Install virtualbox and waste many resources just so that you can run your app
Hope that you used checkinstall when you compiled the old version of wine, so that it’s possible to remove it without wanting to commit ritual suicide
Install the version of wine you had installed from the repos. Hope that the other apps you spent days configuring and actually managed to get working still work.
Hope that the few apps you actually got working don’t break horribly next time you do an apt-get upgrade

I can’t be fucked with any of this anymore, so here’s the process I use:

Create a new wineprefix: ‘env WINEPREFIX=~/wineprefix_for_this_particular_app winecfg’. It’s important to create an entirely new wineprefix for each app, because that way it’s slightly less trivially easy to break all your other apps just by changing one setting.
Run the installer with something like ‘env WINEPREFIX=~/wineprefix_for_this_particular_app wine some_installer.exe’
When things fail horribly (and they will for about 99.999% of apps in my experience), type ‘rm -Rv ~/wineprefix_for_this_particular_app’ and install it in your VM.

The most hilarious and entertaining part about all of this is the way that even after all my experiences which indicate the contrary, sometimes I still tend to assume that things will work under wine – after all, the wine mantra is “if it’s old, it’s more likely to work”. Here are some examples:

“The old PC version of ‘Road Rash’ – the one with soundgarden in the soundtrack – it’s more than 10 years old! It’ll be using DirectX 3 API calls if it’s lucky! SURELY it will ‘Just Work’ in wine, right?”
“Oh, I know – I’ll Install Dungeon Keeper – it’s old – it should Just Work, right?”
“AHA! Deus Ex has a ‘Gold’ rating with THE CURRENT WINE VERSION! Surely that means it will Just Work?”
“Aah, JASC Animation Shop. Such a great little app. I used to use it all the time back in 1997. Is should Just Work, right?”

And now, some questions for the wine developers:

Why is it that Fl Studio uses about 3 times as much processor time in the current version than it did in the previous version? For some of my tracks, FL Studio sits at 90% CPU Utilization when it’s NOT EVEN PLAYING. Trying to play will give you a horrible mess of stuttering as the CPU valiantly attempts to keep up with wine’s bullshit demands. With the previous version of wine and the exact same track on the exact same install of FL Studio with the exact same settings, this track played just fine. I have been tweaking for about 4 days now and have achieved ABSOLUTELY NOTHING in terms of improving this situation.
Why has wine not absorbed PlayOnLinux (another awful piece of code – random hangs FTW!)? This functionality should be included in wine (i.e: a central, per-application/wine version ‘tweaks’ database. You have a nice interface for installing apps. You choose the app from a list, and wine downloads the tweaks appropriate for that app and applies them automatically. This would not be hard to implement, and would solve a HUGE number of issues for a huge number of users.
What genius decided that a version with a broken pulseaudio driver should be marked as “Stable”?
Speaking of re-engineering your audio stack, can you please explain how this new, non-functional audio subsystem is superior to the working one which it replaced?
Do you anticipate that one day wine will actually be able to do what it says on the tin? Or should I just give up on the whole concept? I feel like I am the butt of some huge, multi-year practical joke.

Now, to be fair, this is not all the fault of the wine devs – it’s also the fault of the people who manage repos for the various distros out there: these people should learn, and simply not upgrade the wine version in our repos until they’ve checked whether the fucking thing works or not – it’s a wierd kind of synchronicity that choosing a wine version is kind of like using Microsoft products: You never, ever, ever install the initial release, you wait for R2, when it might actually stand a chance of being something other than utter shit.

Wine sucks. It’s the worst piece of open-source code in the history of mankind. There are two factors why:

Because they’re emulating the worst piece of code in the history of mankind.
Because they’re amateur idiots who suck and can’t manage a project properly and don’t do enough testing. This is evident in that they regularly break backwards compatibility.

There is never a reason or excuse for breaking backwards compatibility other than laziness, and it’s therefore never acceptable to break backwards compatibility.

Wine is a piece of shit.

[EDIT: wine 1.5 is better than 1.4, but still not up to par with 1.2]
[EDIT 2: I'd really really love to hear an explanation of why opening a common dialog crashes metacity]

foxtrotgps / landscape mode X apps on qtmoko / QX

Posted on November 4, 2012 by antisol

I’ve been playing with the latest QTmoko on my freerunner after a couple of years of not updating my distro.

Some thoughts:

It’s great! Very snappy and responsive – congrats and thank-you to Radek and the other contributors, you’ve done a fantastic job and you’ve made some great strides over the last couple of years.

I haven’t tried using it as a phone yet (I’m still put-off by my previous experiences, and don’t have a second SIM), but it looks like it might be *gasp* almost usable! :O I’m tempted to try it out as a phone…

I particularly like what you’ve done with the keyboard – I think it’s about as good as an on-screen keyboard is going to get on this device. Very nice. though I wish I could have it default to qwerty mode.

But it’s not perfect – everything I want doesn’t “just work” yet (though it is very good – things like wifi and bluetooth seem to just work). But that means I get to have some fun tinkering!

I’ve been messing about with making foxtrotgps work under QX on qtmoko for a little while, and wanted to jot down some notes and tips:

When QX asks which X server to install, I recommend xorg – xglamo doesn’t seem to like being rotated. I’d love to make xglamo work, because it seems faster. (Performance with foxtrot on xorg is very usable, but faster == better.)
You very likely want to apt-get install gconf2, or foxtrot won’t save user prefs (e.g mapset, postiion, etc) when you close it.
Rotating the X screen with xrandr doesn’t rotate the touchscreen input properly. To fix this, you need to use xinput to swap the x-axis.

I’m using ‘xrandr -o right’ for my landscape orientation. This means that the USB plug on the freerunner is at the top. If you want to use ‘-o left’ you’ll need to play around with the axis swapping.

There’s no onscreen keyboard for X apps. To fix this, apt-get install matchbox-keyboard matchbox-keyboard-im, and launch matchbox-keyboard –daemon before you start foxtrot. This will give you a keyboard which pops up when you select a textbox. After foxtrot closes, I kill matchbox-keyboard.
QX has a ‘display always on’ option, but X has its own screensaver and blanking/dpms stuff. you’ll want to use xset to turn these off if you want your display always on.
You need to start gpsd before you start foxtrot. I also kill gpsd when foxtrot closes. This means it can take a while to get a fix, but I haven’t done a huge amount of outdoor testing yet – all I’ve done is confirmed that it will get a fix.
Pressing the AUX button to multitask while X is rotated under QT is ugly – qtmoko will work, but its display will be broken – it looks kinda like QVGA mode and is incorrectly rotated. If you can manage to hit AUX a couple of times to get back to QX, and then press ‘resume’ or ‘stop’ in QX, qtmoko will revert to an un-broken state. Ideally I’d like to disable qtmoko’s AUX-button handler while foxtrot is running, or capture focus events to unrotate on lostfocus and rotate on gotfocus, but I haven’t yet found a way to do either of these.
The above ugliness will also happen if X dies while rotated, so you need to xrandr -o normal after foxtrot exits. This means you want to exit foxtrot gracefully. Since foxtrot doesn’t have an ‘exit’ menu item, this means you want to ‘use matchbox’ in the QX settings. You also want fullscreen.

I ended up doing the following to make a wrapper script for foxtrot. It’s a bit of a nasty hack, but it works for me. A slightly nicer way would be to use update-alternatives to use an alternate foxtrotgps launcher script, or saving the script as ‘foxtrot_launcher’, building a desktop entry for it, and setting up a QX favourite for it.

the script below could very easily be modified/generalised to run things other than foxtrotgps!

root@neo:~$ mv /usr/bin/foxtrotgps /usr/bin/foxtrotgps.bin
root@neo:~$ vi /usr/bin/foxtrotgps
              (insert content, below)
root@neo:~$ chmod a+x /usr/bin/foxtrotgps

/usr/bin/foxtrotgps:


#!/bin/bash
#Custom script for starting gpsd and foxtrotGPS in landscape mode:
#xinput stuff liberated from: http://lists.openmoko.org/nabble.html#nabble-td7561815

#ensure GPS is powered up:
om gps power 1
om gps om gps keep-on-in-suspend 1

#gpsd
#service gpsd start
gpsd /dev/ttySAC1

#sleep 1 
# we might have to wait some time before sending commands (I didnt)

#rotate:
xrandr -o right

#disable screen blanking:
xset s off -dpms 

#swap x axis:
xinput set-int-prop "Touchscreen" "Evdev Axis Inversion" 8 1 0
#no axis inversion
xinput set-int-prop "Touchscreen" "Evdev Axes Swap" 8 0
xinput set-int-prop "Touchscreen" "Evdev Axis Calibration" 32 98 911 918 107

#run the matchbox keyboard in daemon mode:
#with matchbox-keyboard-im this pops up automatically
matchbox-keyboard --daemon &

#run the real foxtrot:
foxtrotgps.bin --fullscreen

#foxtrot has closed, cleanup:

#kill keyboard:
killall matchbox-keyboard

#unrotate:
xrandr -o normal

#stop gpsd:
#service gpsd stop
killall gpsd

Converting red-blue anaglyph to stereoscopic images

Posted on July 16, 2012 by antisol

(EDIT: Updated to add black border between images – makes it easier to see the 3d, and makes the 3d image better defined)

I hate those red-blue anaglyphs. The red and blue fucks with my head – my brain refuses to interpret it properly, and the object does this wierd “flashing” between red and blue.

Plus, I’m too cheap to buy (and too reckless to keep) a pair of those red-blue 3D glasses.

So, I installed Imagemagick and wrote myself a bash function:

stereo_convert () {                                                                 
    in="$1"                                                                   
    out="$2"                                                           
    if [ -z "$in" ] || [ -z "$out" ]; then                                    
        echo -e "\nYou need to supply input and output files!\n"              
        return 42                                                             
    fi                                                                        
    convert \( $in -gravity east -background Black -splice 10x0 -gamma 1,0,0 -modulate 100,0 \) \( $in -gamma 0,1,1 -modulate 100,0 \) +append $out;                  
    echo -e "\nConverted red-blue stereo image '$in' to side-by-side image '$out'.\n"
}

Here’s a demo image from NASA’s Pathfinder mission.

Input:

Output: