Big-M Notation

Today's node.js chaos seemed like it was only a simple lesson in Operations 101 (hint: always host the code for your application and the modules it depends on in the same place) until one looks at the actual function that everyone was linking to:

function leftpad (str, len, ch) {
  str = String(str);

  var i = -1;

  if (!ch && ch !== 0) ch = ' ';

  len = len - str.length;

  while (++i < len) {
    str = ch + str;
  }

  return str;
}

This is quite possibly the worst algorithm in the (admittedly short) history of padding strings. Unless JS is doing something special behind our backs, we're looking at something on the order of len string allocations here, each one slightly larger than the last.

OK, so JS more or less asks for problems like this because it refuses to provide anything remotely resembling a standard library. Still, this is a common enough problem: people using dynamic memory management as if it were free, with no awareness of the costs of memory allocation and subsequent garbage collection.

To help raise awareness, I propose a Big-M notation to supplement Big-O notation (and Big-theta and all that). Big-M, or M( ), determines how memory allocations in an algorithm will grow with an input n. As with the other Big-notations, lower-order terms are dropped. 

Using this notation, the above string padding algorithm is M(n), when it should be something constant like M(1).

firefox profiles for ad-hoc privilege separation

Just a quick write-up, since few people seem to actually be doing this.

Firefox supports profiles: each profile is a distinct configuration under ~/.mozilla/firefox, with its own extensions, themes, bookmarks, history, and cookies. This means that badly-behaved web pages in one profile will not be able to read the data from another profile (unless they actually own your system, which is beyond the scope of this simple technique). It also means you can have as many GMail accounts as you like without having to sign out and wipe cookis every time.

To create non-default profiles, open the profile manager from the command line:

bash# firefox --no-remote -P

Create as many profiles as you like. There can be one for each online persona, one for email, one for paying bills, one for pr0n, whatever. For this discussion, we will assume the profile test was created.


For each profile, do the following:

1. Create a desktop file for the profile in ~/.local/share/applications . Make sure the .desktop filename is unique.

  bash# cp /usr/share/applications/firefox.desktop ~/.local/share/applications/firefox-test.desktop

2. Add a distinct icon for the profile in ~/.local/share/icons . You can get different icons by doing a Google image search for firefox icon. There are plenty.

  bash# cp ~/downloads/firefox-green.png ~/.local/share/icons/firefox-test.png

3. Edit the .desktop file to ensure that the Name and Icon are unique, and that the Exec line references the new profile:

Name=Mozilla Firefox (testing)
Exec=firefox --no-remote -P test
Icon=firefox-test.png

That's all there is to it. A new icon for Firefox (testing) will appear in your favorite window manager. Add whatever extensions you deem fit for the purpose.

RIP inittab

Your getty configs are all in /lib/systemd/system/getty@.service now.

[Service]
# the VT is cleared by TTYVTDisallocate
ExecStart=-/sbin/agetty --noclear %I $TERM                                      
Type=idle
Restart=always
RestartSec=0
UtmpIdentifier=%I
TTYPath=/dev/%I
TTYReset=yes
TTYVHangup=yes
TTYVTDisallocate=yes
KillMode=process
IgnoreSIGPIPE=no
SendSIGHUP=yes

Control via /etc/systemd/logind.conf -- see man 5 logind.conf for more info.

xdg-open arcanery

In the midst of playing with tycat and terminology on a virtual console*, it became apparent that xdg-open wasn't doing its job in regards to opening PDF documents.

  bash# xdg-open /tmp/dw.pdf 
  Filename "file:///tmp/dw.pdf" does not exist or is not a regular file

A simple check of the default handler shows that everything is fine:
  bash# xdg-mime query default application/pdf
  evince.desktop
..but for fun, let's try to change it and see what happens.
  bash# xdg-mime default apvlv.desktop application/pdf
  bash# xdg-open /tmp/dw.pdf 
  Filename "file:///tmp/dw.pdf" does not exist or is not a regular file
Nothing.

Grepping for the error in /usr/bin/xdg-open comes up empty. It's odd that two unrelated programs (evince and apvlv) would have the incorrect error message (the file does exist and is regular), or that they would both fail to handle file:// URIs. How does xdg-open actually route these requests?

Turns out it depends on your window manager. If you are running Enlightenment, xdg-open performs the following:

open_enlightenment()
{
    enlightenment_open "$1"

    if [ $? -eq 0 ]; then
        exit_success
    else
        exit_failure_operation_failed
    fi
}

Replacing enlightenment_open "$1" with open_generic "$1" works. Can we invoke open_generic when enlightenment_open fails? Turns out we can't, because enlightenment_open returns 0 (success) even when the file isn't opened.

Fixing enlightenment_open might do the trick. The relevant code (enlightenment.git/ src/bin/e_open.c) is here:

        char **itr;

        int ret = EXIT_SUCCESS;

        for (itr = cmds; *itr != NULL; itr++)

          {

             /* Question: should we execute them in parallel? */

             int r = system(*itr);

             if (r < 0)

               fprintf(stderr, "ERROR: %s executing %s\n", strerror(errno),

                       *itr);

             free(*itr);

             if (r > 0) /* Question: should we stop the loop on first faiure? */

               ret = r;

          }

        free(cmds);

        return ret;

It turns out that the status of what enlightenment_open is calling is ignored. But what is it calling? Adding the line fprintf(stderr, "Trying %s\n", *itr); after the system() call uncovers what is actually happening:

bash# make src/bin/enlightenment_open

  CC       src/bin/src_bin_enlightenment_open-e_open.o

  CCLD     src/bin/enlightenment_open

bash# src/bin/enlightenment_open /tmp/dw.pdf 

Filename "file:///tmp/dw.pdf" does not exist or is not a regular file

TRYING evince-previewer 'file:///tmp/dw.pdf

Where the hell did evince-previewer come from? To make a long story short, xdg-open (and enlightenment_open, and all other *_open tools) uses /usr/bin/mimeopen as a backend. 

This utility operates on files, not mime-types:

bash# mimeopen -a /tmp/dw.pdf 

Please choose an application

1) Print Preview  (evince-previewer)

2) Document Viewer  (evince)

3) vprerex  (vprerex)

4) GNU Image Manipulation Program  (gimp)

use application #

Cancelled

OK, so that is where evince-previewer is coming from. A quick test shows that the actual bug is caused by evince-previewer not understanding file URIs:

bash# evince-previewer file:///tmp/dw.pdf

Filename "file:///tmp/dw.pdf" does not exist or is not a regular file

bash# evince file:///tmp/dw.pdf

(evince:21480): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -82 and height 15

That Gtk warning accompanies evince loading and displaying the file just fine. 

Changing the handler for PDFs using mimeopen turns out to work just fine:

bash# mimeopen -d /tmp/dw.pdf 

Please choose a default application for files of type application/pdf

1) Print Preview  (evince-previewer)

2) Document Viewer  (evince)

3) vprerex  (vprerex)

4) GNU Image Manipulation Program  (gimp)

5) Other...

use application #2

Opening "/tmp/dw.pdf" with Document Viewer  (application/pdf)

(evince:21510): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -82 and height 15

bash#  xdg-open /tmp/dw.pdf 

(evince:21550): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -82 and height 15

xdg-open /tmp/a.pdf

(evince:21602): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate widget with width -82 and height 1

Of course, that doesn't mean that evince-previewer is the only bug. Since evince-previewer returns 1 (failure), enlightenment_open should be returning 1 instead of 0:

        int ret = EXIT_FAILURE;

        for (itr = cmds; *itr != NULL; itr++)

          {

             int r = system(*itr);

             if (r < 0)

               fprintf(stderr, "ERROR: %s executing %s\n", strerror(errno),

                       *itr);

             free(*itr);

             ret =  r;

          }

...and xdg-open should check the return value and fallback to open_generic:

    enlightenment_open "$1"

    if [ $? -eq 0 ]; then

        exit_success

    else

        open_generic "$1"

        if [ $? -eq 0 ]; then

            exit_success

        else 

            exit_failure_operation_failed

        fi

    fi

Let's not even get started on why xdg-open doesn't propagate changes back to mimeopen. Wait, why doesn't it?

UPDATE: looks like there's something deeply wrong with with the xdg-* utilities:

bash# xdg-settings get default-web-browser
xdg-settings: unknown desktop environment

The problem here is that xdg-settings performs its own check for desktop environment (modularity, people!) and, of course, implements this poorly. If the desktop environment is detected (as is Enlightenment), but is not KDE|Gnome|XFCE|MATE,  it returns "unknown desktop environment". If the environment is not detected, a generic handler is called. There are some very confused people working on this software.

The fix is to modify xdg-settings, changing the default case statement
*)
    exit_failure_operation_impossible "unknown desktop environment"
    ;;

to

*)
    dispatch_specific generic "$@"
    ;;

* For those interested: install tslib and rebuild EFL from source, then run the following on a virtual terminal:
ELM_ENGINE=fb /usr/local/bin/terminology -f=nexus/20

Yes, the -b option for a backgroud image will work, as will tytls, tyop, and tycat.