the following word should never be spelt with a capital letter:

desrt

k, thx :)

a name i was thinking about a long time ago and jeff reminded me of

i present to the world:

GVariant

if anyone has anything negative to say about this name, now would be a good time…

DValue is the datatype at the foundation of dconf and of the glib-based dbus bindings that rob and ori are theoretically working on. it will end up being part of libglib (probably for the release before next guadec).

it is named DValue because it used to be named DConfValue.

you can read a little bit about DValue here.

one thing to note is that, unlike GValue, a DValue is actually a value — not a container or a variable. it can only exist as a value with a type and the value can never change. when you create it it has a value and the only way to get rid of that value is to destroy it. also note that it can contain exactly those values that can be sent over dbus. it cannot contain, for example, object references.

the problem is that its name starts with a ‘d’ and everything in glib must start with ‘g’. i would rename it to GValue but i cannot do this for obvious reasons.

i need a name for it that starts with g. this is something that a lot of people have thought about for a long time without coming up with any good name.

all suggestions must start with G, be short (G + 5 chars max) and not conflict with anything currently in glib or gobject. entries will be judged by my personal whim. i will buy the winner a cookie at our next meeting. feel free to list many suggestions but note that most of the obvious ones have already been considered and shot down for some reason or another…

thanks :)

today on #gnome-hackers i was musing to richard about how i think that the current g-p-m/g-s-s setup is very confusing. i’ve thought about this for a while and today i did an AsciiBuilder mockup of what i think the interface should be. he was interested enough to ask me to blog about it to gather opinions from planet.

i make no proposal about how this might be implemented or what the hand-offs between g-p-m and g-s-s might look like. i only propose this as what we should present to the user (and we can figure out the technical parts later).

here it is:

  Computer is inactive after         [2min, 5min, 10min, 1hr, never]

  [X] Automatically lock when inactive

      (*) immediately

      ( ) after an additional        [10min, 20min, 1hr, 2hr]

  [X] Show screensaver when inactive

      for the first                  [10min, 20min, 1hr, 2hr, forever]

          [X] even when I explicitly "Lock Screen".

the [2min, 5min, etc] are not meant to be an exaustive list of times supported by these options. they are merely there to indicate that some time selector is required with possible “never” or “forever” options, as appropriate.

forget screensavers for a moment. pay attention to only the top half of the dialog box.

the basic principle here is that in the absense of a screensaver, the monitor should either be showing your desktop or be powered off (with a small exception made for showing the ‘unlock’ dialog). this powered-off state is called “inactive”. i have not addressed the challenge of how to express this nuance to the user (although maybe it will just be obvious).

if ‘locked’ (implicitly, desktop is not shown) then this implies that the monitor must be off. however, the reverse implication is not true so we allow for a time difference between these two things occuring (including the possibility of zero and infinite time difference).

remember: so far, inactive means “monitor power is off”.

bringing in a screensaver spices things up a little bit but it’s not too bad. i see the screensaver merely as the initial (possibly never-ending) phase of power off. you show it first the first 10 minutes of what would have previously been the monitor’s powered-down mode. there is an exception for the “Lock Screen” item on the panel that allows you to have the screensaver skipped since many people will probably desire this.

note: no relationship whatsoever between the transition from screensaver to power-off and the transition from inactive-but-unlocked to locked. either may occur first (or never).

i think the behaviour from this dialog will be extremely clear and totally specified except for one small detail: when the screensaver is enabled and the unlock dialog box pops up after the monitor has gone to sleep, and the user fails to enter the correct password, then what happens? does the screensaver come on for another 10 minutes or does the computer go directly back to the state that it was in before the user moved the mouse? honestly, i don’t really care and i don’t think we need to expose this as an option.

a possible variation on the screensaver section above is as follows:

  [X] Show screensaver when inactive

      for the first                  [10min, 20min, 1hr, 2hr, forever]

  [X] Show screensaver when I "Lock Screen".

      for the first                  [10min, 20min, 1hr, 2hr, forever]

conceptually it is slightly clearer, and it also allows for more options not allowed by the other dialog. i actually prefer the second choice but i understand that some might see it as overkill.

the use case i have in mind for the second variation is that it might be helpful to show the screensaver for a minute or two after explicitly locking in order to use the monitor as a source of light (when going to bed or locking up the office at night). this might be desired even when a screensaver for inactivity is not desired (or if the inactivity screensaver is desired for a longer length of time).

it might be desirable to put the “screensaver section” in its own dialog (along with the options for selecting the specific screensaver to use).

as for the “times”: how do we do it? spinbox? slider? dropdown menu?

i really like the idea of a dropdown menu containing only “useful” lengths of time. the list of what makes a “useful” length of time is something like:

* 1 minute
* 5 minutes
* 10 minutes
* 30 minutes
* 1 hour
* 2 hours

a consideration not addressed here: perhaps someone wants to cause their computer to immediately be considered as “inactive” (because they are leaving their desk and they want to save power or just hide their screen contents) but doesn’t want to deal with unlock dialogs. we currently have absolutely no way of dealing with this. it’s difficult too, since a simple accidental flick of the mouse would be all that is required to re-activate the desktop. hot corners, anyone?

that is all.

la la la another one of these… time to pile on!

murray: please don’t “retract your post” as some are calling on you to do. this is such a ridiculous concept. you said what you said because it’s exactly what you meant to say. publishing a retraction won’t change that.

clearly some people agree with your statements and some disagree. this is an issue of personal opinion. your blog is obviously your opinion. the only thing i wish is that you were a little thicker on actual substantiation behind your claims and a little bit lighter on inflammatory language. perhaps something to keep in mind for next time.

there are a couple of things i really hate. one of them is people who persistently pretend to have a different level of skill than they really do (this goes in both directions). the other is people who talk trash behind someone’s back and act all friendly to their face. if someone has a problem with someone else, i think that they should make that person aware of it.

screaming it from the rooftops may or may not be the appropriate method to do so.

clarification: the “people who persistently pretend to have a different level of skill than they really do” comment has absolutely nothing to with the current goings on. i list it here only because, it is literally one of my two least favourite things.

a few days ago i woke up in the morning and i checked my mail. i replied to a mail and evolution told me:

Recipient address rejected: Policy Rejection- You have exceeded the maximum(350) number of messages or recipients per hour. Please call Mountain Cablevision Technical Support: 905.389.1393. Thank you.

i instantly panic as i try to figure out which machine in my house has been infected with malware.

“mailq” on my main server says 3000 outgoing deferred messages. ok.

i take a look into the log and discover that the outgoing messages are all bounce replies for non-existent addresses. i’m generating backscatter! what the hell… i thought my postfix was configured properly. since i only receive mail for local users (and nothing fancy is going on) the mails to non-existant users are supposed to be immediately rejected at RCPT time.

the odd thing is that all of the bounces are for non-existent addresses *@kopesetik.desrt.ca.

i check my postfix configuration, and surely enough:

mydestination = desrt.ca

after reading some documentation i find out about another postfix option “relay_domains”. this is the list of domains that postfix will accept mail for (even if not to deliver locally). by default, this is set to be exactly equal to $mydestination, so in theory your mail server by default should only accept mail for domains that it will deliver locally for.

unfortunately there is yet another postfix configuration option. this is the worst setting ever. it is called “parent_domain_matches_subdomains”. this configuration parameter changes the interpretation of other configuration parameters. for each item listed in this parameter the meaning of the value of that item is modified. if for example, item “foo” is listed, and in your configuration file you have “foo = desrt.ca” then the meaning is now actually taken to mean “foo = *.desrt.ca”.

rather moronically, the default for this option is to include relay_domains but not mydestination.

so we have:

mydestination = desrt.ca
relay_domains = $mydestination
…but really, relay_domains = $mydestination plus a bunch of other crap…

this causes your mailserver to accept messages that it can not possibly deliver. in response, it must generate bounce messages. this makes you a source of backscatter and a contributor to the spam problem.

the brokenness can be fixed by setting the “parent_domain_matches_subdomains” option to empty.

broken broken broken.

i tried testing delivering to “nosuchuser@asdf.example.com” against the mailservers of some other people i know and about half of them had this exact problem (the ones with the problem were all running postfix). your mailserver should issue an error immediately on RCPT to such addresses. if the message is accepted for delivery then it is too late. please check your mailserver and fix as appropriate.

take that, web!

most gnome hackers are probably accustomed to the fact that they can pass a null pointer as a value to glibc’s “%s” conversion character and get the string “(null)” output instead of a crash.

take for example, this program:

#include <stdio.h>

int
main (void)
{
  printf ("%s", NULL);

  return 0;
}

this will output “(null)”. nice. i like this glibc feature.

of course, this program fails to put a newline. let’s make the obvious fix:

#include <stdio.h>

int
main (void)
{
  printf ("%s\n", NULL);

  return 0;
}

this program segfaults.

why is this?

let’s look at the assembly code generated for the second program:

...
...
main:
        ....
        ....
        call puts
        ....

it turns out that if gcc sees “printf (“%s\n”, string);” then it assumes that this is exactly equivalent to “puts (string);” and emits the puts code instead. this is without any optimisation enabled. of course, compiling with -ffreestanding causes it to not make this assumption.

of course, puts will crash if you give it a null pointer.

i guess the assumption is probably valid by strict reading of the relevant specifications (printfing a null string is probably said to be “undefined”) but clearly this feature of gcc is in conflict with the “(null)” feature of glibc.

i’ve been working on a vpn client lately. i’ve invented (i think) two pretty simple tricks that are worth sharing.

lockdown

the first thing is a method for locking down a process to not have any filesystem access. the idea is a pretty simple twist on chroot() to an empty directory.

• chdir() to /tmp
• make a directory in /tmp with mkdtemp()
• chroot() to this new directory
• rmdir() the temporary directory (the current directory, unaffected by the chroot, is is still /tmp)
• chdir(“/”) to drop any reference to the old filesystem
• setuid() to a non-privileged account

effectively you now have your process’s root directory as a non-existent directory.

this seems pretty secure. even access(“/”) fails. it also has the added advantage of not requiring a static empty chroot directory (ala /var/run/sshd).

di-semi-default route

one problem faced by vpn clients that want to set the default route is how to manage to ensure packets still get delivered over the normal network to the vpn server (ie: no infinite loop). another problem is how to restore the normal default route when the vpn client exits (or crashes).

the first problem is usually solved by adding an explicit route to the vpn server using the default gateway. for example, if the default gateway on the network was 192.168.0.1 and the vpn server had an address of 209.132.176.176 then one would add a route for 209.132.176.176 gateway 192.168.0.1. no changes here.

the normal method of setting the default route is to delete the current default route (perhaps remembering what it was) and then setting a new route to the network interface created by the vpn program. when the program exits it may restore the old default route. if the program crashes or is kill()ed then you lose.

my approach is to setup something that i’m humourously calling the “di-semi-default route”. essentially, instead of deleting the old default route and replacing it, you add two new half-default routes. say the vpn interface is called vpn0:

• route 0.0.0.0 netmask 128.0.0.0 to vpn0
• route 128.0.0.0 netmask 128.0.0.0 to vpn0

these routes do not conflict with the default route and because the kernel matches routes with tighter netmasks first, they will get matched before the default route. together, they cover the entire ip address space (the first covers all addresses starting with 0-127 and the second covers all address from 128-255). the really nice thing is that when the ‘vpn0′ interface disappears then so do the routes, re-exposing the normal default route.

update: an attentive commenter, craig box, noted that the “usual” method that i use (and is used by software that he packages for ubuntu) is flawed. it fails to take into account the case where the vpn server is on the same local network as the laptop. in this case, it is an error to send the packets to the default gateway.

the method i now use to deal with this is open /proc/net/route and walk through it until i hit a match for the ip of the vpn server (it is sorted by netmask). once i hit a match i only add the new route if the line i hit was the default route.

thanks, craig :)

screw you and your pathetic failed attempt to use your ridiculously trendy device to lock its owners into your sorry excuse for music playing software.

i know you’re afraid of the linux desktop eating away at your precious niche market, but at least you could play fair.

the good guys will always win.