My FSF colleague Brett Smith and I will be making the case against software patents on a panel at the Churchill Club in Mountain View, CA, the evening of February 16th. Hope to see End Software Patents supporters in the audience!
More information: Churchill Club Panel Discussion on Software Patents Free Software Foundation working together for free software
I made smoky grilled tofu (based on the recipe in Veganomicon) on a bed of collard greens and maple-glazed roasted beets and carrots.
CLEMSON, S.C. (CBS/WSPA/AP) A man was struck by an SUV in Clemson Monday evening after police say he was playing a real-life version of the video game "Frogger" on a highway.
As I mentioned recently, the Ubuntu Technical Board is reviewing the most popular topics in Ubuntu Brainstorm and coordinating official responses on behalf of the project. This means that the most popular topics on Ubuntu Brainstorm receive expert answers from the people working in these areas.
This is the first batch, and we plan to repeat this process each quarter. We ll use feedback and experiences from this run to improve it for next time, so let us know what you think.
Power management (idea #24782)
Laptops are now outselling desktops globally, and laptop owners want to get the most out of their expensive and heavy batteries. So it s no surprise that people are wondering about improved power management in Ubuntu. This is a complex topic which spans the Linux software stack, and certainly isn t an issue which will be solved in the foreseeable future, but we see a lot of good work being done in this area.
To tell us about it, Amit Kucheria, Ubuntu kernel developer and leader of the Linaro working group on Power Management, contributed a great writeup on this topic, with technical analysis, tips and recommendations, and a look at what s coming next.
I am going to attempt to summarize the various use profiles and what Ubuntu does (or can do) to prolong battery life in those profiles. Power management, when done right, should not require the user to make several (difficult) choices. It should just work providing a good balance of performance and battery life.IP address conflicts (idea #25648) IP addressing is a subject that most people should never have to think about. When something isn t working, and two computers end up with the same IP address, it can be hard to tell what s wrong. I was personally surprised to find this one near the top of the list on Ubuntu Brainstorm, since it seems unlikely to be a very common problem. Nonetheless, it was voted up, and we re listening. There is a tool called ipwatchd which is already available in the package repository, and was created specifically to address this problem. This seems like a further indication that this problem may be more widespread than I might assume. The idea has already been marked as implemented in Brainstorm based on the existence of this package, but that doesn t help people who have never heard of ipwatchd, much less found and installed it. What do you think? Have you ever run into this problem? Would it have helped you if your computer had told you what was wrong, or would it have only confused you further? Is it worth considering this for inclusion in the default install? Post your comments in Brainstorm. Selecting the only available username to login (idea #6974) Although Linux is designed as a multi-user operating system, most Ubuntu systems are only used by one person. In that light, it seems a bit redundant to ask the user to identify themselves every time they login, by clicking on their username. Why not just preselect it? Indeed, this would be relatively simple to implement, but the real question is whether it is the right choice for users. Martin Pitt of the Ubuntu Desktop Team notes that consistency is an important factor in ease of use, and asks for further feedback.
So in summary, we favored consistency and predictablility over the extra effort to press Enter once. This hasn t been a very strong opinion or decision, though, and the desktop team would be happy to revise it.Icon for .deb packages (idea #25197) Building on the invaluable efforts of Debian developers, we work hard to make sure that people can get all of the software they need from Ubuntu repositories through Software Center and APT, where they are authenticated and secure. However, in practice, it is occasionally necessary for users to work with .deb files directly. Brainstorm idea 25197 suggests that the icon used to represent .deb packages in the file manager is not ideal, and can be confusing. Matthew Paul Thomas of the Canonical Design Team responds with encouragement for deb-thumbnailer, which makes the icon both more distinctive and more informative. He has opened bug 685851 to track progress on getting it packaged and into the main repository.
I have reviewed the proposed solutions with Michael Vogt, our packaging expert. Solution #1 is straightforward, but we particularly like solutions #5 and #10, using a thumbnailer to show the application icon from inside each package.Keeping the time accurate over the Internet by default (idea #25301) It s important for an Internet connected computer to know the correct time of day, which is why Ubuntu has included automatic Internet time synchronization with NTP since the very first release (4.10 warty ). So some of us were a little surprised to see this as one of the most popular ideas on Ubuntu Brainstorm. Colin Watson of the Ubuntu Technical Board investigated and discovered a case where this wasn t working correctly. It s now fixed for Ubuntu 11.04, and Colin has sent the patches upstream to Debian and GNOME.
My first reaction was hey, that s odd I thought we already did that? . We install the ntpdate package by default (although it s deprecated upstream in favour of other tools, but that shouldn t be important here). ntpdate is run from /etc/network/if-up.d/ntpdate, in other words every time you connect to a network, which should be acceptably frequent for most people, so it really ought to Just Work by default. But this is one of the top ten problems where users have gone to the trouble of proposing solutions on Brainstorm, so it couldn t be that simple. What was going on?More detail in GNOME system monitor (idea #25887) Under System, Preferences, System Monitor, you can find a tool to peek under the hood at the Linux processes which power every Ubuntu system. Power users, hungry for more detail on their systems inner workings, voted to suggest that more detail be made available through this interface. Robert Ancell of the Ubuntu Desktop Team answered their call by offering to mentor a volunteer to develop a patch, and someone has already stepped up with a first draft. Help the user understand when closing a window does not close the app (idea #25801) When the user clicks the close button, most applications obediently exit. A few, though, will just hide, and continue running, because they assume that s what the user actually wants, and it can be hard to tell which has happened. Ivanka Majic, Creative Strategy Lead at Canonical, shares her perspective on this issue, with a pointer to work in progress to resolve it.
This is more than a good idea, it s an important gap in the usability of most of the desktop operating systems in widespread use today.Ubuntu Software Centre Removal of Configuration Files (idea #24963) One feature of the Debian packaging system used in Ubuntu is that it draws a distinction between removing a package and purging it. Purging should remove all traces of the package, such that installing and then immediately purging a package should return the system to the same state. Removing will leave certain files behind, including system configuration files and sometimes runtime data. This subtle distinction is useful to system administrators, but only serves to confuse most end users, so it s not exposed by Software Center: it just defaults to removing packages. This proposal in Ubuntu Brainstorm suggests that Software Center should purge packages by default instead. Michael Vogt of the Ubuntu Foundations Team explains the reasoning behind this default, and offers an alternative suggestion based on his experience with the package management system.
This is not a easy problem and we need to carefully balance the needs to keep the UI simple with the needs to keep the system from accumulating cruft.Ubuntu One file sync progress (idea #25417) Ubuntu One file synchronization works behind the scenes, uploading and downloading as needed to replicate your data to multiple computers. It does most of its work silently, and it can be hard to tell what it is doing or when it will be finished. John Lenton, engineering manager for the Ubuntu One Desktop+ team, posts on the AskUbuntu Q&A site with tools and tips which work today, and their plans to address this issue comprehensively in the future. Multimedia performance (idea #24878) With a cornucopia of multimedia content available online today, it s important that users be able to access it quickly and easily. Poor performance in the audio, video and graphics subsystems can spoil the experience, if resource-hungry multimedia applications can t keep up with the flow of data. Allison Randal, Ubuntu Technical Architect, answers with an analysis of the problem and the proposed solutions, an overview of current activity in this area, and pointers for getting involved.
The fundamental concern is a classic one for large systems: changes in one part of the system affect the performance of another part of the system. It s modestly difficult to measure the performance effects of local changes, but exponentially more difficult to measure the network effects of changes across the system.
Our framework, dubbed Mirage, extends the Objective Caml language with I/O extensions and a custom runtime to emit binaries that execute as a paravirtual operating system directly under Xen. The custom run-time is significantly simpler than a general-purpose operating system, with a static single-process 64-bit address space, and "zero-copy" I/O that works directly with the OCaml garbage collector. As a result, Mirage applications exhibit significant performance speedups for I/O and memory handling versus the same code running under Linux/Xen.It's extremely interesting, IMHO. You write your code as a more-or-less normal OCaml program, but you compile it with this special tool-chain, and you boot it directly on ton of Xen, as a domU, without the intermediate OS. The project Git repo is at http://github.com/avsm/mirage, and that links a bit older presentation (http://anil.recoil.org/papers/2010-hotcloud-lamp.pdf) which IMHO is a required read for anyone interested in cloud-related stuff. ICFP proper ICFP, the main conference, is as usual, full of math, designed to scare people away. Err, I mean, designed to tell about new developments in this field. The papers are gathered in this reddit post: http://www.reddit.com/r/haskell/comments/dji4v/papers_from_icfp_2010/. XenServer The paper http://anil.recoil.org/papers/2010-icfp-xen.pdf describes the XenServer project, and more specifically the management interface, which is written entirely in OCaml, by a team of ~10 people. They also have a bit of bin-packing code (http://xenbits.xen.org/xapi/xen-api.hg?file/95b9e4f1b9dd/ocaml/xapi/binpack.ml), but much simpler than the
ganeti-htools project on which I'm working
(no balancing or similar). On the other hand, it is interesting to see
that they committed themselves to write the entire management suite in
OCaml, as opposed to our Python plus just a few bits of Haskell. I
envy them, very much so 
The fun tidbit was how stable they found the OCaml tool-chain. In
three years, they had just one bug related to this (the tool-chain), a
segfault due to wrong formatting code in the handling path of a
seldom-triggered Python exception, which led to a %s to be
translated as is to C code, which meant printf got the wrong
specifiers. So in an OCaml project, a serious bug was due to lack of
type checking in string formatting in a Python component 
Overall I have found interesting parallels between their experience
and my own with Haskell; from is this language/tool-chain stable
enough for use to concerns about using FP for a significant project
(but of course, orders of magnitude difference between their case and
mine).
Super-compilation
There were two papers on this topic;
one at ICFP
proper and
one
at the Haskell symposium.
If I understood things right, super-compilation is the opposite of lazy
evaluation. But let's start a bit back.
First, programs written in a functional languages contain many pure
function. Pure functions, being side-effect-free, exhibit many
interesting properties, and one of them is that they permit decoupling
of the computation of a value from the declaration of such computation.
One technique derived from this is lazy computations. Lazy computation
means that even though you write y = sin(x) + 1, the actual call to
sin and the increment is not actually done until you need the
actual value of y (not just for storing it in y, that is).
Super-compilation is the opposite of this. While laziness postpones
doing a computation to as late as possible, in the hope it won't be
needed at all, super-compilation runs the actual computation way ahead
of time, even before the program starts, that is at compile
time. Since programs use input data at runtime, which is not known at
compile time, the trick is to pre-compute as much as possible at this
stage, given incomplete information; and the papers showed that it's
possible to pre-compute much more than you'd usually believe.
Optimising compilers already do some form of CAF (constant applicative
form) optimisation, but the techniques presented in both papers are
going beyond simple CAFs. The details are in the papers, and are
complicated, but one simple example is converting this:
ones = map inc [1..]
ones = [2..]
[from the Orc literature] we might wish to contact two airlines simultaneously seeking price quotes. If either quote comes back below a threshold price, say $300, then let's buy a ticket immediately. On the other hand if both quotes exceed the threshold, then buy the cheapest ticket. Additionally, buy a ticket if the other airline does not give a timely quote, or notify the user if neither airline provides a timely quote.Now, in my experience, this would require manual management and synchronisation of threads, and for example in Python the early abort of querying the price from airline B if airline A returned a good price would be non-trivial; in addition, adding two extra conditions would be again not a simple composition of rules. In Orc however, it takes all of 10 lines of code to do this, safely. I won't copy the code here, see the paper for details, or the API docs. And the best part is, this is just a
cabal install orc away! I'll be
very interested to see how I can use this in practice, as it is seems
indeed a very powerful library.
Nikola: Embedding Compiled GPU Functions in Haskell
Interesting
project. Using
almost 100% Haskell code, and it marshalls the data to/from the GPU;
in the example given, the performance is as good as hand-written CUDA
code of course, this doesn't happen in all cases. It it's interesting
how they manage to compile the GPU-related code to actual object code
at Haskell compile time, which makes it transparent for the user.
Given the prevalence of high-speed GPUs, this could be a nice way to
utilise them without learning yet another language (or two, since
NVidia and ATI have different stacks).
They've also developed some interesting techniques (e.g. manual
control of sharing, to prevent inlining) as part of their project.
Scalable Event Handling for GHC
This is a
paper
co-authored by Johan Tibell of Google Switzerland and Bryan O'Sullivan
of Real World Haskell fame.
Very interesting serving 20K QPS from a Haskell process while having
16K+ idle clients connected:
[ ] the performance of the epoll back end does not begin to fall off significantly until we have 50,000 idle connections open.The talk started with the idea that we're on the path to serving 10 clients from a single machine, and how to improve Haskell's I/O manager to achieve (almost) 10 concurrent clients. The slides (which I don't have a link for) were a bit more cool on numbers than the paper. Oh, and this will come with GHC 7.0, for free
An LLVM Backend For GHC
The eternal fight to get better than the C backend in other words, to
not have to translate Haskell to C It is interesting to see how many
languages target LLVM nowadays, as opposed to plain old C via gcc. A
fun trivia item was that, according to the author, there are many
features in LLVM that are not actually used by 90% of the languages
targeting it (e.g. the garbage collector) (if I heard correctly in the
talk).
The results are interesting, although not too much overall speedup is
gained; this seems to be due to the hard-to-optimise Cmm intermediate
language inside GHC. In any case, a few benchmarks get more than 10%
speedup, even in the current form.
This will also come in GHC 7.0, although not enabled by default;
probably needs to mature some more
Conclusion
I've enjoyed this conference a lot, and I've learned a lot from
it. Given that many of the talks are about research topics, it's
harder to apply them in day-to-day work, but I think the pay-offs will
be long term rather than immediate.
As this year's admin, I wrote up the following summary which has now been
posted at the R site in the appropriate slot. My thanks to
this year's students, fellow mentors and everybody else who helped to make it
happen.
f:R^m -> R^n, through Automatic Differentiation (AD). Numerical evaluation of derivatives has widespread uses in many
fields. rdx will implement two modes for the computation of derivatives, the Forward and Reverse modes of AD, combining
which we can efficiently compute Jacobians and Hessians. Higher order derivatives will be evaluated through Univariate
Taylor Propagation.
Delivered:
Two packages
radx: forward automatic differentiation in R and
tada: templated automatic differentiation in C++ were created; see
this blog post for details.
Last modified: Wed Sep 22 19:39:43 CDT 2010
I spent last week at the Ubuntu Developer Summit in Belgium, where we kicked off the 10.10 development cycle.
Due to our time-boxed release cycle, not everything discussed here will necessarily appear in Ubuntu 10.10, but this should provide a reasonable overview of the direction we re taking.
Presentations
While most of our time at UDS is spent in small group meetings to discuss specific topics, there are also a handful of presentations to convey key information and stimulate creative thinking.
A few of the more memorable ones for me were:
A few hours ago, I sent the following to both the R development list and the informal R / GSoC list:
Date: Mon, 26 Apr 2010 15:27:29 -0500
To: R Development List <r-devel>
CC: gsoc-r <gsoc-r>
Subject: R and the Google Summer of Code 2010 -- Please welcome our new students!
From: Dirk Eddelbuettel <edd>
Earlier today Google finalised student / mentor pairings and allocations for
the Google Summer of Code 2010 (GSoC 2010). The R Project is happy to
announce that the following students have been accepted:
Colin Rundel, "rgeos - an R wrapper for GEOS", mentored by Roger Bivand of
the Norges Handelshoyskole, Norway
Ian Fellows, "A GUI for Graphics using ggplot2 and Deducer", mentored by
Hadley Wickham of Rice University, USA
Chidambaram Annamalai, "rdx - Automatic Differentiation in R", mentored by
John Nash of University of Ottawa, Canada
Yasuhisa Yoshida, "NoSQL interface for R", mentored by Dirk Eddelbuettel,
Chicago, USA
Felix Schoenbrodt, "Social Relations Analyses in R", mentored by Stefan
Schmukle, Universitaet Muenster, Germany
Details about all proposals are on the R Wiki page for the GSoC 2010 at
http://rwiki.sciviews.org/doku.php?id=developers:projects:gsoc2010
The R Project is honoured to have received its highest number of student
allocations yet, and looks forward to an exciting Summer of Code. Please
join me in welcoming our new students.
At this time, I would also like to thank all the other students who have
applied for working with R in this Summer of Code. With a limited number of
available slots, not all proposals can be accepted -- but I hope that those
not lucky enough to have been granted a slot will continue to work with R and
towards making contributions within the R world.
I would also like to express my thanks to all other mentors who provided for
a record number of proposals. Without mentors and their project ideas we
would not have a Summer of Code -- so hopefully we will see you again next
year.
Regards,
Dirk (acting as R/GSoC 2010 admin)
Yay! The dlr-languages package has been migrated to testing, which means that it will be included in squeeze, the next release of Debian. Jo has uploaded the -2 version and it is now in sid. This version addresses the issues brought up in the Ubuntu Feature Freeze exception (FFe) bug, so I expect that it will be accepted shortly. Still lots of ifs , but this is pretty exciting for me, since this is my first debian package, and I ve been intending to get it in for over two years.
I m not just sitting on my hands while this happens. I ve been working with Ivan, Ankit, Dino and Michael to get the next version of the package put together. I m currently merging Ivan s latest branch into the changes I ve made for DFSG compliance. Dino recommended that the next release include IronRuby 1.0 and IronPython 2.6.1, which should be released by upstream around the middle of April.
We haven t done much work on keeping the continuous integration (CI) machines online, and there haven t been any new builds since November of 09. I should set Nagios to remind us when things get off track or something. The recent acceptance of the DLR into Debian and our intention to get the next release produced has inspired me (and maybe others) to get things back up.
Ivan and I put a couple of Hudson instances up recently that you can reach via hudson-windows.colliertech.org and hudson-linux.colliertech.org. The linux instance is dropping new builds of IronRuby to http://dlrci.colliertech.org/ironruby/. I expect we can tweak the build script a bit and have it also produce IronPython builds. This would hypothetically drop the builds to http://dlrci.colliertech.org/ironpython/.
Ivan mentioned that we may get CNAME records which would activate the windows-builds.ironruby.net and linux-builds.ironruby.net hosts as well.
Note that these builds are being produced from the linux branch of git://github.com/casualjim/ironruby.git
Thanks for your work on this, Ivan!
Ivan put up a hudson server on our winders box. Ankit helped me figure out the IronRuby xbuild build problems. I should probably try it on IronPython, too. I sent the ironruby-core list a patch to fix some case sensitivity issues. Some time in the near future, I m going to get together a bug report for the compiler and send it off to Marek. But I m tired and Scarlet s got a friend doing the sleep-over thing tonight.
So. Later ;)
P.S., can you believe that nobody registered a11y.com before now? Crazy talk.
P.P.S., does anyone out there in gnome land have a ruby app they want to test for compatibility with IronRuby?
I m happy to announce that after the filing of an Intent to Package and nearly 2 years of work, IronRuby 0.9, IronPython 2.6b2, and the DLR are now in Debian. To my knowledge, this is the first package in Debian with direct and active upstream support from Microsoft.
Kudos for this release go to Jo Sheilds (package sponsorship & mentoring), Mirco Bauer (package sponsorship & mentoring), Matthias Klose (IronPython package review), Ivan Porto Carrero (IronRuby build/test support), Jim Deville (IronRuby build/test support), Jimmy Schementi (upstream point of contact @ Microsoft), Dino Viehland (IronPython build/test support), Michael Foord (IronPython build/test support), Marek Safar (mono c# compiler support), Ankit Jain (xbuild support), the folks on OFTC s #debian-cli, Freenode s #ironruby and GimpNet s #mono, and the folks on the IronRuby and IronPython mailing lists.
This is my first package in Debian, too. I m pretty ecstatic ;)
Finally, it happened! I became a Debian Developer!
I wish to thank everybody involved in this process: from those who helped me in my initial packaging efforts, to who actually created the account.
Many thanks to the pkg-perl team for accepting newbies and helping them: props to Damyan Ivanov, Gregor Herrmann, Gunnar Wolf!
Thanks to Debian-Med and Debian CLI: they always believed in me, and I had a great time in these teams. A special thanks goes to Andreas Tille, who advocated my NM candidature.
Thanks to my two AMs, Bart Martens and Bernd Zeimetz. Even if my NM was long, difficult and not so flawless, it all went good, at the end 
.
A special thanks to Enrico Zini: he was the first DD signing my GPG key, thus allowing me to have more "rights" (being a DM), and experience some more responsibility than I previously had. Thanks to his "Become a DD. NOW!" right after checking my ID in Palermo -- Enrico, it finally happened!
Thanks to Christoph Berg, Ron Lee, and Stephen Gran, which handled the final steps of the overall process.
And now, dapal is here to break the world. Be warned!
xmodmap has long
been the only way to modify the keyboard map of the X server, short
of the complex configuration daemon approaches used by the large
desktop managers, like KDE and GNOME. But it has always been a
hack: it modifies the X keyboard map and thus requires a baseline
to work from, kind of like a patch needs the correct context to be
applicable.
Worse yet, xmodmap weirdness required me to
invoke it twice to get the effect I wanted.
When the recent upgrade to X.org 7.4 broke larger
parts of
my elaborate xmodmap configuration, I took the time to finally
ditch xmodmap and implement my modifications as proper
xkb configuration.
#xorg/irc.freenode.org IRC channel to get
me started.
The other resource worth mentioning is Ivan Pascal s collection of XKB
documents, which were instrumental in my gaining an
understanding of xkb.
And just as I am writing this document, Debian s X Strike Force
have published their Input
Hotplug Guide, which is a nice complement to this very document
you are reading right now, since it focuses on auto-configuration
of xkb with HAL. The default
xkb configuration comes with a lot of flexibility, and
often you don t need anything else.
But when you do, then this is how to do it:
xkbcomp, which can also be used to dump the currently
installed map into a file. So, to get a bit of an idea of what
we ll be dealing with, please run the following commands:
xkbcomp $DISPLAY xkb.dump
editor xkb.dump
xkbcomp xkb.dump $DISPLAY
xkb work
according to my needs. I sought a way in which I could use as much
as possible of the default configuration, and only place
self-contained additional snippets in place to do the things I
wanted done differently.
setxkbmap and rule files
Thus began my voyage into the domain of rule files. But before
we dive into those, let s take a look at setxkbmap.
Despite the trivial invocation of e.g. setxkbmap us to
install a standard US-American keyboard map, the command also takes
arguments. More specifically, it allows you to specify the
following high-level parameters, which determine the sequence of
events between key press and an application receiving a KeyPress
event:
setxkbmap -model thinkpad -layout us -variant intl -option grp:win_switch
-print to the above command, it will
print the keymap it would install, rather than installing it:
% setxkbmap -model thinkpad -layout us -variant intl -option grp:win_switch -print
xkb_keymap
xkb_keycodes include "evdev+aliases(qwerty)" ;
xkb_types include "complete" ;
xkb_compat include "complete" ;
xkb_symbols include "pc+us(intl)+inet(evdev)+group(win_switch)" ;
xkb_geometry include "thinkpad(us)" ;
;
-option grp:win_switch argument has been turned
into an additional include group(win_switch) on the
xkb_symbols line, just like the model, layout, and
variant are responsible for other aspects in the output.
xkbcomp dumped
into the xkb.dump file we created earlier. Upon closer
inspection, it turns out that the dump file is simply a
pre-processed version of the keyboard map, with
include instructions exploded.
xkb_keymap
stanza by setxkbmap is actually governed by a rule
file. A rule is nothing more than a set of criteria, and what
setxkbmap should do in case they all match. On a
Debian system, you can find this file in
/usr/share/X11/xkb/rules/evdev, and
/usr/share/X11/xkb/rules/evdev.lst is a listing of all
available parameter values.
The xkb_symbols include line in the above
xkb_keymap output is the result of the following rules
in the first file, which setxkbmap had matched (from
top to bottom) and processed:
! model layout = symbols
[...]
* * = pc+%l(%v)
! model = symbols
* = +inet(evdev)
! option = symbols
[...]
grp:win_switch = +group(win_switch)
xkb_symbols
include line quoted above, starting from the setxkbmap
command line. I ll reproduce both for you for convenience:
setxkbmap -model thinkpad -layout us -variant intl -option grp:win_switch
xkb_symbols include "pc+us(intl)+inet(evdev)+group(win_switch)" ;
group(win_switch) in the symbols column simply
references the xkb_symbols stanza named
win_switch in the symbols file group
(/usr/share/X11/xkb/symbols/group).
Thus, the rules file maps parameters to sets of snippets to
include, and the output of setxkbmap applies those
rules to create the xkb_keymap output, to be processed
by xkbcomp (which setxkbmap invokes
implicitly, unless the -print argument was given on
invocation).
It seems that for a criteria (option, model, layout, ) to be
honoured, it has to appear in the corresponding listing file,
evdev.lst in this case. There is also
evdev.xml, but I couldn t figure out its role.
Mod4, which can be
used e.g. to control the window manager.
~/.xkb/symbols/xkbtest and add two stanzas to it:
partial alphanumeric_keys
xkb_symbols "dashes"
key <AE11>
symbols[Group2] = [ endash, emdash ]
;
;
partial modifier_keys
xkb_symbols "caps_mod4"
replace key <CAPS>
[ VoidSymbol, VoidSymbol ]
;
modifier_map Mod4 <CAPS> ;
;
grp:win_switch earlier, which
told xkb that we would like to use the windows keys to
switch to group 2. In the custom symbols file, we now simply define
the symbols to be generated for each key, when the second group has
been selected.
Key <AE11> is the hyphen key. To find out the
names of all the other keys on your keyboard, you can use the
following command:
xkbprint -label name $DISPLAY - gv -orientation=seascape -
partial because it is
not a complete keyboard map, but can only be used to augment/modify
other maps. I also declared it alphanumeric_keys to
tell xkb that I would be modifying alphanumeric keys
inside it. If I also wanted to change modifier keys, I would
also specify modifier_keys.
The rest should be straight-forward. You can get the names of
available symbols from keysymdef.h
(/usr/include/X11/keysymdef.h on a Debian system,
package x11proto-core-dev),
stripping the XK_ prefix.
VoidSymbol).
The important aspect of the second stanza is the
modifier_map instruction, which causes the key to
generate the Mod4 modifier event, which I can later
use to bind key combinations for my window manager (awesome).
setxkbmap -print output of the keyboard map you would
like to use as a baseline into ~/.xkb/keymap/xkbtest,
and append snippets to be included to the xkb_symbols
line, e.g.:
"pc+us(intl)+inet(evdev)+group(win_switch)+xkbtest(dashes)+xkbtest(caps_mod4)"
xkbcomp, it will fail because it cannot find the
xkbtest symbol definition file. You have to let the
tool know where to look, by appending a path to its search list
(note the use of $HOME instead of ~,
which the shell would not
expand):
xkbcomp -I$HOME/.xkb ~/.xkb/keymap/xkbtest $DISPLAY
xev to verify the results, or just type
Win-Hyphen into a terminal; does it produce ?
By the way, I found xev much more useful for such
purposes when invoked as follows (thanks to Penny for the idea):
xev sed -ne '/^KeyPress/,/^$/p'
xev does not give any indication of
which modifier symbols are generated. I have found no other way to
verify the outcome, other than to tell my window manager to do
something in response to e.g. Mod4-Enter, reloaded it, and then
tried it out.
setxkbmap spit out the
right xkb_keymap and could install the new keyboard
map with xkbcomp, like so:
setxkbmap -I$HOME/.xkb [...] -print xkbcomp -I$HOME/xkb - :0
A crowd of 2m or more is making its way to Washington, DC, to witness the inauguration of Mr Obama. Billions more will watch it on television. [link]Every issue, I see this sort of thing all over. An estimate, or an opinion, presented as unquestioned fact, sometimes pretty clearly wrong or misleading. For weeks before Jan. 20, and even the day before, the widely-reported word from officials was that they had no idea what to expect, but if they had to guess, they d say that attendance would be between 1-2 million. In the end, the best estimates have placed attendance at 1.8 million. Would it have killed them to state that most estimates were more conservative, and to cite the source of their particular estimate? That s all I want, really, when they do things like this. I knew going into it that the magazine (to American eyes) essentially editorializes throughout, and I don t have a problem with that. But it engages in over-generalization far too often and that s just when I catch it. This was just a quick example from the first article I read in this issue; it s more blatant other places, but quite honestly I m too lazy to go look some more examples up at this hour. I do remember, though, them referring to members of Obama s cabinet as if they were certain to be, back before Obama had even announced their pick, let alone their confirmation hearings happening. One of my first issues of The Economist had a lengthy section on the global automobile market. I learned a lot about how western companies broke into markets in Asia and South America. Or at least I think I did. I don t know enough about that subject to catch them if they are over-generalizing again. The end result is that I read each issue with a mix of fascination and distrust; the topics are interesting, but I can never really tell if I m being given an accurate story. It often feels like the inside scoop, but then when I have some bit of knowledge of what the scoop is, it s often a much murkier shade of gray than The Economist s ever-confident prose lets on. Don t get me wrong; there are things about the Economist I like. But not as much as with the New Yorker or the Atlantic, so I ll let my subscription lapse after 6 months but keep reading it until then.
Next.