[Inx] Thoughts and Isssues: INX
inx-one at optusnet.com.au
Thu Jun 26 01:28:07 PDT 2008
As there has not been much happening with INX over the last couple of
weeks, I am sending this as an update, and a possible catalyst for
In this post I want to deal with some potential issues. One of them is
technical, and the others are about "policy", for want of a better term.
As you will be aware, INX has never really been publicly announced,
other than on a few mailing lists. Part of the reason for this up to
now has been my disquiet with a technical problem regarding the links2
In INX, the links2 browser is currently suid root -
ls -l /usr/bin/links2
-rwsr-xr-x 1 root root 2807180 2008-01-05 01:05 /usr/bin/links2
The reason for this is that this is the only way so far that I
have been able to make the "directfb" graphics "work" from the
menus. It is possible to make directfb work with links -g (AKA
xlinks2) by altering permissions in
(For example, setting user "inx" as a member of group "tty" and
making devices writable by that group as follows:
KERNEL=="mice" GROUP="tty", MODE="0660"
KERNEL=="tty[0-9]*" GROUP="tty", MODE="0660"
KERNEL=="fb0" GROUP="tty", MODE="0660" )
Unfortunately, while this allows links2 -g / xlinks2 to start and run
without the suid bit *from a command prompt* , the browser fails
to start *from a menu entry or script*
I have tried without success to change the scripts in various ways in
order to make directfb "work" with links2...
Links2 simply refuses to run using directfb from any script unless set suid root.
I think this is a directfb question, but I confess that my understanding of
directfb is... *cough* rudimentary.
One point worth mentioning: if the browser is called with "exec" from a menu
or script, with thte permissions tweaked as above, it runs.
This is not very useful though, since once you invoke "exec"
you are out of the INX shell, so quitting links2 then returns you to a prompt.
The "safe but not really optimal" solution is to run links2 -g /xlinks2 using only
ordinary "fb" (the slow vesa framebuffer). This is fairly horrible, since the mouse
becomes very "slow" , the scroll wheel "Doesn't Work", and so on. If you want to
try it, invoke the browser thus:
links2 -g -driver fb <some-url-here>
Of course, all of the above applies only to running the browser graphically in a tty,
and not in "X", which works fine...
I've made this rather long dissertation in the hope that some of you might find
time or interest to solve the problem ;-) I won't go into the reasons why suid
on a browser is,,,, shall we say, Not the Right Thing (tm).
Stable vs, Development Models:
Since the current development versions of INX are based on Ubuntu Hardy,
the released version ("Real Soon Now", "When it's Ready", etc. etc.) will stay
pretty much "as is" for a few years.
It occurs to me that we could use a model similar to the Debian approach, and
have an "unstable" branch into which improvements and features could be added
continuously. The reason that I am thinking about this is that I feel it would help to
generate interest in INX for people who want to play with the code, add stuff or
improve it, and so on.
Announcements, Release and other Scary stuff: ;-)
* We need to set up a torrent when the announcement is made - you never know,
there might be some interest, and anyway it's the Right Thing.
* Some mirrors might be nice - if nothing else, it's good for people to have a server
relatively nearby rather than having to download from half way around the world.
* I have no idea what information needs to be gathered for, say, Distrowatch,
but that would be easily discovered...
* Team members might like to think about writing press releases / blogs/ other
marketing things. ( I have an unreasonable prejudice about such matters that
I might need to overcome *grin*)
Feel free to respond in a similarly rambling style, or if you have a solution to the links2
problem, please let us know...
Peter Garrett <inx-one at optusnet.com.au>
More information about the Inx