Search Results: "ana"

28 June 2008

Martin F. Krafft: Shortcomings of the Nokia E51

I put the Nokia E51, which I had previously acquired, onto Ebay last night, and it sold within minutes. Even though I made a 50 loss on the whole affair, this made me very happy! The phone is crap in so many ways that it made me quite angry. I now consider those 50 the investment I had to make to bring you this post: First of all, the reason why I bought the phone was because it sports wireless LAN as well as Voice-over-IP. Since I ve recently gotten into VoIP, I was looking for reasonable VoIP phones and even though the Siemens C450IP DECT phone works very well, it only does so at home, or where I find a switch port for it. So my theory was to get this Wifi+VoIP phone and be able to use my VoIP infrastructure from anywhere around the world. Penny has the Nokia E65 and loves it, so I went for the E51, a newer model that promised to address some of the issues she had with hers. All of the following is based on the E51 with the 100.34.20 firmware dated 29 September 2007, which runs the (crippled) Symbian S60r3 operating system.

Good things Let s start with the few good things up front: the E51 comes with a regular USB jack, allowing you to plug it into any computer and use it as mass storage device without the need for any Nokia-specific cables. I also liked the remote lock functionality: in the event of a stolen phone, you could send it a pre-defined passphrase that would cause the phone to lock itself. Also, the phone could be configured to lock itself (like a screensaver) after a given amount of idle time. Other than that, I could not find anything outstanding, so let s turn to the downsides, of which there are many more:

VoIP/SIP shortcomings I had previously dismissed the E series phones for good reasons, but both the E65 and the E51 improved their SIP clients a fair bit, and with the SIP VoIP settings utility, it was even possible to configure STUN. But unfortunately, the SIP client, while a nice toy, ended up being unusable in production. Here are some of the reasons: I got VoIP working at home and in some other places, but definitely not everywhere. It may be that some of those networks blocked the SIP port (5060/udp), or that the phone didn t feel well on the day, but in the majority of cases, I could not get the SIP client to connect. And there was no way to find out what was going on, as the client would just claim that registration failed without any additional information. It was also hard to retry, often requiring the phone to be restarted. Whenever if failed, the client would helpfully tell me that it could not establish a connection to the connection network . To get the phone to log on to the SIP server automatically, I had to define a home network for the SIP profile. Changing the access point for that network required a phone reboot to get SIP working again. It was possible to define multiple SIP profiles with different access points and add them all to the one, global VoIP profile, and theoretically get auto-login to work across multiple Wifi networks; unfortunately, I cannot say that this worked, there were always some problems requiring me to change defaults and shift things around. Also, after I had defined a few of those profiles and needed to make a change to the SIP settings (move the SIP port to 53/udp), I had to modify all profiles in turn; it was not possible to share settings. On the other hand, NAT traversal settings and timeouts, which can only be configured with the aforementioned SIP VoIP settings utility, applied to a VoIP profile and thus to all SIP profiles, without exception. I found it mildly annoying that I couldn t use # and * as part of the number/SIP address to call, nor was it possible to dial single-digit extensions the phone will ask you to associate a quick dial number with the key, even if quick dial has been explicitly disabled). I could also not dial a SIP address ad-hoc if I wanted to call sip:someone@sip.somewhere.org, I had to define a contact and add the Internet phone address. One can define Internet calls to be the default call type, thus routing all calls via VoIP if available. Unfortunately, once I dialed a number, the event was hardwired to the call type: I could not redial a number used previously for a VoIP call when all I had available was GSM coverage.

Gripes with the IMAP client The IMAP client, while an interesting addition to my day, turned out to be pretty unusable. The first mistake I made was to tell it to synchronise all messages in some of my larger mailboxes, which caused the phone to take tens of seconds until it switched a folder, and a few seconds just to scroll to the next screen in any given folder. I found that once any mailbox accumulates more than 100 messages, the client turns useless (Nokia s default is to synchronise 30 messages). I could tell the client to synchronise every hour, but only if I locked it to an access point, the home network . If I roamed to a different Wifi network, I could no longer connect to the IMAP server, as this access point would not be found. The phone would not let me use a different access point unless I changed the home access point, but changing that turned off the automatic mail sycnhronisation. If I say mail synchronisation, I mean header synchronisation. Even though there is an option for Headers only , it only applies to POP3; it is impossible to have the phone download message bodies automatically, only manually and then only per-message or per-folder, not for all folders at once. The IMAP client could delete messages, but it could not move a message to a different folder, nor create or delete folders. And even though I could turn off the message tone the phone would play when it received new email, it insisted on vibrating nevertheless. The only other IMAP client I found for Symbian phones is ProfiMail, which looked interesting and much more powerful, but which would randomly crash on me while browsing or operating on larger mailboxes.

Connection hickups While the an application was running that was using the network, the Wifi connection stayed open, but I could not make it stay open between sessions. The phone would obtains an IP, do what I asked it to, and then immediately close the connection. From a power management perspective, this makes sense, but not from the usability angle. I could not make the phone connect to a Wifi network that advertised both, WPA and WPA2 and had to disable WPA at home to let it connect. At times, it was not possible to reuse an existing connection. I haven t been able to figure out the details, but it seemed to me that whenever an application like the IMAP client was locked to an access point, it would be unable to make a connection to the IMAP server, even if e.g. the VoIP client was connected to the server by way of exactly the same access point. The phone would just say that a connection was already active and that I should close it and try again . I had a really hard time working with SSL-enabled websites and IMAP servers, because even though the phone presented me with the server certificate and offered the choice of accepting it permanently, it didn t and would ask the question again and again (which made the phone pretty unusable if the IMAP client was running in the background). Only after I had found out how to import the CACert root certificates, did this problem become irrelevant.

Other pet-peeves The phone came with a lot of smaller issues that made me ask the question of whether its designed ever had to use it too often. Possibly the most annoying aspect of the phone was its speed. It s a lot faster than the E61, but it still takes on the order of seconds to update screens or display simple text messages. Speaking of text messages, I am a little spoiled by the Sony Ericsson K610i (to which I now return), which would offer the contacts with whom I d recently interacted instead of presenting me with the full list, like the E51 does. I could filter the full list, but only by typing the start of the name substring matching was not implemented. It was impossible to receive text files via bluetooth and have them put onto the filesystem. On receipt, the phone just said text file saved , and it took me a while to figure out that it had stored them into the notepad, from where it could not be exported. To get my SSH identity onto the filesystem for PuTTY to use required me to access the phone via USB. The phone could receive vCards with new contacts, but it only offered to import the first contact, even though the standard allows for an arbitrary number of contacts per file. What s even worse though is that the phone silently failed to import contacts with non-ASCII characters in their name, such as or they just didn t show up even though the phone gave every indication of a successful import; creating such contacts on the phone worked, on the other hand. Each time I started the phone, the Nokia greeting screen would show up, accompanied with the Nokia tune, which could not be disabled. Enough said. The last problem I feel worth mentioning is hardly a Nokia or Symbian problem: battery life. With Wifi turned on, the phone would last about 24 hours on standby, which makes it pretty unusable for roaming Wifi or even VoIP usage.

Summing up I am happy to have sold the phone and look forward to returning to my Sony Ericsson K610i. After checking out the E61/E71 a bit, playing with the E65, and trying the E51 out for several weeks, I can conclude that Nokia has a long way to go before they can offer a usable smartphone with Wifi/VoIP capability. It would be a good step forward if they would open-source the Symbian operating system, but until that s done, I am going to look at the OpenMoko FreeRunner next. The E51 once again made it perfectly clear for me that proprietary software is no alternative for my use case. NP: Fat Freddy s Drop: Live at the Matterhorn

Paul Wise: Going to DebConf!

Going to debconf! Finally got my shit together and got a flight to Argentina for DebConf! Perth -> Sydney -> Auckland -> Buenos Aires -> Mar del Plata. That is quite a bit of flying and a long bus trip ending quite early on the 4th. It will definitely be worth it if DebConf7 was anything to go on. Hopefully by DebConf I can get my hands on an OpenMoko FreeRunner to do some Debian porting work during DebCamp and possibly mapping out the streets of Mar del Plata for OpenStreetMap. Of course I need to work on completing analysis of the results of the Debian user and new contributor surveys and figure out what to say about synfig if I get the chance to do a lightning talk about it. /me now officially excited

Martin Michlmayr: Debian support for HP mv2120: putting everything together

I managed to get my hands on a HP Media Vault mv2120, a nice ARM based NAS device, a few months ago with the intentions of porting Debian to it. Unfortunately, I have been really busy lately and most of my time was spent on adding support for the QNAP TS-109/TS-209 and TS-409 (which required a lot of generic work to get Marvell Orion support into Debian, a new SoC used in many NAS devices, including the QNAP TS-x09 and HP mv2120). There were a number of things that had to be worked out before Debian would run on the mv2120. The good news is that Marc Singer and Eugene San have done all of the heavy lifting in the last few weeks in figuring out how the mv2120 works and that now it's just a matter of putting everything together for Debian to work. Here are the issues that had to be worked out: Now that these two issues are resolved, I simply need to put everything together and add support for the mv2120 to a number of debian-installer components. We already have Orion kernel images in unstable that support the HP mv2120 (along with a number of other Orion based NAS devices) and the rest shouldn't take too long.

27 June 2008

Biella Coleman: Dear lazy lazy lazy web

I think it is time for me to upgrade my digital camera and while I would like a SLR, I think I am going to stick to a small non-SLR digital camera. I am looking for a high quality one, preferably with a wide-angle lens such as with this camera (which is one of my choices). Are there any cameras that folks have that they love?/hate?/recommend? Feel free to leave comments or drop me a line

26 June 2008

Pierre Habouzit: About free software, UI and bad excuses

Okay, following my irritated post I received (sigh) complaints about me being too harsh. So to these people here is what I say, because I'm tired answering the same thing over and over. For starters, the SSL dialog in firefox is badly designed:
  1. My mom doesn't grok it, so it totally fails the "corridor testing" (see JoelOnSoftware if you don't know what it is), stop pretending otherwise;
  2. since it fails with the "average not very computer literate user", I, as an advanced user, believe to be representative of this kind of person, say and affirm that this UI is completely broken and horrible, not to mention counter-intuitive.
That said, I have other things to say on the form. Yeah I've been harsh, and I will continue to be about this issue: this has not been designed with the simplicity in mind, but by geeks (FSVO geek) that believe that it's important to educate people about how nice HTTPS is and that everyone should talk in S3kr3t because its 733t. And I'm sure they tried very hard to make it very painful for users to have to deal with HTTPS and not believe in it to be trusted for bad reasons. Why ? HELLLOOOO PEOPLE this is the wrong way to do it. People are already aware that it is https, because they did typed https in the URL. And again, my mom doesn't know what the s in https stands for and she doesn't care. What she cares about is to see the small lock when she logs on her bank website, not even when she goes on her webmail. You REALLY want to make a simple UI ? Well, please try to explain and justify (with real arguments) Why on earth is https with an untrusted certificate less secure than http ?. Okay I'll let you 3 seconds to think. 1
2
3 What is your answer ? OH see ? it isn't. So now second 1 question, why does it need to be more painful to use https with an untrusted certificate than plain http ?. Well, I don't have 3 seconds to give anymore, so let's jump to the answer: there is absolutely no reason. See, I'm far from an UI expert, and what I use every day for UIs would revulse 99% of the planet: vim as an editor, awesome as a tiling window manager, vimperator for a browser, and I live most of the time in a terminal. But it takes me like 10 minutes to design what I believe to be an excellent UI for https with untrusted certificate: just don't mind the certificate and show it like plain HTTP. YES I'M ANNOYED That brings me to the last point. I see in my comments, and have received the same by mail, that I should not be harsh with people writing such a brilliant piece of software. Well, the fact that firefox is or is not a good piece of software is totally irrelevant. When you claim no less than trying to reinvent the web, well, if you fuck up this big, you deserve it. No matter if it's a free piece of software or not. (or a piece of free software or not). When you request your users to click on FIVE completely counter-intuitive buttons/urls to finally be able to see a webpage they want to see (and my mom doesn't care about the webmail being insecurely hosted, really), with the first screen being almost the same than what you get when a serer timeouts or 404, well, you're just out of your mind. There is absolutely nothing that can excuse such a bad design, and the SSL thing is a failure. I mean everyone is laughing at the vista way of asking you if you really meant to go pee, well I see no difference here, it's as dumb and inefficient. No matter how much firefox did improved (and it did memory wise, believe me, I feel it, and I'm really glad about that), https is part of my everyday's life. Those five clicks are a real PAIN. When I'm reading documentation, browsing some sources, and so on, I go through this dialog about 3 to 10 times in a row. I'm totally unimpressed, and just because a couple of geeks believed that it was GOOD to educate me about how dangerous untrusted certificates are, I have to break my workflow to grab my mouse in the middle of my work. No sorry, I don't really want to be calm. In fact, what annoys me the most, is that I'm a programmer. And as a programmer, the worst thing to me, is regression. Regression is what happens when you're sloppy, and don't test your program enough. It's what happen when you aren't good enough to keep your concentration, and don't see the big picture, and constantly break your program invariants. So when I see a regression that people did on purpose, well, it shocks me beyond what I can explain with words, that's the worst thing you can do to a piece of software. I won't really mind a new feature that only partially works, I won't mind if a feature that is complicated to write isn't there after 5 years dreaming of it, but this ? I do mind. There is no way to consider that ruining a piece of software like that to the name of A Greater Good is excusable. Oh and last words: wanting to educate people this way is a way worst offense that what I will ever say on the subject. Such a condescending approach to what they think of their users reminds me of various journalists that I met, and that when I tried to rephrase some things so that they can write about it to their readers, answered to me oh you know, they're too dumb, they'll never understand. And as a result, articles or interview are always distorted, can't interest the readers that don't care about the subject a lot, because there's nothing captivating in the article, and is totally inexact and uninteresting to people interested in the matter, because it's void from its substance. Well, the SSL dialog gives me the very same impression: it's annoying to me who knows what a SSL certificate is, and my mom won't know a single bit more what an SSL certificate is and why she should care[1].
Notes [1] and actually the whole point guys, is that she should not

Russell Coker: Kernel Security vs Uptime

For best system security you want to apply kernel security patches ASAP. For an attacker gaining root access to a machine is often a two step process, the first step is to exploit a weakness in a non-root daemon or take over a user account, the second step is to compromise the kernel to gain root access. So even if a machine is not used for providing public shell access or any other task which involves giving user access to potential hostile people, having the kernel be secure is an important part of system security. One thing that gets little consideration is the overall effect of applying security updates on overall uptime. Over the last year there have been 14 security related updates (I count a silent data loss along with security issues) to the main Debian Etch kernel package. Of those 14, it seems that if you don’t use DCCP, NAT for CIFS or SNMP, IA64, the dialout group, then you will only need to patch for issues 2, 3 (for SMP machines), 4, 5, 7 (sound drivers get loaded on all machines by default), 9, 10, 11, 12, 13, and 14. This means 11 reboots a year for SMP machines and 10 a year for uni-processor machines. If a reboot takes three minutes (which is an optimistic assumption) then that would be 30 or 33 minutes of downtime a year due to kernel upgrades. In terms of uptime we talk about the number of “nines”, where the ideal is generally regarded as “five nines” or 99.999% uptime. 33 minutes of downtime a year for kernel upgrades means that you get 99.993% uptime (which is “four nines”). If a reboot takes six minutes (which is not uncommon for servers) then it’s 99.987% uptime (”thee nines”). While it doesn’t seem likely to affect the number of “nines” you get, not using SMP has the potential to avoid future security issues. So it seems that when using a Xen (or other virtualisation technology) assigning only one CPU to the DomUs that don’t need any more could improve uptime for them. For Xen Dom0’s which don’t have local users or daemons, don’t use DCCP, NAT for CIFS or SNMP, wireless, CIFS, JFFS2, PPPoE, bluetooth, H.323 or SCTP connection tracking, then only issue 11 applies. However for “five nines” you need to have 5 minutes of downtime a year or less. It seems unlikely that a busy Xen server can be rebooted in 5 minutes as all the DomUs need to have their memory saved to disk (writing out the data to disk and reading it back in after a reboot will probably take at least a couple of minutes) or they need to be shutdown and booted again after the Dom0 is rebooted (which is a good procedure if the security fix affects both Dom0 and DomU use), and such shutdowns and reboots of DomU’s will take a lot of time. Based on the past year, it seems that a system running as a basic server might get “four nines” if configured for a fast boot (it’s surprising that no-one seems to be talking about recent improvements to the speed of booting as high-availability features) and if the boot is slower then you are looking at “three nines”. For a Xen server unless you have some sort of cluster it seems that “five nines” is unattainable due to reboot times if there is one issue a year, but “four nines” should be easy to get. Now while the 14 issues over the last year for the kernel seems likely to be a pattern that will continue, the one issue which affects Xen may not be representative (small numbers are not statistically significant). I feel confident in predicting a need for between 5 and 20 kernel updates next year due to kernel security issues, but I would not be prepared to bet on whether the number of issues affecting Xen will be 0, 1, or 4 (it seems unlikely that there would be 5 or more). I will write a future post about some strategies for mitigating these issues. Here is my summary of the Debian kernel linux-image-2.6.18-6-686 (Etch kernel) security updates according to it’s changelog, they are not in chronological order, it’s the order of the changelog file:


  1. 05 Jun 2008: CVE-2008-2358 for DCCP and CVE-2008-1673 for ASN.1 (NAT for CIFS and SNMP).

  2. 23 May 2008: CVE-2008-2136 memory leak in IPv6 over IPv4 tunnels, CVE-2007-6712 timer related bugs, CVE-2008-1615 ptrace on AMD64 architecture, and CVE-2008-2137 “Validate address ranges regardless of MAP_FIXED”.

  3. 07 May 2008: CVE-2008-1669 SMP race

  4. 11 Apr 2008: CVE-2007-6694 PPC only, CVE-2008-0007 Add VM_DONTEXPAND to vm_flags in drivers that register a fault handler but do not bounds check the offset argument, CVE-2008-1294 prevent user escape from RLIMIT_CPU, and CVE-2008-1375 fix dnotify race.

  5. 10 Feb 2008: CVE-2008-0010 and CVE-2008-0600 Fix missing access check in vmsplice.

  6. 25 Jan 2008: Not a security issue, but silent data loss on IA64.

  7. 22 Jan 2008: CVE-2007-6151 ISDN memory overrun, CVE-2008-0001 something related to checking the access to a directory, CVE-2007-2878 FAT filesystem related, CVE-2007-4571 ALSA bug that allows user to read kernel memory.

  8. 17 Sep 2007: Fix minor DOS attack for slightly privileged users (EG members of dialout group).

  9. 18 Dec 2007: CVE-2007-6063 overflows in ISDN subsystem, CVE-2007-6206 core dumping over an existing file can get the wrong ownership (should be possible to use kernel.core_pattern to work around this [1]), CVE-2007-5966 timer issue, CVE-2006-6058 Minix fs DOS attack via corrupted fs, and CVE-2007-6417 tmpfs memory leak.

  10. 29 Nov 2007: CVE-2007-3104 local kernel DOS attack (Oops), CVE-2007-4997 malicious frame on wireless interface crashes system, CVE-2007-5500 potential system hang, and CVE-2007-5904 CIFS overflows from server sending corrupt data.

  11. 02 Oct 2007: CVE-2007-4573 Xen 64bit with 32bit DomU, CVE-2006-5755 Xen, CVE-2007-4133 memory management DOS, and CVE-2007-5093 DOS when unplugging a webcam that is in use.

  12. 25 Sep 2007: CVE-2007-3731 ptrace causing Oops, CVE-2007-3739 memory management Oops, CVE-2007-3740 CIFS not honoring umask, CVE-2007-4573 ptrace of 32bit process on AMD64 bug, and CVE-2007-4849 JFFS2 (flash media) filesystem bug.

  13. 27 Aug 2007: CVE-2007-2172 IPv4 memory related issue (local DOS or compromise?), CVE-2007-2875 local user can read kernel memory if cpuset filesystem is mounted, CVE-2007-3105 buffer overflow in random number generator, CVE-2007-3843 CIFS, and CVE-2007-4308 AAC RAID.

  14. 11 Aug 2007: CVE-2007-1353 bluetooth, CVE-2007-3513 usblcd, CVE-2007-2525 PPPoE, CVE-2007-3642 H.323 connection tracking, CVE-2007-2172 IPv4 local exploit, CVE-2007-2453 slightly less random numbers, CVE-2007-2876 SCTP connection tracking, CVE-2007-3851 i965 batch buffer usage, and CVE-2007-3848 potential privilege escalation.

Share This

Wouter Verhelst: Firefox sucks. No, really!

Warning: big rant ahead. I received some comments on my previous post, as expected. Most of them were helpful; e.g., the oldbar extension is very useful. One of them was silly.
It depends: If your application is "fullscreened", clicking on the link without having the focus could lead to interesting situation like "Hey, It does nothing?"
Just to make a point here, let me reiterate: There is no excuse whatsoever to steal the focus Sorry for the shouting, but seriously. I have the following in my icewm configuration: 
ClickToFocus = 0
RaiseOnFocus = 0
FocusOnMap = 0
FocusOnAppRaise = 0
FocusOnMapTransient = 0
FocusOnMapTransientActive = 1
RaiseOnClickClient = 0
What this means is that I don't want anything to either get the focus or get on top of anything else all by itself, unless it happens to be a new dialog box created by an application that already has the focus. I also don't want windows to appear on top of anything else just because they received the focus. I also happen to prefer focus-follows-mouse, which you can get by way of the ClickToFocus thing. The reason I prefer it this way, is that often I have several applications open all at once. For instance, when I read RSS feeds, I have my RSS reader open on one virtual desktop, and read through the articles. Since my laptop's processor is much, much faster in certain things than is my network, I also make use of its multitasking abilities to have it preload links in the background (on another virtual desktop, preferably). Unfortunately, somehow, firefox manages to bypass all that configuration and shows up in front, stealing the focus; and in the process, it completely interferes with the way I work. No doubt they do this in order to help some hypothetical "grandma" or other stupid clueless person who's never used a computer before, but let me tell you something: software should be written for people who actually do use software, not for stupid nitwits who can't even read an error message that tells them "you cannot do A, please go ahead and do B instead". But I guess I'm too stupid or something to understand the usability "experts" who know it all best and say that software should be "intuitive" so that those who are 53 and see a computer for the first time in their live can sit right next to it and start emailing. Hah. As if the above wasn't enough, firefox 3 also is a crashing load of shit. I just spent the better part of an hour to try and make a payment using my bank's excellent online payment software which requires nothing more than javascript, SSL, and a digipass 810 that is provided by the bank as part of the online banking contract. Unfortunately firefox insisted on crashing halfway through entering the required information, for six times in a row. You'd think I'd be filing a bug now, but no, it managed to crash in a different location every time. I'd probably have to start debugging firefox to get this done, which is not something I'll do in this life. You know what the problem is? Webbrowser developers think they're developing the most important application for any computer. They're not. It's just a webbrowser, no more important than an xterm or a mail client: a tool to get a job done. Period. Grunt.

Edd Dumbill: My OSCON 2008 picks

In just under a month, the tenth O'Reilly Open Source Convention will get underway in Portland. Over ten years OSCON has developed—along with the world of open source—into an intense, exciting, informative, diverse and exhausting event. This year I've the privilege of being co-chair, along with Alison Randall. We've packed so much into the show, it's a difficult job even being able to comprehend it as a whole! Fortunately, there's a way to start making sense of things before you arrive there, thanks to the personal scheduler. Just mark the sessions you want to go to with a star, and you'll be able to plan out your time in advance. I wanted to list a few sessions from my own personal schedule that particularly piqued my interest. Then at the bottom of this post I'll share a discount code which can give readers of this blog 15% off OSCON registration. There's bribery for you. Practical Erlang Programming Largely thanks to XMPP enthusiasts and ejabberd, I've been hearing increasing amounts about Erlang, and I'd like to know enough about it to be dangerous. This three hour tutorial looks just the ticket. Open Source Virtualization Hacks This is one of several sessions we have on virtualization, something I'm particularly pleased about. Virtualization may be "done" at the kernel level, but I think we're only just starting out on its application. This session is by my friend and sometime co-author, Niel Bornstein, who works for Novell on just this sort of thing. Using Puppet: Real World Configuration Management Puppet is the piece of open source software that is most exciting to me at the moment. As a developer, it enables me to manage my machines like I'd manage my code libraries. A must-see if you've not used Puppet yet. These are just 3 out of the 300 or so confirmed sessions. Don't forget there's a large number of events and parties happening around OSCON too. And finally, the discount code. Use the code os08pgm when you're registering, and you'll get 15% off the ticket price. See you in Portland!Join the conversation about this post

Simon Richter: Seconded

This. (context)

25 June 2008

Mike Hommey: Pissing users off

It seems some people don’t like the new about:config warning in Firefox 3.0. The sad thing is this message was not intended to piss people off. The localization note intended for translaters reads:
<!– LOCALIZATION NOTE: aboutWarningTitle.label should be attention grabbing and playful –>
It’s not even necessarily talking about warranty in other locales:
<!ENTITY aboutWarningTitle.label “Attention, danger !”> (fr)
<!ENTITY aboutWarningTitle.label “ Zona hostil para manazas!”> (es-ES)
<!ENTITY aboutWarningTitle.label “Here be dragons!”> (en-GB)
Seems like the en-US version has a strange definition of playful.

David Moreno Garza: YAPC::NA 2008

So I attended the conference last week in Chicago, IL. I was just been procrastinating to write about this.

As a (almost) complete outsider of the Perl community, I have countered thoughts about the whole event:

After all, it was quite a nice and new experience. I'm not totally sure I'll attend YAPC::NA 2009 in Pittsburgh, PA, we'll see.

Martin-&#201;ric Racine: O: planner -- project management application

This one had been a long time in the making, but here it goes: I'm orphaning Planner. Why? Because upstream hasn't been too active in ages, save from a few random bug fixes, and because the GCC 4.3 transition at Debian has exposed yet more bugs that make it FTBFS. The package had been marked as RFA for a while, but I decided that I'm not gonna wait any longer; O it is. Hopefully, an experienced GNOME maintainer will take over and revamp the upstream code into a usable shape. If not, then I guess we just found another dead package in the archive. So be it.

Biella Coleman: The Cultural Significance of Free Software

When it comes to research and writing, anthropologists are notorious for being slow as molasses. It takes, on average, 9 years to finish grad school and then another 3-6 years before you write and publish your first book. Such is the sometimes frustrating pace of academia. But sometimes it is worth the wait as this new book, Two Bits, the Cultural Significance of Free Software by the anthropologist of science and technology Chris Kelty, makes clear. I am pretty intimate with the details of the book as ck was one of my dissertation committee members. I have read earlier versions and was fortunate enough to teach the final version to a small group of graduate students last spring. While there have been previous books on the subject of open source or peer-to-peer production more generally, this is the first book to delve deep, analytically and historically, into the cultural significance of free software. And the best part is that ck managed (I am not sure how but he did) to convince Duke University Press to release the whole book under a CC license. So download it to your heart’s delight and if you find it useful, do order a treeware copy (as you can’t beat that for easy and comfortable reading). For the developers out there, I would suggest starting with the introduction, which provides an initial overview of some of the main themes he develops and then I would dig into part two where the historical chapters reside and then loop back to the theoretical chapters in part one or continue to part three. Trust me, these will fascinate and surprise even those geeks with a relatively deep historical sense of this world. In fact, my very favorite academic piece on free software exists in these pages: and is the chapter on the history of the actual conflict between James Gosling and Richard Stallman that led to the creation of the GNU General Public License. Here is a small excerpt to whet your appetite:
In brief the controversy was this: in 1983 James Gosling decided to sell his version of EMACS a version written in C for UNIX called GOSMACS to a commercial software vendor called Unipress. GOSMACS, the second most famous implementation of EMACS (after Stallman s itself ), was written when Gosling was a graduate student at Carnegie Mellon University. For years, Gosling had distributed GOSMACS by himself and had run a mailing list on Usenet, on which he answered queries and discussed extensions. Gosling had explicitly asked people not to redistribute the program, but to come back to him (or send interested parties to him directly) for new versions, making GOSMACS more of a benevolent dictatorship than a commune. Gosling maintained his authority, but graciously accepted revisions and bug-fixes and extensions from users, incorporating them into new releases. Stallman s system, by contrast, allowed users to distribute their extensions themselves, as well as have them included in the official EMACS. By 1983, Gosling had decided he was unable to effectively maintain and support GOSMACS a task he considered the proper role of a corporation.
[ . . .]
Indeed, the general irony of this complicated situation was certainly not as evident as it might have been given the emotional tone of the debates: Stallman was using code from Gosling based on permission Gosling had given to Labalme, but Labalme had written code for Gosling which Gosling had commercialized without telling Labalme conceivably, but not likely, the same code. Furthermore, all of them were creating software that had been originally conceived in large part by Stallman (but based on ideas and work on TECO, an editor written twenty years before EMACS), who was now busy rewriting the very software Gosling had rewritten for UNIX. The once proud hacker ethic that Labalme mentions would thus amount not so much to an explicit belief in sharing so much as a fast-and-loose practice of making contributions and fixes without documenting them, giving oral permission to use and reuse, and losing records that may or may not have existed hardly a noble enterprise.
[. . .]
The story is a lively one, punctuated with some great e-mail “moments,” and gives you a play-by-play sense of how it is that free software become so entangled with the law and how the unwritten norms that guided sharing were violated to then become transformed, explicit, and written. The other chapter that will also fascinate those who want a deeper sense of this history is on UNIX and its role in creating the technical and collaborative conditions necessary to secure the explosion of free software years later. The story of the norms of sharing source code is, not by accident, writes Kelty, also the history of the UNIX operating system. This connection has been made by others but not shown in any historical detail as it is done in this book. For those interested in more anthropological issues, the first few chapters is where this type of more conceptual theorizing is at. Chris Kelty introduces the master trope of his book: the recursive public which is an idea that feeds into a longer academic debate, inaugurated by Jurgen Habermas, on the role of publicity, dialogue, and circulation of ideas and texts in cementing a democratic sphere. Many others, such as Charles Taylor, Michael Warner, and Nancy Fraser have since refigured and rehashed the meaning publics and public debate but there have been few ethnographies on the topic. It is here where Chris Kelty intervenes most forcefully to conceptualize publics in explicitly ethnographic terms and in an arena technology and the Internet which is often left undertheorized by cultural theorists. There is a lot more in the book (the third section examines some of the various political modulations of free software, such as Connexions and Creative Commons) but instead of saying any more, I will just leave you with his definition of a recursive public and again urge you to check out the book for yourself!
A recursive public is a public that is vitally concerned with the material and practical maintenance and modification of the technical, legal, practical, and conceptual means of its own existence as a public; it is a collective independent of other forms of constituted power and is capable of speaking to existing forms of power through the production of actually existing alternatives.

Clint Adams: Relaxation

I was misled. That much is probably true. I certainly had no idea what I was getting myself into. Enough of that though; there's narrative fading away. The part I should take responsibility for is the decision I made to stray off the map. Perhaps it was not so much a decision as a compulsion. I looked at the map. I saw the suspicious unmarked area at the edge, and concluded immediately that there was something good there, something the people wanted to keep hidden from me. I was correct, but I presumed far too much about the terrain. I thought I would make a quick exploration of the secret place, then backtrack to the more mapped area and get back with the program. Enough of that though; I've nearly forgotten the story. First I should point out that, had the map been to scale, it should have taken me an leisurely fifteen minutes to get to my first destination. It should have, assuming the land would be as flat as the map that represented it. Instead, it turned out to be something one could cover in fifteen minutes if one had, say, a jetpack and spring boots. I'm probably wrong; I'd probably injure myself in the process and take longer. Anyway, the average incline was close to 45 , and luckily was mostly uphill. Luckily. When I got to a resting place, I was able to conclude that my supply of fluids was almost certainly insufficient for me to continue. On the other hand, there was probably no way I would return if I went back for more drink. I told myself that there would likely be a beverage-selling shack out in the middle of nowhere around the next bend or so. Having solved this probability problem, I pressed on into the blazing sun. I came to a path leading down to the sea. It was unclear what was down there, but it was clear that it seemed to be a million miles down, and that that path might be the only way back. Given my current state of exhaustion and hydration, I decided to pass on this opportunity. After continuing for a while, the features at the bottom of that path became visible. A very pretty cove was down there, and almost certainly no shack o' drinks. I then came upon a fork. A wide path led downward: to what, I could not see. To its left, a narrow and rough path led straight. Knowing that a descent probably meant climbing four to eight times the altitude back somehow, and assuming the less pleasant-looking path led somewhere better, I went left. After a while, the land began to slope down, ever so slightly. Little clusters of bottles and newspapers were left on the rocks here and there. Then came a sofa under a tent. I began to wonder what hippies were traveling this path. The slope grew greater, and I passed a bench in a tent. Then I came to a giant staircase, almost straight down. It was covered in weeds and insects. Some were vegan, some wanted my flesh. As I got toward the bottom I thought about how glad I was that I had come that way from the top and not the other way around. Oh, I was very glad. At the bottom was something resembling a plastic bottle graveyard and barrels among barrels filled with water. Rubber hoses seemed to run randomly between certain barrels. A kitchen stood at the edge of some barrels. I suddenly got the feeling that I was not supposed to be here. After discovering that a couple of escape routes were actually dead ends, I proceeded to descend a small staircase to a terraced garden. Hoses lay about the rows, presumably for watering the plants. A cot under a tent lay empty, and I hurried past hoping I would not encounter the owner. Then I was at the ocean. The coast was lined with huge boulders, and a wooden bridge led me to the first one, and another wooden bridge took me to the second. Then the bridges stopped. In the distance, I could see that pretty little cove from before. I took stock. I could either return whence I came, up that horrifying staircase, or I could try to traverse the rocky coast over to the cove, then maybe do a faceplant on the beach and let the tide drown me rather than climbing back up. It seemed like a no-brainer, so I began making my way toward the cove. It got harder. Several times I became very afraid, either of falling and smashing my head against a rock or falling into the water below, or some sequential combination thereof. In the end I turned out to be more afraid of going back, at least until I got to what I judged the point of no return. I was reasonably close to where I imagined the sandy beach started, but there was a huge and impassable boulder in the way. Also, if I went further there was no way I would be able to climb back up in case I needed to retreat. I was thinking I would need to retreat, because unless there was some magical hidden toehold, I would be forced to jump into the water and swim around. I did not want to jump into the water. I wanted my phone to stay unfried in the event that I would need to use it to get rescued. I also did not want to call anyone to get rescued, especially since I didn't really know how to explain where I was. With a heavy sigh, I gave up, turned, and went back. This time I moved more quickly, though incurring more damage to my hands and feet. No humans were visible at the crazy farm/garden and makeshift reservoir, but plenty of bugs were visible on the staircase. I made the mistake of trying to lean against the railing to catch my breath. When I finally got to the bench in the tent, I understood exactly what it was for. I sat down, took a sip of my remaining water, ate an apple, and kept going up. When I got to the couch, I sat again. This time I sat and tried to figure out a plan. I still clung to the belief that once I got back to somewhere less wild I'd be able to buy a drink. I noted that I only had a little bit of water left, that I was dehydrated, that I was sunburned, that my pulse was about 180, and that there were no dogs or Russian people wandering past me. I ate a pear and drank my last few drops of water. I kept sitting until my pulse was down to around 150, then I figured I needed to keep moving. I was experiencing most of the effects of caffeine, and for free. Oddly, I passed a dog a few steps later. It was just standing by a rock, looking at me. I decided not to converse. When I had nearly reached the fork again, a couple came my way. I thought about begging them for water. I decided not to be rude. I have no idea what happened to them. I'm betting they wisely decided not to go down the steps. Resolving that the only sane option was to go back all the way to where I absolutely knew I could buy something potable, I headed in that direction. Still, I took two risks. Instead of going up the exact way I had come, or taking a well-travelled path down, I took a narrow and flat dirt path. It was actually a bit of a dilemma. I started down the latter two more than once each. Finally I saw that the down path was rather V shaped, and I concluded correctly that the straight path would bypass that angular-half-pipe-like construct. When I finally got to a point I recognized, it was smooth sailing the rest of the way down. I bought water and a snack, since I had had almost nothing to eat that day. At this point it would have been prudent to call it quits and go off and gorge myself on seafood or something, but no, I was now in the mapped area and surely it would all be roses and manna. Finishing one bottle, I bought two more. Five minutes later I bought another. I had now overcompensated, but I was playing it safe. I continued my explorations. Bicyclists kept nearly running into me, and, aside from the obvious, I viewed this as a good sign. Bicyclists, especially those that can't seem to steer straight for some reason, avoid difficult terrain. This is why they take their bikes on subways, trains, and buses. I don't like bike-riding, but if I had my druthers, I would always go downhill. No up, no flat, just down. Like downhill skiing, just down. It is a good thing I don't ride a bike. Once I got to the point where the bicycles thinned out to nonexistence, I was at an intersection. The way I wanted to go was up. The way I didn't want to go, but was a reasonable option, was only very slightly up. Additional factors complicated this decision point. [elision] This passage has been marked friends-only and you will not be able to view it without logging in. Moving hurriedly away from there, I headed upward. After a couple of turns, I ran into Catholics. First there were dead Catholics. Then there were Catholics pre-occupied with dead Catholics. Then there were Catholics waiting to die. Then there were seminarians. Then there were teens with prayer books. When I reached the next pinnacle, there were more teens with prayer books. There were benches, and there were no teens on them, for the teens were standing or sitting on the ground, quietly contemplating the Word. Unfortunately, they had decided that the benches were more suitable for holding all their bags, so there was nowhere for me to sit. I considered interrupting their reverie, but decided it wouldn't be very Christian of me to disturb them, so I just placed an ancient Drasnian curse on them and plodded down the hill toward a small beach. I really didn't need any more sun, but at least there probably wouldn't be anyone praying there. The water was tempting, but I'm always paranoid about my belongings when swimming alone, and if my phone were taken I wouldn't be able to call anybody to come rescue me at the next crisis point, sure to come. So I skirted the coastline and arrived at a much larger beach, one with facilities and services. Opting to save money but complicate things by using the public changing rooms and showers, I made a discovery. [elision] This passage has been marked friends-only and you will not be able to view it without logging in. Nonetheless, I changed into my swimming trunks, stuffed everything else but my towel, sunglasses, and a disgusting sugary drink I never should have bought into my bag, and went barefoot a few buildings down to rent a locker. The locker was ridiculously large for a single person, which is good to know should I ever want to kidnap a family and torture them at this place. The proprietor informed me that they were closing at some specific time, about an hour from then. I had no timekeeping device outside of the locker, so I had to wing it, and erring heavily on the side of caution, I had a short beach diversion. Given that large swathes of my epidermis were turning bright red, it's probably for the best. Handling the shower, locker, and changing in the other direction was slightly more complicated, but I did it and then I headed inland, figuring I should have a substantial meal for once that day. On my way to find dinner is when things got really crazy. [elision] This passage has been marked friends-only and you will not be able to view it without logging in. I wandered over to a bench to eat my newly-acquired snack, and did not exercise enough caution, because the flimsy paper bag ripped and I got sauce all over my pants and a little on my shirt. Unfortunately I had used my napkin in that earlier episode, and I'm not sure how much it would have helped anyway. Thus I continued on, looking like a slobby retard. Then I made an obviously-poor decision and ended up having a subpar dinner. What happened after that is a story for another time.

Clint Adams: Analogy or proportion

ropa vieja : old rope :: sopa vieja : ?
  1. old soup
  2. old soap
  3. shrimp butty
  4. The Sexual Misadventures of Natty Gann

24 June 2008

Clint Adams: Eli and the wolves of Bristol

The West Virginian is huddled over his bong, swirling the ice cubes around his glass of cream sherry. There is a montage on the television, set to some factory-produced pop song sung by a no-talent teen who was thrust into major stardom with the help of comb filters and clever marketing. He is not watching the montage; he is thinking about Chris Wallace and nepotism. He will stand in the end.

Russell Coker: Links June 2008

Paul Graham has recently published an essay titled How To Disagree [1]. One form that he didn’t mention is to claim that a disagreement is a matter of opinion. Describing a disagreement about an issue which can be proved as a matter of opinion is a commonly used method of avoiding the need to offer any facts or analysis. Sam Varghese published an article about the Debian OpenSSL issue and quoted me [2]. The Basic AI Drives [3] is an interesting papar about what might motivate an AI and how AIs might modify themselves to better achieve their goals. It also has some insights into addiction and other vulnerabilities in human motivation. It seems that BeOS [4] is not entirely dead. The Haiku OS project aims to develop an open source OS for desktop computing based on BeOS [5]. It’s not nearly usable for end-users yet, but they have vmware snapshots that can be used for development. On my Document Blog I have described how to debug POP problems with the telnet command [6]. Some users might read this and help me fix their email problems faster. I know that most users won’t be able to read this, but the number of people who can use it will surely be a lot greater than the number of people who can read the RFCs… Singularity tales is an amusing collection of short stories [7] about the Technological Singularity [8]. A summary of the banana situation [9]. Briefly describes how “banana republics” work and the fact that a new variety of the Panama disease is spreading through banana producing countries. Given the links between despotic regimes and banana production it’s surprising that no-one is trying to spread the disease faster. Maybe Panama disease could do for South America what the Boll weevil did for the south of the US [10]. Jeff Dean gives an interesting talk about the Google server architecture [11]. One thing I wonder about is whether they have experimented with increasing the chunk size over the years. It seems that the contiguous IO performance of disks has been steadily increasing while the seek performance has stayed much the same, and the dramatic increases in the amount of RAM you can get for any given amount of money over the last few years have been amazing. So it seems that now it’s possible to read larger chunks of data in the same amount of time and more easily store such large chunks in memory.

Share This

Matthew Garrett: Power management design philosphy

One of the traditional problems with power management has been balancing power savings against reduced functionality. The two traditional approaches to this have been to have sane defaults or to let the user tweak them, with a hybrid approach being to have sane defaults and an "advanced" box that lets users set their own parameters.

Both of these options suck.

The problem with sane defaults is that power management is an area where the "sane default" genuinely does differ between users. Usage patterns will determine the appropriate spindown period for a hard drive. AHCI's ALPM will disable hotswap detection, which is fine for home users but a pain if people want to rip out a failed RAID element. ALPM also introduces a small amount of latency (on the order of a seek in the most aggressive mode), which is entirely irrelevant for almost everyone but is a pain if you're trying to offer i/o latency guarantees. PCI-E link power management adds small quantities of latency. Letting the CPU run to full speed whenever it wants to is good for power management but potentially bad for thermal management. Screensaver timeouts vary depending on whether you're watching a movie or not.

The problem with leaving everything tweakable is that you're asking users to make choices about things but not giving them the information they need to make those choices. Whether you get a power saving from hard drive spindown depends on whether the drive is idle for long enough to save the power you'll spend spinning it back up. Get it wrong and you'll be putting your drive under extra load, reducing performance and consuming more power than you were to begin with. If you limit the maximum speed of your CPU to keep it cool, you'll be wasting power and performance even when it's well below the thermal limits. Disabling ALPM because you might want to change a RAID device at some stage means you're consuming power despite generally not needing to use the additional functionality.

But while these options both suck in different ways, they share one fundamental failure. They both imply static configuration. The correct power management policy depends on the way that a machine is being used at a specific instant in time, and no matter how many power management profiles you add there's no way for a user to switch between them fast enough to obtain a decent power/performance ratio.

Adaptive power management adopts a different strategy. Rather than define a static policy (or several static policies), the hardware is monitored to determine the best power management settings. An example of this is the ondemand CPUfreq governor. Rather than attempt to provide a static configuration, the processor frequency is automatically changed to meet demand while also keeping the overall power consumption as low as possible. This patch adds a thermal component to its policy, preventing the machine from overheating. Result? No requirement to provide tunables to userspace.

Something similar is achievable with hard-drive spindown. By simply monitoring how often reads or writes actually hit disk, it's possible to automatically adjust the spindown period to obtain decent power savings while reducing the number of spinups. This approach is imperfect - in an ideal world we'd know to spin the drive up before it's needed, but that simply isn't possible. However, the user is almost certainly unable to make a better guess. It's not realistic for a user to be able to predict whether or not a given page is still in cache or has been evicted. Nothing is lost by providing a dynamic policy, and another unnecessary tunable has vanished.

The difficult part of an adaptive policy comes when roles are switched in ways that don't correspond to changse in hardware status. One of the most common cases is that of screensaver settings when the user is watching a video. It's not practical for the kernel or a system daemon to predict this case, so we have two choices:.One of these choices involves the user having to explicitly state something that's obvious - playing a video automatically implies the desire to adopt a different power management policy, and so asking the user to manually adjust that is ridiculous.

The loss of hotswap notifications when ALPM is enabled? Simply reenable it if SMART starts complaining or the RAID set becomes degraded or a filesystem is unmounted or any of the other things that will have to be done before a drive can be safely removed. Latency an issue? Let userspace tell you what its latency requirements are. When we get down to it, the only settings that we can't infer are things like idle-time-to-suspend, screensaver settings and default brightnesses. Which, curiously, are about the only things that Mac OS exposes[1].

The problem we face is that we don't currently have interfaces to let applications tell us what their requirements are. This is theoretically straightforward, but getting it right is important. Beyond latency and screensaver issues, what constraints do applications want to impose? How can we expose an interface to those constraints? This is the sort of thing we'll be looking at at the Linux Plumbers Conference, so if you have ideas about what they'd need to look like then sign up. Or, even better, submit a paper and be part of the process that gets Linux's power consumption as close to the theoretical minimum as possible.

[1] My Vista system gives me 25 options which can be set for each of AC and battery.

23 June 2008

Obey Arthur Liu: Daniel Burrows on cwidget-gtk

Sometimes people propose other solutions to have the Aptitude-gtk project done, like :
I d have thought that the most interesting way of doing aptitude-gtk would be to write a gtk backend for libcwidget. -Karellen
As this might be of interest to more people, I’ll repost Daniel Burrows‘ response :
Although I can see where you re coming from, a GTK+ backend to cwidget would have no significant upsides and significant downsides. The main upside to doing that from a practical point of view is that you would have only one piece of driver code for the GTK+ and curses interfaces. You wouldn t have to rewrite the entire interface from scratch to create a GUI frontend. But this is just an illusory benefit. cwidget is a terminal interface library and aptitude s curses frontend is a terminal-based UI. From a practical point of view, this means that aptitude regularly assumes that, for instance, to clear out a line it s sufficient to output $WIDTH space characters (ASCII 32) with the desired background style. A port of cwidget to GTK+ would have to introduce new, interface-independent abstractions for all operations like this and eliminate all direct use of terminal-based assumptions, at a significant cost in complexity for both cwidget and the aptitude frontend. In order to transition to these new conventions, I believe you would have to rewrite large portions of both cwidget *and* aptitude in order to make the interface abstraction layer work. (remember: the justification for doing this is to avoid having to rewrite aptitude!) Furthermore, while this approach avoids reimplementing aptitude s curses interface (sort of, except where it doesn t see above), it does so at the cost of requiring you to reimplement all of cwidget, for GTK+. I just did a quick line count (with wc -l ): in all of cwidget there are 23,390 lines of code, while aptitude s curses frontend has around 23,359 lines of code (some of which are actually shared with the other frontends but are in the curses directory due to the historical organization of the code tree). Not only is a rewrite of cwidget more involved, but the amount of code you d have to replace is comparable to the amount implicated in a rewrite of aptitude itself! Finally, even if these costs weren t enough to eliminate the idea, it s not at all clear to me that a GTK+ backend for cwidget is even desirable. Although aptitude has some superficial similarities to a GUI program, the process of designing an interface to run in a terminal (where the available input mechanisms are relatively restricted and all output is to a character-cell grid) is rather different from the process of designing a GUI. GUI programs can t rely on some simplifying assumptions that terminal programs can, and at the same time they have a lot more options available to them (just to name a few: graphics, multiple windows, differing text sizes and rotated text). Trying to force everything through an abstraction designed for terminal output would require you to either
  1. eschew those options,
  2. provide abstract GUI components that somehow fell back to terminal rendering in a terminal, or
  3. add ways for the frontend to extend the abstract widgets with custom functionality.
1. is not an option because I (and, I think, Arthur) want to design a good GTK+ package manager, not a good GTK+ imitation of a console package manager. 2. and 3. amount, in my strong opinion, to writing two separate interfaces but intertwining their implementations in a mass of maintenance-resistant and extension-resistant spaghetti code. At the end of the day, I think that having two separate frontends (sharing backend logic where appropriate, of course) is a far cleaner and more maintainable design, and also easier to create.
As I said earlier, I intend to go a little farther than just making a GTK+ “skin” over the curses interface. Think less like gvim and emacs and more like maybe ddd. I should also add that the cwidget library is used by no major programs except Aptitude so few others would benefit from a GTK+ backend. As the cwidget library homepage says:
cwidget was originally an internal user interface library for the aptitude package manager. This means, on the one hand, that cwidget is known to work in the real world for a real application; on the other hand, it means that the feature set of cwidget is coextensive with the requirements of aptitude.

Russell Coker: TED - Defining Words

I recently joined the community based around the TED conference [1]. The TED conference is expensive ($6000US) and has a long waiting list (the 2009 conference is sold out) so it seems quite unlikely that I will ever attend one. But signing up to the web site is easy and might offer some benefit. One thing that interested me was that part of the sign-up process requests that you select up to 10 words from the list above to describe yourself. Some of the words seem almost mandatory for anyone who is interested in what TED has to offer (I find it difficult to imagine someone declaring that they are not an “activist” or a “change agent” while wanting to be involved with TED in any way). The range of words also seems quite strange, there are some professions mixed with educational status, marital status, and religion. The way it is laid out would tend to encourage people to make a decision as to which aspects of their life are more important, is career, marital status, or religion more important? Given the nature of TED I’m wondering whether the intentionally did a bad job of that part of the site design to encourage people to think about these issues. It seems to me that a better way of doing this would be to provide a few suggestions and allow people to fill in text fields with their own values. Even defining marital status can require many choices and there is no limit to the number of religions and careers. If you try to make a comprehensive list then you will end up doing what British Airways did with their frequent flyer membership application page [2]. Even disregarding the choices of spelling (EG Admiral vs Admiraal and Brig Gen vs Brig General vs Brigadier General) the British Airways list is unreasonably long, and I doubt that anyone who deserves the title “Her Magesty” or “His Holyness” is going to be interested in frequent flyer points. Also I wonder which of the entries in the TED list would be most commonly accepted by the free software community. It seems that activist and technologist would be quite popular. Here is the list in text form for those who can’t get the picture above:

Activist, Agnostic, Architect, Artist, Atheist, Athlete, Blogger, Brainstormer, Buddhist, Business adviser, Business leader, Business mentor, Care taker, Change Agent, Christian, Clergy, Concerned citizen, Connector, Consultant, Designer, Doctor, Educator/Teacher, Engineer, Entrepreneur, Environmentalist, Event planner, Explorer, Filmmaker, Finance professional, Foodie, Gay, Global soul, Hindu, Idea generator, Industrialist, Inventor, Investor, Jewish, Job-seeker, Journalist, Lawyer, Life mentor, Marketer, Musician, Muslim, Parent, Performer, Philanthropist, Photographer, Policy maker, Potential employer, Producer, Project manager, Promoter, Public servant, Real Estate professional, Sales specialist, Scientist, Single, Social entrepreneur, Startup, Student, Technologist, Web guru, World traveler, and Writer/Editor.

Share This

Next.

Previous.