I was recently pointed to a project by Philips to design a home that was more in tune with environmental issues - composting, waste recycling etc, but all done with a modern urban design brief.
One of the items in this collection was a beehive, and its an amazingly beautiful piece of design. But sadly, it doesn’t appear to have had any input from those involved in beekeeping, especially not in the modern beekeeping environment, or those who understand bee behaviour.
I’ve tried to list what I think are the main issues with this design, from the perspectives of both bee and beekeeper. There may be some which the designers have thought round, but they don’t seem immediately apparent… and of course there may be more issues that don’t spring to mind as I write this!
Of course, its always a noble aim to try to get more people interested in beekeeping, and to promote bee numbers and bee health at a time when colonies are under threat. However, this particular example shows how the practicalities of some environmental issues are often misunderstood by those seeking to help - in turn creating more problems than they solve.
It took me ages to figure out how to do this, probably because I’m used to thinking in a facebook-like way.
The solution is that you just have to remove the contact from all aspects - on the home page mouse-over an aspect at the top-left and a pen icon will appear. Click on this and you will see a window with all your contacts, with a green tick next to those in this aspect. Click on the tick and it will turn to a grey plus. Repeat for all your aspects, and when the user isn’t in any of them, they’ll stop appearing in your stream.
It’d be nice to have a ‘remove contact’ button that does this for all your aspects, but this will do for now!
While this at the start seems like a simple challenge, it ended up being much harder than I anticipated.
Firstly, I had naively assumed that there would be a gconf key for this - and there is, though it has the annoying problem of removing shutdown and logout from the Settings Menu.
So my workaround was to firstly enable this gconf option, and then add back a logout icon onto the system tray.
The gconf option is in
/apps/panel/global/disable_log_out
on some versions of Gnome, or in
/desktop/gnome/lockdown/disable_log_out
in other versions.
Once this is set, your System menu will no longer have the Log Out or Shutdown options shown.
Now, you need to add a system tray applet to give users a logout button.
#!/usr/bin/python
importsubprocessimportgtkdefclicked(self):subprocess.Popen(["/usr/bin/gnome-session-save","--logout-dialog"])icon=gtk.StatusIcon()icon.set_from_file("/usr/share/icons/oxygen/22x22/actions/system-shutdown.png")icon.set_tooltip("Logout from Linux")icon.connect('activate',clicked)gtk.main()
Note that the syntax for gnome-session-save and the icon chosen might differ on your system.
Next, we need to ensure that this applet is run at login, by putting a desktop link into /etc/xdg/autostart/logout-applet.desktop:
You should now see an icon on the start menu when you log in, which when clicked shows you the logout dialog.
Of course, there are still ways around this if a user really wants to shut down a computer. Without more restrictions on the execution of the shutdown/reboot commands, or polkit restrictions, users can still call a shutdown.
However, there is one way which they might try to switch off a machine ‘accidentally’ - and that is by pressing the power button. There are 2 places that handle ACPI power button events - the ACPI stack, and gnome-power-manager.
To handle ACPI:
Replace /etc/acpi/events/power.conf with:
event=button/power.*
action=/bin/true &
Then run
killall -SIGHUP acpid
Of course you can always replace /bin/true with a script of your choice, if you want to for example log out the user, or display a warning message about pushing the power button!
Finally, you need to tweak gnome to ignore power button events, or it will throw up the shutdown dialog.
Back to gconf - set the following key to nothing:
/apps/gnome-power-manager/buttons/power
You might also want to investigate many of the other ACPI events that live here and deal with them accordingly.
We have begun investigating Spice, an open-source accelerated ‘remote desktop’ system for connecting to our virtual machines. so far it appears to be extremely powerful and fits our needs well.
We are running a linux computing lab, and want to run a Windows virtual machine, accessed by Spice, only by the person currently logged in on the console, though there may be multiple users logged in remotely.
However, one of the problems with Spice is that it lacks in authentication methods. The only method available to authenticate from the client appears to be to set a password. However, this is set via qemu/libvirt at the time of guest instantiation, meaning that it is difficult to keep a guest running permanently, and allow only a single user (out of many on that system) to access it, since the password would be known to everyone.
We used the following tools to solve this problem - iptables and the console.handlers locking mechanism found in /etc/security.
Firstly, we configure spice to only listen on the localhost interface (127.0.0.1) on port 5930. (Details are in the Spice documentation on how to do this).
Next, we use the iptables to set a ‘default deny’ to that port:
iptables -A OUTPUT -o lo -p tcp --dport 5930 -j REJECT
Next we write 2 scripts - allow-user and deny-user which add (and remove) a new rule using the user module in iptables:
#allow-user
iptables -A OUTPUT -o lo -p tcp -m owner --uid-owner $1 --dport 5930 -j ACCEPT
These scripts could be triggered by a variety of methods, depending on what action you want to cause access to Spice to change. In our case, we want to trigger access based on console login.
We edit /etc/security/console.handlers to execute these 2 scripts:
/usr/bin/allow-user lock user
/usr/bin/deny-user unlock user
The lock/unlock flag signifies on which action to run this script (login=lock, logout=unlock). The usersetuid flag is also passed. (see man console.handlers for more info).
Now when a user logs in on the console, an ACCEPT rule will be added granting them access to the port on which Spice is listening. Secondary console logins (e.g a second user dropping to a VT and logging in) won’t trigger the handler scripts.
This time of year is one I enjoy the most - the time when the elder is in bloom - first flowers with a delicate, perfumed taste, followed by elderberries for a rich, fruity flavour.
So a simple start to the season - elder flower fritters. These are shallow fried ones, akin to scotch pancakes or blini, as opposed to the other way of doing them - dipping the whole heads into a tempura-like batter and frying. I’ve found the green stems, even in small quantities can give a sour or bitter taste, so always prefer to put the loose flowers directly into the batter.
The next tasty recipe based on elderflowers is cordial - there are literally hundreds of variations on this drink, but I have tweaked this one to suit my own tastes - not as sickly sweet, and without the lemon to let the elderflower flavour shine through. Feel free to play about with it!
The easiest way to get the petals off the stalks is to place all the heads in a black bin bag, tie it ‘inflated’ with lots of air-space, and hang up for 24 hours. A vigorous shake (taking care not to split the bag!) and almost all the flowers will drop off the stalks, ready to be used.
I make this recipe in large quantities so it sees me through to the elderflower season the next year - it also makes it easier when adding a campden tablet as I don’t need to try to divide it up.
I had made up 3 new colonies from Sarah in May, and recent inspections hadn’t looked favourable - no sign of laying queens in 2, and a vanished colony in the third - there appear to have been 2 queen hatches, both of which had virgin swarmed with the flying bees, leaving only a cupful of worker bees, waiting to be merged back onto Sarah.
I’d expected the other 2 to have laying queens nearly 3 weeks ago, and after seeing no sign of eggs or queens last Saturday, I stuck in new eggs and queen cells from Sarah (who is showing signs of wanting to swarm) and left them to it.
Of course, today I find both packed with eggs and larvae, and the new queen cells gone. I was reminded that all of the parent queens were slow to start laying, so perhaps this is just a trait of this line. At least it now means things are back on track - though Sarah looks to want splitting again some time this week as she keeps throwing up new queen cells, even with plenty of space with the recent merge.
Coming back to growing my own fruit and veg again, I’m reminded of the hassles of having a glut of certain crops at certain times of year. This post, and hopefully others following it, will be part of a series of recipes I’ve used to try and work my way round that glut… starting with Radishes!
Yes, this probably doesn’t count as a good idea… but sometimes you have to use bash to do these kind of things - so I might as well explain how I did it. Most of this work was based on someone else’s hints and tips, but I’m afraid I can’t find the references any more…
The concept is quite simple. Launch a series of jobs in parallel, in the background, recording the PID of each one. Also run a timer function, which when it times out sends SIGALRM to the parent. the parent has a trap, listening for the signal, and if it receives it, it actively kills all its children. Otherwise, the children exit cleanly, and the parent tidies up.
#!/bin/bash #Time to wait for stuck processes before killing them export ALARMTIME=30
PARENTPID=$$
exit_timeout(){echo"Alarm signal received : killing all children"for pid in${CHILDPIDS[@]};do
kill$pid >/dev/null 2>&1
done
exit}CHILDCOUNT=0
for server in alice bob charlie;do
CHILDCOUNT=$CHILDCOUNT+1
echo"Running command on $server:"
ssh $server"uname -a" &
CHILDPIDS[$CHILDCOUNT]=$!done#Prepare to catch SIGALRM, call exit_timeout trap exit_timeout SIGALRM
#Sleep in a subprocess, then signal parent with ALRM (sleep$ALARMTIME;kill-ALRM$PARENTPID) &#Record PID of subprocess ALARMPID=$!#Wait for child processes to complete normally wait${CHILDPIDS[*]}echo"Alarm never reached, children exited cleanly."#Tidy up the Alarm subprocess kill$ALARMPID
