To directly quote from Felipec’s post in his blog:

After a bit more than two years of development we are proud to announce the first stable release of msn-pecan. The project started as a “fork” of libpurple’s msn protocol (read below why it’s not really a fork), but it has grown and soon will become a standalone library with support for Telepathy too.

Even though I have only 3 of the 1009 patches and although I don’t understand any of the code itself, I gotta admit I really feel like I’m part of the project.

7 years ago I started a project to write a text mode, ncurses-based MSN client for Linux. The project is still registered on Sourceforge as msnclient. It was my first attempt at writing free software. However, the challenge was too much for me and the project quickly died. I never got further than logging in and sending a single-worded message to another contact.

I eventually started to learn how to use Pidgin and got my self good hardware and my need of a personalized MSN client was no more. I still think, however, that msnclient is a good concept to try to bring to life. Maybe some day it will be an interface based on the msn-pecan functions.

That said, in mid 2009, when I started learning Git, felipec provided me a branch from his repository to test the direct connection feature (better known as “fast file transfers” or “p2p file transfers”). It didn’t work that time.

6 months went by and lot of commits over his master branch were too. 0.1.0-rc1 came out and directconn was still not working but the dc-test branch was relly old now. I had learned enough about Git and I though that I was better enough to try fixing the DC code. However I really knew nothing about the MSN functionality and I really didn’t understand the code. Well, at least I knew what the first step was: I had to rebase it anyway. So I tried to bring that old branch to the new code base so it could be (at least) useful to the developers. So war was lost for me, but perhaps felipec would get encouraged enough to restart working over this part of msn-pecan (but you’re not supposed to say that, right?). That’s how I saw it and how I got my motivation to do it; also, I would be my first actual real-world git rebase.

The main problem was that felipec had done a lot of relevant code reorganization, renaming and splitting in July (some done good, some done badly). Using some C experience I managed to rebase it and sent it in as a couple of patches.

Suddenly, felipec continued work on directconn. I don’t know if it was because of the patches or not; that doesn’t matter. The important thing is that in msn-pecan 0.1.0, direct connections now work and are stable. Even if not in all cases, it is a great step.

Now I think it went beyond learning how to rebase: I actually learned how to contribute using Git, just like the big boys do in the Linux Kernel project. I still don’t understand the code and the inner workings of the project but those two patches allowed me to learn a lot about software collaboration and review. This was particularly helpful for Superkb which is also written in C and its source code managed in Git.

So, thanks again felipec, congratulations and we all should have a drink for the project, even if on different parts of the world! Let’s party and spread the word.

Es un video con los experimentos realizados por el Dr. Donald Pettit, astronauta, Ingeniero de Vuelo y Oficial de Ciencias de la expedición 6 a bordo de la Estación Espacial Internacional.

Según la página de Saturday Morning Science, “hasta en su tiempo libre, los astronautas a bordo de la ISS están descubriendo cosas nuevas y sorprendentes sobre la naturaleza”. Según Don Pettit, estos experimentos no se tenían programados como parte de la misión; no eran ciencia “programada” sino ciencia “de oportunidad”.

Este video es un video crudo y directo al grano; tal vez sea una versión compilada; pero hay otras versiones en YouTube y la galería de videos de la expedición donde están editadas a modo de entrevista con un poco más de explicación.

Espero que los disfruten tanto como yo y se sorprendan tanto como los astronautas.

For now, it is only in English. I’m really looking forward to adding a full Spanish equivalent.

I think this will make it a lot easier to keep the documentation up to date.

The SourceForge Wiki doesn’t allow anonymous contributions, so an SF account is needed to include the people in the editors group.

Suggestions and contributions are welcome.

auto br0
iface br0 net dhcp
   bridge_ports eth0 eth1
   bridge_stp off
   bridge_fd 3

I have always felt the EIGRP metric as being really overwhelming. I see values like “2820096″ and instead of understanding it, I always end up asking what the hell does that number mean.

For example, in RIP:

R    192.168.0.0/24 [120/3] via 172.16.1.1, 00:00:15, FastEthernet0/0

Just by looking at the metric of “3″ I immediately know what is means: there are three steps between the announced network and the router receiving the advertisement. Easy, right? “Understanding the number” makes it easy for me to manage and diagnose it.

In OSPF, the metric (cost) is still not as cumbersome as EIGRP’s. However, in the following example, can you identify what does “66″ mean? For you, is it “just a number” that won over another because of its numerical value being lower? How do you know if the number is right or not?

O   192.168.0.0/24 [110/66] via 172.16.1.1, 00:00:82, FastEthernet0/0

The EIGRP metric formula is better, functionally speaking. It is calculated from various components. As a result, it is more complex. Furthermore, the resulting value is bigger. When you try to read the number in the route table, it is no longer obvious.

D   192.168.0.0/24 [90/2820096] via 172.16.1.1, 00:00:12, FastEthernet0/0

So, what does “2820096″ mean? Well, it’s pretty simple. Take 2820096 and divide it by / 25600 and you get the estimated travel time in milliseconds: .

The EIGRP metric is an approach to calculating the total travel time. By default, EIGRP calculates the packet travel time like is: take the transmission delay in all hops in the path (the famous “delay” part) and —instead of adding all of the serialization delays— add only that of the bottleneck bandwidth for a 100 Kilobit sample.

The goal of this article is to show you how to mathematically get to that conclusion in the particular case of the default K values. This will allow the article to be much shorter and understandable, because the rest of the terms that compose the complete EIGRP metric are more complex and there is less on-line documentation reference for those. Also, Cisco doesn’t recommend changing the K values by default unless you REALLY know what you are doing.

Besides, we can get our engines started and warmed up for a later article with an analysis for the whole formula, don’t we?

Step 0: Starting to think

To put a “meaning” to this number, I will first ask you: if you designed your own “perfect” routing protocol, what would you use as a metric? What formula do you think would provide the routers with the best and closest to reality information in order to always take the most optimal routing decisions, at all times, and whatever the network circumstance is? It is not an easy question, though it is one that any protocol designer will never be able to escape. Think about this for a moment.

When I asked myself this question, my answer was: I think everybody wants the packets to get to its destination (unmodified, of course) as quickly as possible. I would like all participating routers to know the exact time it will take a packet to get to router B. Travel time should be used as *the* metric. In my “perfect” routing protocol, the metric would be measured in some submultiple of seconds. Even the Internet would be better if this were true, except that it’s way too expensive, complex, and difficult to manually control if done this way (that’s were BGP jumps in).

The EIGRP protocol gives it a shot at this approach.

Quoting complete the EIGRP metric formula, by Cisco

To analyze the default metric behavior I will start by quoting the complete EIGRP metric formula specified by Cisco¹:

where:

• 
  • where is the least bandwidth of all outgoing interfaces on the route to the destination network represented in kilobits.
• 
  • where is the sum of the delays configured on the interfaces, on the route to the destination network, in tens of microseconds. The delay as shown in the show ip eigrp topology or show interface commands is in microseconds, so you must divide by 10 before you use it in this formula. Throughout this paper, we use delay as it is configured and shown on the interface.
• If , the formula reduces to .
• Cisco routers do not perform floating point math, so at each stage in the calculation, you need to round down to the nearest integer to properly calculate the metrics.
• The default values for K are:
  • 
  • 
  • 
  • 
  • 

For default behavior, you can simplify the formula as follows:

I found out that sentence to be a source of confusion for myself. Even the simplified, default-behavior metric formula is expressed in a way that assumes we can add apples and oranges, though this is impossible. Cisco wants us to add “bandwidth” with “delay”. So, how do they actually do it? How much is “10 bps + 10 s”?

Step 1: Arranging the mathematical expression in its default K values

Let’s try to state the formula in its default behavior. I will use the following symbols:

• : metric.
• : resulting scaled bandwidth.[/pmath]
• : bandwidth(i), the least bandwidth of all outgoing interfaces on the route to the destination network represented in kilobits.
• : resulting scaled delay.[/pmath]
• : delay(i), the sum of the delays configured on the interfaces, on the route to the destination network, in tens of microseconds.
• : 1000000 (as in 10 Mega-something).

Let’s arrange the formula in a way it really looks like a mathematical equation:

where:

Step 2: moving the “256″ out of the way and getting to the original IGRP metric formula

EIGRP metric is 256 times that of IGRP². This is easily provable: as both, B and D are a multiple of 256, we can divide by it. The result is the exact original IGRP formula3. (Though this is also true in the complete formula, please remember we are only working with the particular case of the default metric behavior.)

This means that the EIGRP metric will be always inflated and will be a multiple of 256.

Let’s do the procedure. First, lets get all into one big formula. Let’s replace B and D for their corresponding formulas:

There we can see how the 256 factor is present in the two terms. We could factor it out but for convenience I will divide everything by 256.

The right side is the default metric for IGRP.

Step 3: Unit analysis and T₃

Or put another way: what is the resulting value measured in, is it Kilobits, seconds, hops, packets…?

The last formula from step 2 has the following form:

where:

• (metric)
• 
• 

The terms and must have the same units. Otherwise, addition couldn’t be possible.

The easiest term to analyze is . According to Cisco must be in tens of microsegundos. Therefore:

And thus, units (and therefore the whole M units) must be tens of microseconds, also.

So:

• (time)
• (time)
• (time)

So, given is a delay, the other term and the total metric must be a delay too in the same scale. Remember what I said at the beginning about using travel time as my “perfect” metric for a routing protocol? EIGRP is actually giving it a shot.

Step 4: Analyzing T₁

In step 3 we let be defined as:

And also that must be in tens of microseconds.

We know the units for and , but what are the units for ?

: tens of millibit

How many bits are ?

So finally, is like this:

Just like , also , so means “serialization delay for 100 Kbits under that bandwidth B_min“.

Conclusion and interpretation

D   192.168.0.0/24 [90/2820096] via 172.16.1.1, 00:00:12, FastEthernet1/1

We know that 2820096 is given in and multiplied by 256.

So we take 2820096 / 256 = 11016.

To convert it to instead, divide the metric / 25.6:

Or to milliseconds, divide it by / 25600:

As I said, the EIGRP default metric is an approach to calculating the total travel time. By default, EIGRP calculates the packet travel time like is: take the transmission delay in all hops in the path (the famous “delay” part) and —instead of adding all of the serialization delays— add only that of the bottleneck bandwidth for a 100 Kilobit sample.

References

¹ Cisco Document ID 16406, actualizado: Sep 09, 2005. Enhanced Interior Gateway Routing Protocol: http://www.cisco.com/en/US/tech/tk365/technologies_white_paper09186a0080094cb7.shtml

² IP Routing, by Ravi Malhotra, January 2002. Chapter 4: Enhanced Interior Gateway Routing Protocol (EIGRP) http://oreilly.com/catalog/iprouting/chapter/ch04.html#45434

³ Cisco Document ID 13678, actualizado: Aug 10, 2005. IGRP Metric [IP Routing], http://www.cisco.com/en/US/tech/tk365/technologies_tech_note09186a008009405c.shtml

Introduction

The most ignored Internet Etiquette rule is that of the posting style when replying to an e-mail message.

By “quoting” I mean the inclusion of a previous message in a new one (for example, a reply) with the intent of stating the relevance of the answer itself in the original context. I would say “Dan, I don’t know what are you talking about. Please quote the original e-mail in your reply next time in order to know what were you replying to.”

Almost every e-mail client do quote the original message in the reply, at least by default. That is good, and it contributes to the “netiquette”, but its abuse has made it completely useless.

By saying that the rule is “ignored”, I mean that the common user doesn’t edit the text put by the e-mail client as the quote. It leaves the quoted message as is, simply ignoring the resulting text. After three iterations of the answer, the “original message” carries more garbage than relevant content.

Common e-mail clients —like Outlook y Thunderbird— don’t help either; those are pretty stupid. They quote whatever they find. Even when the original goal is to place the original message in the editor ready for its editing while replying, it is also true that signatures and those hideous legal disclaimers are stupidly included also.

Ok. Beyond the rant, the main purpose of this article is to show the current quoting and reply techniques, but more important, to yearn for a style / technique used more than 15 years ago, even before Internet started to be popular in the city where I live.

A correctly applied etiquette to an e-mail reply allows a well-organized message. This etiquette is mainly formed by two elements: (a) the correct placement of the answer in relation to the quoted message and (b) the correct editing of the quoted message.

Reply text placement against the quoted text

The best way to explain this is to mention the three different styles and the difference between them: top-posting, bottom-posting and interposting (or in-line posting). It refers to the placement of the answer before, after or inserted into the original text.

Example A: top-posting

Yes, and I'm going to do it.

On Fri, Jun 26 2009 17:42:34 -0700, Hitsuo Tikashi <hitsuo.tikashi@sistint.com.mx> said:
> Octavio:
>
> Is the maintenance window on next Thursday?
>
> Who's going to execute the changes?
>
> Regards.
>
> ---
> Hitsuo Tikashi.
> Infrastructure Services Manager.
> Integrated Systems, Inc.
> T. +1 (619) 555-1234
> E. hitsuo.tikashi@sistint.com.mx

Example B: bottom-posting

On Fri, Jun 26 2009 17:42:34 -0700, Hitsuo Tikashi <hitsuo.tikashi@sistint.com.mx> said:
> Octavio:
>
> Is the maintenance window on next Thursday?
>
> Who's going to execute the changes?
>
> Regards.
>
> ---
> Hitsuo Tikashi.
> Infrastructure Services Manager.
> Integrated Systems, Inc.
> T. +1 (619) 555-1234
> E. hitsuo.tikashi@sistint.com.mx

Yes, and I'm going to do it.

Example C: interposting (or inline-posting)

On Fri, Jun 26 2009 17:42:34 -0700, Hitsuo Tikashi <hitsuo.tikashi@sistint.com.mx> said:
> Octavio:
>
> Is the maintenance window on next Thursday?

Yes.

>
> Who's going to execute the changes?

I am.

> Regards.
>
> ---
> Hitsuo Tikashi.
> Infrastructure Services Manager.
> Integrated Systems, Inc.
> T. +1 (619) 555-1234
> E. hitsuo.tikashi@sistint.com.mx

Which one do you think is the best? All of them has pros and cons, so the answer may be different in each environment. What do you think are the pros and cons of each?

For instance, In some mailing lists, top-posting is more than prohibited. Either you do bottom-posting or, better yet, interposting. This has been used since before the existence of e-mail as is known today.

However, in businesses and common use, the most popular style is top-posting, due to the easiness of just “writing and sending” without worrying for anything else; this has moved the MUAs (e-mail clients) to be configured for top-posting out of the box. This, in turn, makes it even more popular.

Proper editing of the quoted text

The last example of interposting made it easy to show how a great part of the reply text is just useless. It is considered that the quoted text is part of the reply, as it occupies disk space as part of the reply.

I’ll use that interposting example as the case to analyze, but the following applies to either of the three quoting styles.

From the word “regards” on, the text is irrelevant, and thus, useless. Maybe we could say that the line “Octavio:” is also irrelevant, but let us not be so picky at the moment. In numbers, 8 out of 21 lines (38%) are useless; so are 25 of the 59 words (42%); and so are 161 of the 373 characters (43%). We still have to take into account that mi reply signature is not there, so that will slightly lower those ratios.

Example D: Proper quoting in top-posting

Yes, and I'm going to do it.

On Fri, Jun 26 2009 17:42:34 -0700, Hitsuo Tikashi <hitsuo.tikashi@sistint.com.mx> said:
> Octavio:
>
> Is the maintenance window on next Thursday?
>
> Who's going to execute the changes?
>

Example E: Proper quoting in bottom-posting

On Fri, Jun 26 2009 17:42:34 -0700, Hitsuo Tikashi <hitsuo.tikashi@sistint.com.mx> said:
> Octavio:
>
> Is the maintenance window on next Thursday?
>
> Who's going to execute the changes?
>

Yes, and I'm going to do it.

Example F: Proper quoting in interposting (or in-line posting)

On Fri, Jun 26 2009 17:42:34 -0700, Hitsuo Tikashi <hitsuo.tikashi@sistint.com.mx> said:
> Octavio:
>
> Is the maintenance window on next Thursday?

Yes.

> Who's going to execute the changes?

I am.

The main argument for not editing the quoted text would be that it takes a long time to do it and it is done inefficiently. At home, this is called “lazyness”.

This will be the argument for those that don’t know the keyboard shortcuts for text editing, in particular the use of the Shift key as a non-written standard to select text. Using Shift and the arrow keys, followed by “Delete”, is extremely easy to select and erase useless text.

Yearning for Blue Wave and FidoNet

Before going into user interfaces and mobile devices, I’d like to take a momento to show my yearning feeling for the times where I wrote in FidoNet, even before the Internet started to be popular in Tijuana (1994 to 1996).

In FidoNet, it was common to do this a little different. I used a popular shareware named Blue Wave Offline Reader. Many of us used Blue Wave, which had a particular way of preparing the quoted text before putting it into the editor:

On Fri, Jun 26 2009 17:42:34 -0700, Hitsuo Tikashi said:
 HT> Octavio:
 HT>
 HT> Is the maintenance window on next Thursday?
 HT>
 HT> Who's going to execute the changes?
 HT>
 HT> Regards.
 HT>
 HT> ---
 HT> Hitsuo Tikashi.
 HT> Infrastructure Services Manager.
 HT> Integrated Systems, Inc.
 HT> T. +1 (619) 555-1234
 HT> E. hitsuo.tikashi@sistint.com.mx

The interesting thing is not in the inline replying. Same as today, a couple of Enters in the right place allowed me to reply in-line.

To erase from “Regards” on, still same as today: I place the cursor in the “R” from “Regards” and Shift+Ctrl+End, Delete and voilà: message is clean.

And so was my answer:

On Fri, Jun 26 2009 17:42:34 -0700, Hitsuo Tikashi said:
 HT> Octavio:
 HT>
 HT> Is the maintenance window on next Thursday?

 Yes. Even thought the changes are not considered to be critical, in case
 of a possible failure we will affect our service level agreements,
 because less than 30 days ago our carriers suffered an outage.

 HT> Who's going to execute the changes?

 I am.

What is really interesting is that when the original sender tried to reply me back, the text would be automatically adjusted to the line length (properly word wrapped) and quoted in the following way:

On Fri, Jun 26 2009 17:42:34 -0700, Octavio Alvarez said:
 HT> Octavio:
 HT>
 HT> Is the maintenance window on next Thursday?
 OA>
 OA> Yes. Even thought the changes are not considered to be critial, in
 OA> case of a possible failure we will affect our service level
 OA> agreements, because less than 30 days ago our carriers suffered an
 OA> outage.

 Acknowledged. I leave it in your hands and keep me informed.

 HT> Who's going to execute the changes?
 OA>
 OA> I am.

 BTW, who will monitor and operate the services the next day?

In the example, the user interleaved its answers to me.

Notice how the quoted lines don’t exactly match the original lines. those were modified intelligently, being considered as a paragraph and adjusted to keep a solid and consistent text block.

Also, notice how the text is clear enough and easy to follow; even more if the reader and editor software puts the different authors in different colors.

This style, beyond organized is scalable. After multiple iterations, the format and the text are kept organized.

On Fri, Jun 26 2009 17:42:34 -0700, Octavio Alvarez said:
 HT> Octavio:
 HT>
 HT> Is the maintenance window on next Thursday?
 OA>
 OA> Yes. Even thought the changes are not considered to be critial, in
 OA> case of a possible failure we will affect our service level
 OA> agreements, because less than 30 days ago our carriers suffered an
 OA> outage.
 HT>
 HT> Acknowledged. I leave it in your hands and keep me informed.
 OA>
 OA> Ok, I'll send you an SMS, according to the procedure.

 And please send it to me via e-mail, also.

 HT> Who's going to execute the changes?
 OA>
 OA> I am.
 HT>
 HT> BTW, who will monitor and operate the services the next day?
 OA>
 OA> It would be the new team member, but we have already asked everyone
 OA> else to be alert and ready in case of any eventuality.

 Have you exchanged phone numbers yet?

From my point of view, this is much more intelligent than its popular counterpart:

On Mon, Jun 29 2009 17:42:34 -0700, Octavio Alvarez <alvarezp@alvarezp.ods.org> said:
> On Sun, Jun 28 2009 17:42:34 -0700, Hitsuo Tikashi <hitsuo.tikashi@sistint.com.mx> said:
> > On Sat, Jun 27 2009 17:42:34 -0700, Octavio Alvarez <alvarezp@alvarezp.ods.org> said:
> > > On Fri, Jun 26 2009 17:42:34 -0700, Hitsuo Tikashi <hitsuo.tikashi@sistint.com.mx> said:
> > > > Octavio:
> > > >
> > > > Is the maintenance window on next Thursday?
> > >
> > > Yes. Even thought the changes are not considered to be critial, in
> > > case of a possible failure we will affect our service level
> > > agreements, because less than 30 days ago our carriers suffered an
> > > outage.
> >
> > Acknowledged. I leave it in your hands and keep me informed.
>
> Ok, I'll send you an SMS, according to the procedure.

And please send it to me via e-mail, also.

> > > > Who's going to execute the changes?
> > >
> > > I am.
> >
> > BTW, who will monitor and operate the services the next day?
>
> It would be the new team member, but we have already asked everyone else
> to be alert and ready in case of any eventuality.

Have you exchanged phone numbers yet?

This is the best the current e-mail practices can get us. It is not bad, but only if the authors and client software follow the etiquette.

If not, we get:

• Badly nested quoting prefixes like: > >> > >>> >
• Badly split lines for exceeding a line length.
• Fully quoted messages, including irrelevant paragraphs.
• HTML garbage from improper tag handling.
• Messages full of signatures and legal texts (sometimes in more than one language per message).

Even though a message from an author that followed the etiquette is a lot better than what we see in a day-to-day basis, i feel it far from the comfort of working in the Blue Wave / FidoNet style.

About user interfaces

E-mail clients fail in promoting the etiquette culture in e-mail messaging.

I think there could be a signature detection mechanism and automatically exclude it from the quoted text. This would save us from getting three copies of the same bulk after three replies:

> ---
> Hitsuo Tikashi.
> Infrastructure Services Manager.
> Integrated Systems, Inc.
> T. +1 (619) 555-1234
> E. hitsuo.tikashi@sistint.com.mx
>
> The content of this e-mail message and its attachments is confidential
> and may be protected by Copyright law. It is intended exclusively to the
> addressees and them only. If you have received it by mistake, you must
> eliminate it from your system. In this case you are not allowed to copy,
> print or distribute this e-mail or its attachments nor use them for any
> purpose of allowing its contents to be known by any person. The here
> included information is not necesarily backed up by [CORPORATION NAME]
> or any of its subsidiaries or strategic alliances.
>
> Please consider the environment before printing this message.

Note: I’ve seen that last line in some messages. I included it because I just couldn’t help myself from using my poor sarcasm after seeing that call for the ecology right after that waste of electricity and disk space (that is usually in HTML format).

Mobile devices

In a 160×320 screen and an itsy bitsy teenie weenie keyboard one could argue that is difficult to do all of this editing in a practical way. However, in the same way new mobile devices present the user an appropriate interface to do other common tasks in a different way, it is the UI that holds how easy or impossible the editing would be.

If in-line posting were popular, a mobile device would have a function or command to “answer below this paragraph” or “navigate by paragraph” and choose “reply, leave or snip” each of them and maybe even an option to “erase the rest of the text”.

If the UI doesn’t have it, it is because in-line posting has not been that popular and not requested enough. It is still a deficiency, though.

Conclusions

I’ve tried to show show the style in example F is the most organized and scalable among all possible, based on previous experience from Blue Wave and FidoNet.

Personally, I try to go with the same style that most of the people use in the same context. It’s the best. A people replying with interposting in a mailing list where everybody top-post (for example, at work) will only confuse for everybody.

I have nothing else to say than to throw a call to those that participate in discussion groups, mailing lists (and, in particular those in technical areas) that at least we observe this etiquette guides among ourselves:

• Reply in line to the topics in the original answer.
• Eliminate irrelevant parts of the quoted message. Signatures and legal texts in particular.
• Rearrange illegible paragraphs (word wrapping, for example).
• Use correct spelling and grammar.
• Back our text up with emoticons if confusion might arise.

Thank for the patience to read all the way to here.

gawk '{print "\007" $0 }'

This will effectively “prepend” a bell to each line.

You can convert this into an alias or a command (say /usr/local/bin/line-beep.gawk):

#!/usr/bin/gawk -f

{ print "\007" $0; }

So it can be used in a code like the following:

tail -f /var/log/messages | grep --line-buffered dhcpd | line-beep.bash

That’s why Opera can be set to ignore core X fonts, by unchecking the Enable Core X fonts configuration option. You can use this as a workaround.

So, the result of having this option enabled can be compared in the following images. The first image shows the rendering when the font-family: "Deja Vu Sans", sans-serif directive is used. The second image shows the same page when the “Deja Vu Sans” option is removed from the directive. In this second case, Opera renders the text using the “sans-serif” font, whatever it matches.

Seen from a different perpective, it appears to be that when Opera asks X for a font, X returns an antialised core font. Does this happen on other distributions too?

Continuing with the stream of web browser interoperability issues I recently found how to make Opera 10 work with a Cisco Secure Access Control Server 4.1.

The problem I experienced is briefly described as, clicking any option in the menu (in the left frame) will open the menu again in the right frame, instead of actually showing the selected option.

The answer is simple: set Opera to identify as Firefox for that domain or IP. This is located under Tools » Preferences » Advanced » Content » Manage Site Preferences. Add the site and under Network, change “Browser identification” to “Identify as Firefox”.

Here are the screenshots. Click on them.

Opera identified as such.

Opera identified as Firefox.

The analysis narrows down to this code in the menu:

// unfortunately the Object model in IE doesn't match the Netscape one so we have to check the browser...
if( "Netscape" == navigator.appName )
{
	obj.href=sequence_url;
}
else
{
	ua=navigator.userAgent;
	v=navigator.appVersion.substring(0,1);
	if ((ua.lastIndexOf("MSIE")!=-1) && (v!='1') && (v!='2') && (v!='3'))
	{
		// MSIE 4.0 and later.
		obj.href=sequence_url;
	}
	else
	{
		parent.parent.R.location=sequence_url;
	}
}

(some code snipped)

<A HREF="" TARGET=R onClick="getURL( this , 'setup.exe?action=make_r_fs&option=users' )" >
<IMG SRC="images/cisco_buttons/user-up.gif" BORDER=1 ALT="User Setup"></A>

So Cisco is actually trying to detect the UA, but instead of assuming a standards-complaint browser and applying special fixes for IE, it assumes IE and applies a special fix for Mozilla (Netscape).

That’s why changing the identifier for that site actually works. Now the JavaScript code correctly detects the UA and performs the correct action of loading the page in the “R” frame.

I just have to wait for Cisco to mark my exam as “valid”. I don’t find any reason for them not to.

I gotta take some rest for a few days. Next stop: ISCW.