Monthly Archives: March 2008

Ubuntu Hardy backgound guerilla marketing

Posted on by
7

Did I already mention I really like the default background image for Ubuntu Hardy Heron? It is called “Warty Final” (confusing name scheme) and was created by Feta Kuti. It’s a new fresh style (correct me if it is older and I’s always missing it) apart from all those water-chocolate-thingies (which we have seen enough, haven’t we?). I already got asked about the background from people standing behind me several times. “Warty Final” already enhances some Windows backgrounds. Ubuntu Guerilla marketing in an artistic way. Nice work!

ubuntu background image

[update]
A comment by user AshCroft (thank you!) stated that Feta Kuti is an “Afrofunk/Jazz Saxophonist whose music was some of the inspiration for the heron and was chosen as the name for the art submission”.

good howto: Bash Pitfalls

Posted on by
Reply

There is a very nice collection of common Bash scripting pitfalls and hints on how to avoid them on Greg’s Wiki: Bash Pitfalls

If you are writing little Bash scripts from time to time or are even a heavy Bash scripter, give it a try – it helps you avoiding errors that might work perfectly under normal circiumstances but suddenly go wrong… A good guide especially for writing server bullet proof scripts.

Having a Hardy day – Ten steps helping you not to have a hard time upgrading

Posted on by
16

So just before the first beta I finally updated my production machine to Hardy after feeling bad about not giving enough effort in testing for the last weeks. In one short sentence: It worked! In a longer sentence: It worked quite well, but…

If you plan to update your machine by calling “update-manager -d” on Gutsy or actually any other Ubuntu upgrade you might have a better time with the update by taking the following then steps before:

  1. Remove all applications you installed for testing purposes but don’t use them. It’s a nice feeling to have a mostly cleaned machine. Removing applications before an update reduces download time, the space needed and dependency calculations as well as the risk of a dependency failure. So just drop all those only once clicked applications, games and even libraries. Take some time for this, it will save you time later. Trust me.
  2. Check that you have enough space left on your device. Hundreds of packages are being downloaded in one step, therefore you should have enough disk space for this. Keep this in mind.
  3. Compiled software by your own? Installed external .deb-files? If possible: Uninstall them, you can later reinstall them if they are not provided by Ubuntu+1.
  4. Added software repositories to /etc/apt/sources.list (or Synaptec?). Disable them for now.
  5. Switched to a server close to you? For an update to an alpha or beta version it might be better to switch back to the main repository server as you are getting probably urgently needed updates faster (correct me if this is wrong).
  6. Of course: Back up, back up, back up. Decide, if a backup of your home directory fits your needs or you also want the rest of your partitions.
  7. Bring enough time: A full upgrade might take two hours and more, depending on your ram, cpu power, network speed and amount of installed applications. Don’t think an upgrade runs automatically – it will ask you several questions during package upgrades and therefore awaits your attention. Make the day your upgrade day or at least the afternoon your upgrade afternoon. A cup of tea might help.
  8. Check for already known caveats that you might take care of. Normally the most important ones are collected on the wiki page to the current alpha/beta release like this one.
  9. Make yourself clear what “alpha” an “beta” mean: Take them as warnings and only take the risk of an upgrade if you are not under time pressure for a project (like writing an essay, developing an application or anything with a deadline close to your upgrade day).
  10. Check if you have the possibility to have a second computer around enabling you for checking against discussion boards, wikis and other ressources of useful information. In case of an emergency it is crucial to be online in way because often really simple tricks can save your day.

After these steps, feel free to give “update-manager -d” a try. Take notes of things that look strange and check launchpad bug tracker if they are already reported. Now it is up to you to help making Ubuntu a better distribution and Hardy a really success.

Good luck!

p.s.: And if you want an example of things that *can* go wrong: After upgrade I noticed my wireless connection was down as the device was missing (no eth1 anymore). After searching the web I found out that the package “linux-ubuntu-modules-2.6.24-12-386″ was not installed though it should have been. An “aptitude install linux-ubuntu-modules-2.6.24-12-386″ over a wired connection solved the problem.

One step forward, two steps back – AOL’s new “openness”

Posted on by
1

Great news! AOL finally opens it’s OSCAR protocol for developers by providing extended information through its OpenAIM program with a SDK, tutorials and all you need to build up aim compatible messengers or even bots. But is it that open? I mean, we know the difference between “open” and “free”, don’t we? So a closer look at the license terms shows things you really don’t want to see and that are just unacceptable:

1. The “choose two from five” rule:


“Additional Feature Requirements. Any Custom Client or Web AIM Developer Application that you distribute must include at least two of the following features or functionalities (“Additional Features”) as an integral part of such distributed Developer Application:
  1. AIM Expressions. Inclusion of the capability for your users to choose and display a Buddy Icon to customize his or her user experience and provide a link to the AOL-Hosted AIM Expressions web page as documented in the AOL Additional Features document.
  2. AIM Toolbar. Inclusion of the AIM Toolbar as a user-selected option during the registration/download/installation process for the Developer Application, as applicable.
  3. AIM Start Page Launch. Inclusion of the launch of the AIM Start Page upon users. logon to your Site or to the Developer Application.
  4. Buddy Info. Inclusion of content provided by AOL that includes information about a user’s online status, including the user’s AIM profile, and AOL-supplied advertising.
  5. Advertisement. Inclusion of an AOL-provided display advertisement (“Advertisement”) within your Custom Client, Site or activity window. Unless otherwise provided in a written agreement, all revenue from such Advertisement will belong to AOL.”

source: http://dev.aol.com/aim/license

So let’s say you want to develop a free, non-commercial client. Your best choice’d be choosing to implement “AIM Expressions” and “Buddy Info”. That might be okay but it might be not. And actually it should be your decision, shouldn’t it? Even more interesting: What about console clients? Yes, they are around and it might be possible they haven’t ever heard of icons. Are they disallowed by default? Aren’t you free to choose a very different style of artwork for “expression” by dropping the standard set and developing a new one?

2. The additional “hope to be unsuccessful rule”

Okay, this might be pettifoggery, but let’s also assume your client is implemented with the mentioned
requirements, people start to download your client, so it is widely used. Fine? Uh, yes, AOL thinks so too, as they are really interested in that:

“In addition to, and not in lieu of, the above requirements, in the event that the number of simultaneous users of your Custom Client or Web AIM Developer Application reaches a peak level of 100,000 at any time (as defined by AOL and provided at http://developer.aim.com/manageKeys.jsp) you must either: (i) within ninety (90) calendar days also include an Advertisement within your Custom Client, on your Site or the primary activity window of your Open AIM Developer Application, and discontinue any version of the Custom Client or Site/Activity Window that does not include an Advertisement; or (ii) within fifteen (15) calendar days, contact AOL at the following address: aimcommercial@aim.com and reach agreement on alternative arrangements satisfactory to AOL.”
source: http://dev.aol.com/aim/license

So what is this about? If your application is a success, make it commercial in a way. Free software is for a niche, big market shares are for winners? Be afraid of having 100.000 peak users? Stop distributing uncommercial clients if having success?

So, really thank you, AOL, for moving towars openness. But the way you define “open” is not the way we mean it. It is not even “free beer” you are giving away, it’s a glass of free beer with a big refund sticker on it. But you already showed that you know what is all about: Just a couple of weeks ago information about a xmpp/jabber aol/aim test server leaked and you might have noticed how enthusiastic people were. Stick to it, be brave! Other big companies already use it by default.

Think about companies forcing developers to implement similar “features” into mail applications just because they transport mail to a specific domain, with a specific mime type or whatever. You would not like it? We don’t either. Make your protocol open and free. Your users are users – not customers, developers not employees.

using postfix for secure tests with live data

Posted on by
Reply

During web development and quality assurance you sometimes want to test an application with live data (e.g. a web shop test instance with live customer sql data). As your application implements mail functionality you have to make sure that no mail on the test server is sent to a real user but you probably want to be able to send mails to developers and receive all other outgoing test mails in a catch-all account. An easy Postfix tweak for this is using a pcre regular expression virtual map.

So our goal is: All outgoing mails to a specific domain should be delivered normally (e.g. your company domain) while all other outgoing mails should be delivered to one specific catch-all mailbox.

Actually this task can be resolved by adding not more than three lines of configuration code in two files.

1. in /etc/postfix/main.cf add

virtual_alias_maps = pcre:/etc/postfix/virtual.pcre

2. the new /etc/postfix/virtual.pcre should look like

/(.+)@yourowndomain\.tld$/ ${1}@yourowndomain.tld
/(.+)@(.+)/ catchoutgoing@yourowndomain.tld

After having restarted postfix you are already done.

Please note, a ${0} instead of ${1}@yourowndomain.tld did not work for me, so this a tiny workaround which does not look beautiful but really does it’s job.

p.s.: A really nice (but somehow old looking) tool for developing and testing regular expressions is “redet“, a “regular expression development and execution tool” which knows nearly every important regex syntax depending on the tools you have installed. You’ll find redet in your Debian/Ubuntu repository.