I have long been in Bruce Schneier s camp, thinking that the TSA is a joke: nothing but security theater. A few recent examples come to mind:

• In the famous recent event, a man refuses to go through the backscatter machine, and then refuses to be groped. They tell him he can t board the plane, take a report, and say he is free to leave. Then they say he has to go back to the screening area and be screened before leaving the airport, despite his wishes. Obviously they don t believe he really had a bomb, because if he did, would they really want him in a cramped area surrounded by hundreds of civilians? So why make him go back?
• Reading about these screenings, one of my thoughts was, I sure wouldn t want to have my kids have to go through that, or a millimeter wave machine whose health effects are completely unknown! Then I read the TSA s bulletin, intended to calm people like me: don t worry, kids under 13 will never be patted down. OK TSA, so either your patdowns are completely ineffective or you are so naive that you think that nobody under 13 could ever be an attacker. If the latter, why fuss with making them go through security in the first place?

I don t get it. They have been completely reactionary since they began. They have a complete failure of institutional imagination. Something happens, and then a new rule comes out to prevent the thing that everybody is now expecting. And what happens about the thing that people aren t expecting yet? Nothing. So we now have to take off our shoes because one guy tried to use them for something nefarious. OK, fine, but the next guy is probably going to try something other than shoes. Which is why, I m sure, many people are pointing out that the TSA is over-reliant on technology and device detection and completely underemphasizing evildoer detection as, we are repeatedly reminded, the Israelis excel at. The TSA s attempt to remedy that was foolish at best, and, according to a recent report, not grounded in science. Which is why I am heartened that, almost a decade after 9/11, Americans are starting to let go of their fear and be ready to reclaim some sense of intelligence at the security line. The fact that politicians think there is something to be gained by being tough on TSA s invasive screening procedures, rather than risk looking soft on terrorism, is evidence of this. So, what I haven t yet worked out is this: What gives, TSA? Are they:

• Stupid or incompetent? Do they really, deep down, actually believe it when they say this is excellent, best in the world security? Do they really not see how stupid it is?
• Afraid? Are they afraid that if they don t deploy every possible technological solution, and then there is an attack, that they will be fired? (This surely doesn t explain the botched behavioral screening program though)
• Pressured? Are the vendors of security technology getting at them directly or indirectly via politicians forcing them to deploy this stuff?
• Apathetic? They simply have a job, don t really care about it at all, and are just doing the minimum necessary to bring home a paycheck?
• Stuck in a culture of rigidity? Unable to come up with any sort of process that gives screeners the ability to use discretion, they insist that everyone be treated equally and that those that aren t are treated differently on a completely random basis. Some bureaucrats probably spent years on the plan, which is totally useless.

(Note: this criticism is directed mostly at the upper levels of TSA management; I do not believe the people most of us see have the ability to change the system, even if they wanted to.) One final word: I also get annoyed at all the people that grouse at the TSA checking 80-year-olds as thoroughly as everyone else. An 80-year-old could be wearing a hidden device just as much as anyone else could, and if we don t check them, then someday they probably will. The key is to be smart about who we check carefully. Use data, behavioral analysis, simple questioning, etc it works, and is a lot better than exempting people under 13 and over 80 from screening on arbitrary grounds. Also, it might help anyone with a blurry groin. And it might just save a bunch of us from getting cancer.

You probably all know du from GNU Coreutils. But there s more than just du around in Debian. du xdu First there is xdu, which displays du output piped into it graphically, even if du is running on some other box with the output coming over an ssh connection:

$ du   xdu
$ ssh server-without-xlibs du some-directory   xdu

Clicking on any directory except the topmost zooms into that directory. Pressing n sorts by size and s toggles the display of sizes in numbers. xdiskusage xdiskusage seems to be a fork of xdu or at least shares some GUI code with it as it looks and behaves quite similar. But the GUI looks nicer, more modern and you don t need to pipe the output of du into it. It collects the disk usage of a given directory itself. ncdu And then there is ncdu, the ncurses du . (It has nothing to do with the German party CDU . You can easily remember that as Not CDU . ;-) It shows you the disk usage of files and subdirectories in the given directory already sorted by size, optionally displaying also ascii art bars and/or percentage (by pressing g one or more times) for better comparision between file and directory sizes. And all easily and intuitively to navigate in an ncurses text-mode user interface.

ncdu 1.3 ~ Use the arrow keys to navigate, press ? for help
--- /home/abe/debian/webwml ------------------------------------
                             /..
   70.2MB [20.0% ##########] /english
   40.9MB [11.7% #####     ] /french
   35.0MB [10.0% ####      ] /german
   30.2MB [ 8.6% ####      ] /swedish
   26.6MB [ 7.6% ###       ] /japanese
   23.2MB [ 6.6% ###       ] /spanish
   21.5MB [ 6.1% ###       ] /portuguese
   19.8MB [ 5.6% ##        ] /danish
   15.2MB [ 4.3% ##        ] /italian
    9.8MB [ 2.8% #         ] /russian
    8.8MB [ 2.5% #         ] /polish
    6.5MB [ 1.8%           ] /finnish
    5.8MB [ 1.6%           ] /chinese
    4.4MB [ 1.3%           ] /catalan
    4.3MB [ 1.2%           ] /dutch
    3.7MB [ 1.0%           ] /korean
    3.4MB [ 1.0%           ] /ukrainian
    3.0MB [ 0.9%           ] /czech
    2.6MB [ 0.7%           ] /croatian
    2.6MB [ 0.7%           ] /bulgarian
    2.4MB [ 0.7%           ] /norwegian
    1.7MB [ 0.5%           ] /hungarian
    1.6MB [ 0.4%           ] /romanian
    1.2MB [ 0.3%           ] /greek
    1.2MB [ 0.3%           ] /turkish
    1.1MB [ 0.3%           ] /slovak
  576.0kB [ 0.2%           ] /Perl
  556.0kB [ 0.2%           ] /arabic
  428.0kB [ 0.1%           ] /lithuanian
 Total disk usage: 351.1MB  Apparent size: 351.1MB  Items: 70653                                                      

And yes, I uploaded the two screenshots shown above also to screenshots.debian.net as both tools had no screenshots available yet.

Most of my talks are either talks about commandline basics (Commandline Helpers about GNU Coreutils and Findutils usage; Understanding Shell Quoting) or collections of small tips and tricks, e.g. about SSH, History Expansion, or commandline tools. Valentin Haenel called this second type of talks nugget talks . I like that term. My newest talk (German only so far, next occasion at the LUGS meeting in Zurich on 16th of December 2010) is such a nugget talk and is about useful but unknown tools. While preparing that talk I noticed that the amount of neat but less known tools I collected for possible inclusion into that talk would be enough for a whole day or so. I noticed that I ll never be able to give a talk about all that stuff. To not letting these tips rot in that file uncommented, I decided that I ll write (more or less) short blog postings about these tools, similar to and inspired by Myon s blog postings about Cool Unix Features as well as the no more existing or at least broken Debian Package of the Day and Debian Package a Day. While Myon mostly posted long-time but still unknown features, my postings will mostly cover useful but unknown packages available in Debian and most debian-derived distributions like grml and Ubuntu. Some postings may also just highlight some features of common tools or packages like e.g. GNU Coreutils. You can subscribe to these tips via RSS or just view all of them in your web browser at http://noone.org/blog/English/Computer/Debian/CoolTools/.

i've been on an IPv6 kick recently, getting dual-stack systems up and working for a bunch of folks.I'd like to make some of these services reachable by IPv6-only clients. this suggests that i need a range of details sorted out, but i think the one piece left for me is the glue records for the nameservice. i use in-bailiwick nameservers for DNS where possible, which means i want mandatory glue records. that is, the primary namserver for example.org is probably something like ns0.example.org, which means that the org nameservers themselves need to store not only the NS record, but an A record that corresponds to the name pointed to by the NS. But for IPv6-only clients that do their own name resolution, i need AAAA glue records, and i haven't yet found a registrar that will push AAAA glue records for the same names as the existing A glue into the org zone. Do you know of a registrar that will do this?I've tried:

dotster

Dotster seems to only allow IPv4 glue to be entered on their Register Nameserver config page (needs a dotster login to see it). They haven't yet yet responded to my query through their support web form about submitting AAAA glue

gandi

gandi at least offers the opportunity to enter AAAA glue, but apparently can't let me have both AAAA and A glue for the same name. A note to their support team got me a response that this is planned for Q1 or Q2 of 2011.

Any suggestions for reasonable registrars that offer this today? Am i being silly in wanting AAAA and A glue for the same names? i note that the root zone and the org zone both offer A and AAAA records for each of their dual-stack nameservers. You can check for yourself:

 dig @a.root-servers.net ns org
 dig @a.root-servers.net ns .

if i don't go for dual records, i could instead use gandi and go with distinct names for the v6 and v4 servers, like this:

;; QUESTION SECTION:
;example.org.				IN	NS
;; AUTHORITY SECTION:
example.org.      172800	IN	NS	a.ns.example.org.
example.org.      172800	IN	NS	b.ns.example.org.
example.org.      172800	IN	NS	c.ns.example.org.
example.org.      172800	IN	NS	d.ns.example.org.
;; ADDITIONAL SECTION:
a.ns.example.org. 172800	IN	A	192.0.2.3
b.ns.example.org. 172800	IN	A	192.0.2.4
c.ns.example.org. 172800	IN	AAAAA	2001:db8::3
d.ns.example.org. 172800	IN	AAAAA	2001:db8::4

But of course what i really want is this:

;; QUESTION SECTION:
;example.org.				IN	NS
;; AUTHORITY SECTION:
example.org.      172800	IN	NS	a.ns.example.org.
example.org.      172800	IN	NS	b.ns.example.org.
;; ADDITIONAL SECTION:
a.ns.example.org. 172800	IN	A	192.0.2.3
a.ns.example.org. 172800	IN	AAAAA	2001:db8::3
b.ns.example.org. 172800	IN	A	192.0.2.4
b.ns.example.org. 172800	IN	AAAAA	2001:db8::4

My concern about this is if some IPv4-only system gets a list like the first one, and decides to use c.ns.example.org or d.ns.example.org, which doesn't have an A record at all. That would be a silly implementation, of course. but uh, we have a lot of silly implementations of things out there.Feedback welcome!Tags: dns, ipv6

<script type="text/javascript"> var flattr_wp_ver = '0.9.11'; var flattr_uid = '34168'; var flattr_url = 'http://www.sourceguru.net/bad-tech-support-feel/'; var flattr_btn = 'compact'; var flattr_hide = 0; var flattr_lng = 'en_GB'; var flattr_cat = 'text'; var flattr_tle = 'How bad tech support makes me feel'; var flattr_dsc = ''; var flattr_tag = 'punch,stabby,tech support'; </script> <script src="http://api.flattr.com/button/load.js?v=0.2" type="text/javascript"></script>

My telco Three have just offered me a deal on getting a new phone a couple of months earlier than my contract was supposed to expire, presumably they have some competition and want to get me locked into another 2 year contract a couple of months before anyone else has the chance.My current phone is a LG U990 Viewty [1] which I am reasonably happy with for the regular phone and camera functionality (apart from it being too slow to take a photo), it s on a $29 per month plan. I also have a 3G modem which is on a $15 per month plan for 1G of data per month for a total cost of $44 per month. As new phones have advanced client functionality (ssh, IMAP, etc) and have Wifi support for providing net access to a laptop there seems to be less need to have a separate phone and modem. So I am considering getting a high-end phone to replace the phone and modem, so while I don t want to pay a lot more than I currently pay, a $49 contract would be quite affordable and a $59 contract is something I can consider.What I need is a system with a good ssh client implementation, a high resolution screen (800*480 or better), preferably a slide out keyboard and an option to use a Bluetooth keyboard.The best option for the OS seems to be Android as it s based on Linux, it s moderately open, and it has a good range of applications. The Nokia N900 has been recommended based on features but a friend had a bad experience with a N900 that broke and didn t get good warranty support. Also the N900 doesn t have a digital compass (so can t do augmented reality). While I m primarily buying a phone for making phone calls, using the net, and being a ssh client I want to be able to do cool things like do Google searches on things that I photograph and have an annotated star map when I point my phone at the sky. Also as I m not using Windows or Apple phones for obvious reasons that leaves Android phones as the only suitable phones that are on offer from my Telco.I have checked some options for buying a grey-market phone, given that I need to get a more expensive phone contract to have the voice and data access I need the cost of buying a grey-market phone and having a no-phone contract would be unreasonable. So selecting a phone that s on offer by Three/Vodaphone seems to be the best option. Moving to another telco would be inconvenient as I would have to convince the relatives that I call often to switch as well (I get free calls to other Three/Vodaphone customers).I previously listed some phones that seemed good without regard as to where I could buy them [2] and some people wrote some really interesting and informative comments (thanks a lot!). But after considering all the options it seems that the costs of the various options force me to choose something that Three offers.Currently the best option from Three for an Android phone seems to be the HTC Desire HD [3]. It has a 800*480 screen, an 8MP camera with face-detection and geo-tagging, wifi, an accelerometer, GPS, and a digital compass. It also runs Android 2.2 (the latest release). Generally it has everything I want apart from a slide-out keyboard. It seems that Bluetooth keyboards are about $100 each, so I could buy such a keyboard and have options of taking just the phone, the phone and keyboard, or phone and laptop depending on how much I can carry and what I expect to be doing.Three PricesThe Desire HD is free on a $59 plan, or costs $15 per month on the $29 plan. So for $44 per month (the same as what I spend now) I can get a Desire HD! The down-side is that the $29 plan only allows 200MB of data per month and has an excess data fee of $0.50 per meg. My average usage has been about 300MB per month, I could reduce this a bit but I do occasionally have a month where I need a lot of data transfer. For an extra $8 per month I can get an additional 500MB of data transfer. That would give me a total cost of $52 per month for my phone, and I could get the same phone for my wife for $44 per month (I doubt that she would use the 200MB of data included). That would take a typical Three bill from $73 to $96.I might just wait a few months. The Viewty and 3G modem combination is working reasonably well, presumably there will be some better deals if I wait a while. At least now after considering all the options I could find and determining that a Desire HD from Three is the best option for me I can now evaluate any new options by comparing them to that.

• [1] http://etbe.coker.com.au/2009/05/31/lg-u990-viewty/
• [2] http://etbe.coker.com.au/2010/10/08/choosing-an-android-phone/
• [3] http://en.wikipedia.org/wiki/Desire_HD

With today regular update from unstable an update to desktop-base package has brought the SpaceFun theme to Debian. This change made my feel like a child with a new shiny toy (: Take you Valessio Brito for this theme it looks great. p.s. As Rapha l mentioned, help is needed to integrated the rest of the theme to other packages.
Filed under: Debian GNU/Linux

Squeeze is frozen for some time now and will be released when it's ready, of course. Currently, I have at least two packages that have reported bugs, but it seems that they are making no progress. The first package is BackupPC.One of the bugs is #600654 and the other is #601843. Where as the first is just a cosmetic bug displaying filesystem usage of the backup volume, the other seems to have a functional impact: the backup pool doesn't get cleaned up properly each night. Sadly the maintainer seems a little bit absent, so maybe someone else can do a NMU to get BackupPC into shape for release? Would be nice, though... ;-) The other package is spamassassin or more exactly libnetaddr-ip-perl and bug #601601. Whereas the BackupPC maintainer is rather quiet, there's lot of activity for the other bug but still I get these errors when running Spamassassin by cron:

netset: cannot include 0:0:0:0:0:0:0:1/128 as it has already been included
netset: cannot include 0:0:0:0:0:0:0:1/128 as it has already been included

Although I'm confident that #601601 will be solved soon, I don't really know about the BackupPC bugs, except writing additional info mails to those bugs with "add me!" comment. UPDATE 17.11.2010:
libnetaddr-ip-perl (#601601) seems to be fixed now.

The Debian Women project is pleased to announce the -start of a series of training sessions to be held via IRC in the Debian Women IRC channel, #debian-women on irc.debian.org

The first session has been scheduled for Thursday, 18th November at 20:00 UTC. Lars Wirzenius, will give an introductory lesson titled Introduction to Debian Packaging .

The main goal of this initiative is to encourage more people, specifically women, to contribute to Debian while introducing them to different aspects of the Debian Project. Topics will span a wide range of subjects related to daily Debian maintenance efforts as well as advanced tasks and are open to everybody, regardless of gender or previous involvements in the community.

Future sessions will be held on a regular basis, and will cover collaborative maintenance with git, Python modules and applications packaging, and many more. Please visit the Training Sessions wiki page regularly to check the up-to-date agenda and follow our group on identi.ca. You may also refer to the wiki to suggest new topics or sign up yourself as a trainer: we are always looking for more people to share knowledge and complete the schedule, so don t be shy!

For further information about the Debian Women project, please visit the Debian-Women website or send mail to the Debian Women mailing list.

For the last few years, I ve been a mostly happy customer of Sivit (now bought by Nerim). But recently, technical problems have become more frequent, and today, for the first time, a crash made me lose some data which was rather painful to restore from backups. Also, they are still stuck on with an ancient 2.6.16 kernel. So, I m looking into alternatives, and a promising one is Gandi hosting, based on virtual machines like Sivit.

• Would you recommend it for a mission-critical server?
• What s your uptime? When was the last time your server had an unscheduled outage?
• When was the last time you lost data because of Gandi?
• What are the limits due to the Xen-based hosting? Can you run your own kernel (like the squeeze one)? Can you build additional modules (like tun)?
• What else should I know?

Thanks!

I'm going to be listing the more inept of the commercial spammers that I'm annoyed by, so I can hopefully help give them a more accurate reputation on Google searches. Spammer Number 1: CM Crossroads via Streamsend Guilty of: spamming lots of Debian mailing lists. I guess that "agile business" is a synonym for "being spamming bastards", based on this. I'll be careful to remember this in future.

As my student research project I worked on a formalization of Olin Shiver s control flow algorithms for functional languages (as written down in his dissertation) in the theorem prover Isabelle. I just handed in my report to my supervisor Andreas Lochbihler. I have also submitted the Isabelle theories to the archive of formal proofs and uploaded the Haskell prototype on Hackage. The complete code is in a git repository.

Yesterday, stardict-czech got accepted to Debian. So there is yet another useful dictionary for Czech users available in Debian without need to use my repository (however daily builds are still available there). The dictionary is built from ABZ.cz: slovn k ciz ch slov using my set of scripts, which are also capable of converting other dictionaries. Thanks to FTP masters team for accepting new package even in freeze, when they are busy with other things. Great work guys.

Filed under: Debian Stardict 0 comments Flattr this!

I'm considering replacing our 5 year old 32" TV with a 40" Sony Internet TV, largely "just because" it has Google TV. That and I have spousal approval to get a new, bigger TV (it just has to be wall mounted). The dilemma is MythTV. It's currently still running on the Dell Dimension 3100 that I bought years ago, and connected via VGA to the TV. The Sony Internet TV is HDMI or nothing, so at the very least, I need to get a DVI-capable video card in my MythTV box. The more or less natural choice would be an NVIDIA card, despite them having a closed-source driver. At least it's well supported under Linux. The problem is, as far as I can determine, NVIDIA cards require at least a 300 watt power supply, and the Dimension 3100 has only a 230 watt power supply. So now I'm looking at having to replace the MythTV box. I'm currently running the front end and the back end on the same box, so it'd be a fairly simple case of splitting the back end from the front end, and just getting something new to be the front end. So now I'm in the market for something small, low-power, has a HDMI (or DisplayPort) interface, and enough grunt for HD playback. I'm wondering if the Boxee Box is the solution. Interface-wise, it has HDMI, so I'm good there, and I believe the marketing claims it can do HD playback. I just don't know how hackable it is. I think it's running Linux, so in theory this should be doable, so long as there isn't some weird hardware in it with a binary-only driver. For the price, it's probably worth just getting one to see. The annoying thing is, I have nothing in the house that is DVI or HDMI capable, so I have no way of testing this out prior to buying the TV.

Shifting gears from serious tractor injury stuff to the more humorous We re all used to seeing Yoda 900 years old. I ve noticed over the past couple of months that Oliver, while eating supper, seems to resemble a 1-year-old Yoda. So I got out my camera one evening, with the results below: Or this what s so hard about lifting an X-wing pose? And of course:

Developers are not usually the right people to write documentation, but in an effort to encourage more Debian folk to consider Emdebian, I'm starting an intermittent series of blog posts to describe how Emdebian works and how it fits with Debian. Emdebian has a variety of ideas and experiments but the principle distribution, to be released alongside Debian Squeeze, is Emdebian Grip. This post, I'll cover the basic stuff. Feel free to let me know if there are particular issues you'd like covered. In particular, if the documentation on the Emdebian Grip website needs improving, let us know.
What's Emdebian Grip all about?
Simply a smaller Debian. Smaller packages, smaller downloads, smaller sets of packages, smaller installation sizes and smaller update sizes; yet always and completely binary compatible with Debian. Every backtrace from an Emdebian Grip device will match the backtrace on a Debian machine of the same architecture, package version etc. Packages can be mixed trivially (with some allowances for strict dependencies like -dbg packages). The name is a derivative of Squeeze - to make Debian smaller, we take a hold of it; Grip it.
Is it cross-building?
NO. Emdebian Grip is not recompiled (natively or cross), it is processed. Packages natively built in Debian are unpacked, files removed and repacked on the server before being included into the Emdebian repositories. dpkg and perl do all the work, not gcc.
What gets taken out?
Translations move out of the source packages and into TDebs (organised by locale) and compiled .mo files are then removed from the binary packages. Manpages and other documentation is lost entirely, copyright is compressed and changelogs are removed. None of the binary files are touched. The SHA256 sum of your /usr/bin/foo executable in Debian will be precisely the same in Emdebian, the same applies to libraries.
How is it done?
The emdebian-grip-server package in Debian processes the package and treats every architecture in the same way. (This allows Emdebian to carry unofficial ports like SH4, armhf etc.)
Why not filter stuff with dpkg?
The straight answer is that there usually isn't room to download the large package first in order to strip it on device. Also, filtering on device is slow. Stripping the package on the server means that the work is only done once. Every Emdebian device is saved the effort of filtering the files one machine at a time. Grip effectively does what dpkg filtering does, just it does it on the server, repacking the results into a new .deb. Instead of every device doing the task again and again, the server does it once.
Why is my pet package not included?
Emdebian restricts the number of packages which are included in the repositories (less than 10% of Debian packages will be included in Emdebian Grip 2.0 which is based on Debian 6.0 "squeeze") but provides tools which can be used (on device or on the desktop) to prepare any other package for installation on an Emdebian Grip device. There is no need for the machine preparing the package to be of the same architecture as the intended device because all processing is architecture-neutral.
Who decides which packages get included?
Me, basically. The merits of adding particular packages is usually discussed on the debian-embedded mailing list. Typical criteria (in rough order) include:

1. Subjectively suitable for an embedded device (so OpenOffice.org does not qualify)


2. most, if not all, dependencies already included in Grip


3. already available in Debian testing


4. not in a state of churn in Debian (rapid upload cycles, frequent library transitions etc.)
   
5. not particularly buggy in Debian

Can I convert Debian to Emdebian Grip
Yes - simply add Emdebian to your apt sources list and watch as your next upgrade releases tens of megabytes of space.
What are these em1 version suffixes?
Emdebian modifies Debian packages, albeit in an architecture-independent manner, by removing files. The resulting packages are therefore different to the originals, albeit containing compatible binaries. Hence, the Emdebian processing adds the em1 version suffix to show which version is installed. Adding the suffix also means that every Emdebian package is considered to be an upgrade compared to the equivalent Debian package, if both exist in your apt sources.
How is Emdebian Grip installed?
It is possible to use Debian Installer (we provide pre-seeding files to help this process) or create a simple tarball using multistrap if that is more suitable for your device.
What about Recommends: ?
Debian defaults to installing all packages listed as Recommends in the package metadata. Emdebian simply drops the entire Recommends field when processing the package. Suggests is also omitted. This dramatically shortens dependency chains and gives developers full control over which packages are installed. It is important here to consider the embedded device user interface. Recommends exists to support those users who need the extra parts of the package, the bells and whistles. Embedded devices strictly control which parts of the package is actually exposed to the user - there is no need for a menu or a desktop. Users can only access the functionality exposed by the device, so no bells and whistles - just the base system and whatever you choose to expose as part of the interface. Rather than require all Emdebian devices to turn off Recommends individually, Emdebian simply drops Recommends at the server and allows the developer to cherry-pick which packages to add.

More to follow . . .

When most people talk about Ubuntu, they usually mean our flagship product, Ubuntu Desktop Edition. Sometimes, they might mean the Ubuntu project, or the community of people who work on it, or various other things. Similarly, Debian might mean the Debian operating system, or the package repositories, or the project, and so on. This gets a little confusing sometimes. When I m talking about Ubuntu, I ve started to use more specific terminology to explain what I mean, and this seems to help people understand better the nature of the whole Ubuntu. In particular, I use the three Ps:

• a portfolio of products, including Desktop Edition, Server Edition, Netbook Edition, Kubuntu and more. These are software bundles which can be downloaded, pre-installed on retail computers, and so on. Each one is designed to meet a certain set of user needs, and to work on a specific form factor of computer.
• a technology platform, which can be used to build a wide range of products. It is primarily of interest to developers, who build derivative distributions, OS products, applications and infrastructure using Ubuntu packages. This platform is the common foundation of the Ubuntu products above, and includes things like the global package repository. Joel Spolsky does a good job of explaining why platforms are distinctly different from products, and should be treated as such.
• an open community project, which collectively produces, distributes, promotes and supports the products and the platform. The Ubuntu project has a philosophy, a government, and various tools and processes to help contributors work together. Canonical supports the Ubuntu project by providing resources and infrastructure, and also directly participates in Ubuntu at various levels.

This breakdown may seem a bit obvious to those of us on the inside , but it s confusing to people who are encountering it for the first time. I m sharing this in the hope that if more people start using the same words, it will get easier for people to understand how these pieces fit together. I ll also be linking to it a lot, to help put things into context using this framework.

Org has a nice option which allows you to show week-end days in a different color in your agenda. That means that Saturday and Sunday (when I do not work) are fontified with org-agenda-date-weekend'. But there are other days I do not work, like my vacations or holidays. Therefore, I've wrote a patch to add org-agenda-day-face-function' which is optionally called to determine what should be the face used to fontify a day. This allows me to use the same face for holidays and for week-end days, like for last Thursday which was an holiday in France. That patch has been merged in Org last week.

Unfortunately, for many people "File Transfer" equals FTP. I dislike this; but if the customer insists that "HTTP" is not a suitable file transfer protocol, then the customer is king. For all its usage and updates, FTP still requires the use of two TCP connections, which makes firewalling hell. Oh well; at least in this particular instance, the firewall is not my job. At least the customer does have some clue, and insists that no passwords should be sent over the wire in the clear. On that, we agree. Now there are several methods of securing passwords when doing something for which the name involves "ftp".

1. The most well-known is "sftp", a part of the OpenSSH package. This has nothing to do with the FTP protocol; it uses a tunneled SSH connection to get at files. This means that usually, in order to get people to files on a server, you must give them shell access too (although there are ways around this). Also, not all file transfer clients support sftp (though some do). The URI scheme used for this is, usually, 'sftp://'
2. Another one is FTPS, which involves opening an encrypted control connection to port 990, and then doing FTP as usual much in the same way that HTTPS uses a different port, too. The URI scheme used for that one is, clearly, 'ftps://'
3. Yet another one is using the method described in RFC4217 (October 2005) which involves an AUTH TLS command. Clearly this is superior to the ftps option (who likes to create more holes than necessary in their firewall?). Two problems with this RFC:
   • I haven't found what the URI scheme is.
   • Since there does not appear to be an RFC for the second method above, the existence of an RFC for this method appears to confuse many people, including (but not limited to) some who should know better (SEE ALSO section) that it is about ftps, which it isn't.

The fun bit is that vsftpd supports the latter two; but because everyone confused FTPS with RFC4217, the version that's packaged for rhel 5 supports the latter but not the former, while most clients support the former but not the latter. FTP, how I loathe thee.