Trivia: Where did the Term "Endian" come from?

Question: Where did the term "endian" come from?

Answer: From "Gulliver's Travels".

Background History from www.dictionary.com.

The terms big endian and little endian come from Jonathan Swift's "Gulliver's Travels" via the famous paper "On Holy Wars and a Plea for Peace" by Danny Cohen. In Swift's novel, Gulliver discovers civil war has broken out among the Lilliputians over whether soft-boiled eggs should be opened at the big end or the little end.

In computer science, big-endian systems store the most significant value at the lowest storage address (i.e., first). Little-endian systems store the least significant value at the lowest storage address. Many mainframe systems use big-endian architecture, whereas PC's use little-endian architecture.

Differences in how varying computer architecture manage the issue of little endian versus big endian leads to problems when transferring data between computers with differing byte order. This problem is frequently referred to as the nUxi problem. The string "Unix" might look like "nUxi" on a machine with a different "byte sex" (e.g. when transferring data from a little-endian architecture to a big-endian architechture, or vice-versa).

If only FairCom had been around to resolve the disputes! By providing a uniformat server, FairCom allows developers to avoid this "nuxi problem".

c-tree's standalone models have supported the concept of UNIFRMAT for years. In fact, UNIFRMAT is one of c-tree's most appealing features. UNIFRMAT allows machines with alternate architectures related to byte ordering to read and operate on each other's data.

In the early years of c-tree, the best example of the utilization of this feature was allowing applications in Apple's Macintosh platform (HIGH_LOW environment) to operate on Windows (LOW_HIGH environment) data.

FairCom extends this feature to the c-tree Server as well:

• "HIGH_LOW Host" Server: Operates on LOW_HIGH data (i.e., a c-tree Server on Sun Sparc may read Windows data), but not on native HIGH_LOW data.
• "LOW_HIGH Host" Server: Operates on HIGH_LOW data (i.e., a c-tree Server on Intel Linux may read Sun data), but not on native LOW_HIGH data.

This allows an existing system to be replaced with an opposite system without converting the data files. For example, a standard c-tree Server on a Sun Sparc system (HIGH_LOW) could be replaced with a LOW_HIGH Host c-tree Server on a Linux (Intel) system by simply installing the new Linux c-tree Server software and copying the existing data to the Linux system.

This convenience comes at a price however. Due to the differences in byte ordering, transaction processing is not supported with UNIFRMAT servers. As the transaction log files are not portable, various features of transaction processing become more of a challenge, and have not been implemented at this time.

The following diagram demonstrates a UNIFRMAT environment.