Next Generation Optical Transport?

Currently, optical transport (both SONET and SDH) technology used in service providers have reached its maturity and seems have stagnated. There is really no new features implemented on this technology. Most technology vendors have implemented features such as BLSR, UPSR, Bridge-and-roll, Ethernet over SONET (using GFP), even DWDM.

But, if we see the distribution of bandwidth used by customers, seems there is still a lot of 'dark' fiber, in other words, much of the bandwidths are left unused. Are these slots are really unused? If we see, in United States itself, High Definition TVs have not reached a point that many people expect. What about the Internet? well, eventhough most of the service providers (telephone, Internet or TV cable) give broadband accesses, the numbers are not satisfactory.

Now it is coming Packet-Over-ADM using optical connection. Many people are expecting this will be the next generation optical transport. Even some vendors have already had thse PADM-enabled equipments.

Technology-wise it is next generation optical transport, but what about business-wise? Well, let see what is going to happen in near future.

My Book Collections on Linux

A few months ago I bought another Linux-related book titled Linux Kernel Development by Robert Love. Very good book indeed! I have read the first few chapters of the book and couldn't stop to finish it (well, it is hard for me as I need to spare my time to read a lot other books and documents too).
This book add collection to my Linux bookshelf, besides Linux Device Driver, Linux Kernel, and Linux Wireless.

KDE or GNOME?

I have been questioning myself about which GUI is best fit to my GNU/Linux. From user perspective, KDE is more comprehensive and complete. It supports many things and structured, because it uses QT from trolltech.com. The graphics itself is really good. On the other hand, GNOME is very open and easier to compile and also it comes from GNU with GNU Public License (GPL) and also seems more stable.

I have tried to compile my KDE from scratch and enabled many optimizations on my Pentium4 laptop (-O3, -mSSE2, -MFPMATH=SSE, -march=pentium4 -mthreads etc.). First I compiled my QT. This QT depends on CUPS, mySQL and some other modules to compile. After compilation, my KDE applications were not stable anymore. The printing did not work, my KMail sometimes crashed and so on.

While with GNOME, I compile some applications such as GAIM which required me to compile some GNOME modules and still it worked fine.

The total size of the modules are also less on GNOME than KDE. While in KDE, there is a lot of applications and modules, GNOME seems is more thin and fits to lower-end PCs.

Anyway, Linux community must decide which GUI they want to use for desktop Linux. Otherwise, they will be crushed by Apple's Mac OS which has decided to pulling their steer towards Intel processors. Yes!, they have decided for their next Mac computers to use Intel x64 dual or quad processors.

CORBA header

The CORBA messages are carried over TCP. Inside, each message consist of message header and message data.

The structure of message header is :

char[4] magic;
octet[2] GIOP_version;
octet flags;
octet message_type;
unsigned long message_size;

First 4 octets contain "GIOP", then followed with 2 octets of GIOP version (high byte is for Major version, low byte is for minor version).

flags (in GIOP 1.1, 1.2, and 1.3) is an 8-bit octet. The least significant bit indicates the byte ordering used in subsequent elements of the message (including message_size). A value of FALSE (0) indicates big-endian byte ordering, and TRUE (1) indicates little-endian byte ordering. The byte order for fragment messages must match the byte order of the initial message that the fragment extends.

The second least significant bit indicates whether or not more framents follow. A value of FALSE (0) indicates this message is the last fragment, and TRUE (1) indicates more fragments follow this message. The most significant 6 bits are reserved. These 6 bits must have value 0 for GIOP version 1.1, 1.2, and 1.3.

message_type indicates the type of the message; these correspond to enum values of type MsgType.

message_size contains the number of octets in the message following the message header, encoded using the byte order specified in the byte order bit (the least significant bit) in the flags field (or using the byte_order field in GIOP 1.0). It refers to the size of the message body, not including the 12-byte message header. This count includes any alignment gaps and must match the size of the actual request parameters (plus any final padding bytes that may follow the parameters to have a fragment message terminate on an 8-byte boundary).


MsgType definition:

enum MsgType_1_1 {
Request,
Reply,
CancelRequest,
LocateRequest,
LocateReply,
CloseConnection,
MessageError,
Fragment // GIOP 1.1 addition
};

So, message_type may containt 0 for "Request", octet 1 (00000001) for Reply an so on.

Forget My Ignorance! (answer to Bad Documentation...)

I am supposed to write this blog a while ago, but with all workload and family life, no time to update this blog. Anyway, a few days after I wrote the blog "Bad Documentation of Compaq Products", I went to CompUSA. A salesperson approached me and asked what he could help.
I told him that I was looking for FireWire cable for my new Compaq laptop. He then brought me to a rack full of different kind of cables. I told him that I had bought one (4-pin to 4-pin), but somehow could not fit to the laptop.

He asked me what kind of laptop I have. I explained to him that it is Compaq Presario R3000. He then brought me to computer section and we found the kind. He then tried the cable. In the beginning, it could not go all the way to the socket. He then carefully reinserted, and amazingly it fitted!.

I was stunned! How could this cable fits to the connector, while mine does not. Rushing back home (after saying to the salesperson that I will buy the cable if mine still does not fit), I carefully inserted it. First, it's kinda hard. I tried again, but now really align it and with little force. Voila!, it worked!

So, with this blog I would like to revise my previous blog. But, still Compaq does not provide a complete detail about some parts of the laptop.

Bad Documentation on Compaq Products

I had been wondering why my old video camera's I.LINK (or Firewire or IEEE 1394, either one as they are identical) cable could not fit to my Compaq Presario R3000z port. I thought, "aah...o course it does not fit, the other end that goes to the camera is Female 4-pin, while another end that goes to PC has 6-pin. I getta buy a 4-pin to 4-pin cable then".

I rushed to BestBuy (which is the closest electronic superstore from my home) and found one made by Sony. Suprised with its higher-than-expected price, I asked a salesperson overthere whether there is another option. He told me to go to Cable & Networking aisle. Gotcha! I found one with 10 bucks less than the Sony one (it's $32 or something, forgot). The cable is 4-pin M to 4-pin M.

Getting back home, I opened the box and then tried to connect it to the laptop. Suprisingly I could not make it!. After checking the pins and the shape I then realize the cable's connector is slightly in difference shape than the the laptop'. Damn! I had wasted 35 bucks for useless cable.

I went to compaq.com, but could not find anything related to this issue. I then went to google. After skipping some pages, I spot a page from hp.com documenting the laptop (forgot what's the title of the PDF file). But still could not figure out what kind of connector it requires.

I really am dissapointed to see a big company as HP misses this small-but-important thing. Their product documentation is bloody bad too. Hope they change that. I like their products (I have HP printer and later this R3000z). But the recent problem affects my rating of their quality to about below-average in term of documentation.