What does this mean? Well, previously, Gentoo already supported various masking reasons (like stable versus staging – the x86 versus ~x86 saga, package.mask’ing – for security reasons or critical bugs, …). Now, a new feature is added: license masking.

By default, Portage accepts all non-EULA licenses. If a package uses a EULA license, you’ll get a failure message stating that the license is ‘masked’.

Now, what good does this do for users? Well, you can now ask Portage only to accept certain licenses (like @FSF-APPROVED, which is a list of all FSF-approved licenses) and deny the installation of others. Nice, isn’t it?

I’ve added information regarding package license states (and the global as well as per-package unmasking support through /etc/portage/package.license) to the Linux Sea document.

My idea here would be to create a script (say “athome.sh”) which returns 0 if you’re at home, and 1 otherwise. The key of the script is that the MAC address of your (default) gateway is unique.

#!/bin/sh

GW=$(/sbin/ip route | awk '/default/ {print $3}');
MGW=$(/sbin/arp -e | grep ${GW} | awk '{print $3}');

if [ "${MGW}" = "00:11:22:33:44:55" ]
then
  exit 0;
else
  exit 1;
fi

With this script, you can then run athome.sh && fetchmail. If you aren’t home, athome.sh will return 1 and the fetchmail command will never be executed. When you are, the command returns 0 and fetchmail is launched.

I’m glad to see that the document is well received. There is still lots of work on it (more excercises, a thorough spelling / grammar check, elaborate on certain topics, …) so stay tuned for further updates. Why are those updates “slow”? Well, let’s say that I use a “fair share scheduling” principle on all my hobbies ;-)

• Information regarding ndiswrapper
• Some information about udev and the symlinks that it creates

The PDF version has been updated as well.

DITA “forces” the technical writer in separating the content of his document in specialized subjects: reference, task or concept, or a specialized version of any of those which you can create/define yourself.

By separating content in those three subjects, you can more easily manage your technical documentation (write concepts as individual topics, tasks as end-user procedures and references for affiliated topics or command information).

Once all these documents are written, you bind them together using a DITA map (a metadocument which holds references to all related concepts/tasks/references) et voila: your documentation is ready.

Well, not really, you need to build it to something end users can read – you can use dita-ot for that. It supports building for Eclipse Infocenter, RTF, XHTML and PDF out of the box.

I also took a different CSS (docbook.css file used by the FreeBSD handbook) as it looks a lot better.