Maurizio – Omnologos

Where no subject is left unturned

Archive for the ‘Computing’ Category

Laptop Killer

with one comment

1kg, WiFi, good-size keyboard, screen 1024×600, webcam, 15 seconds to start. VGA output.

After that, it’s truly absurd to go for a laptop PC.

Written by omnologos

2008/Oct/13 at 22:42:07

Posted in Computing, Technology

Tagged with , , ,

Hope in the Portrait vs. Landscape Saga

leave a comment »

Ad agencies appear to have woken up to the superiority of “portrait” (“vertical”) setting of displays compared to standard “landscape” (“horizontal”): that is, how much more natural and life-like the images look on them.

I have already written about how standard computer video interfaces are anything but natural, especially with the advent of widescreen displays.

Why has that happened? Likely for two reasons. First of all, computer screens were originally built using standard TV technology. Television started as a kind of “remote theatre” (most of it, still is). Theatre stages are wide rather than deep, because all actors need to be placed in front of the public and it’s pretty hard to stack them up…the original 4:3 landscape format for TV sets was therefore not a bad choice (even more so, the contemporary 16:9 format).

Furthermore, perhaps since the times of Xerox’s Palo Alto workshop that heralded the era of computer graphics, a PC’s screen has been meant to be a “desktop”…literally, the top surface of one’s desk. Now, office desks are usually rectangular, and this is because of the way we can move our arms (reaching out is much easier on the sides than straight in front of us).

But most of us use computers for reading and writing messages, for blogs and comments, for developing programming code, and in most cases to surf the internet. I am not sure anybody pretends that their few square inches of screen are actually their desktop?

Instead, as books and newspapers are usually in portrait format, and people’s bodies and faces are usually vertically -oriented (that’s why it is called portrait), and even the windows in most buildings are taller than wider…our real-life world is full of portrait-oriented features with which we interact.

It would all look obviously much more natural if we had portrait computer screens. In some cases, even portrait-oriented TV sets.

And that’s in fact what is happening in some airports, where TV screens are being mounted vertically to display advertisements. Whatever is shown, such as panoramas or products, the impression is of looking into a window into another real world, rather than the artificial theatre of television.

So if your screen and your PC’s graphics card allow portrait-orientation, do not hesitate and try it out.

Me, I have no intention to go back to “landscape”.

Written by omnologos

2007/Aug/01 at 13:03:49

Millennium Bug A Different Virus

leave a comment »

Seven and more years later, we can definitely close down the story of the Millennium Bug as one of the greatest wastes of money in the history of Humanity.

In hindsight, it has been as useful and as value-generating as one of those chain-mail messages, just a different kind of computer virus.

Nothing of significance happened on Dec 31, 1999. Perhaps nothing at all, zilch, nada, niente (but it’s hard to demonstrate a negative).

Even the stories with the flimsiest relevance and interest should have surfaced by now.

People that were actually employed in fixing the fantasy Bug don’t usually like such a train of thought. Somebody actually tried to tell me the Bug caused no trouble because of the dedication of so many people and resources to fix it.

I do not buy any such excuse.

Surely a lot of people worked on the Bug very professionally and conscientiously.

But then we all know any kind of software does contain errors…the Millennium Bug Fixes by miracle or extraordinary coincidence, not even one. How can that be possible?

And how can it be likely that everybody everywhere on the planet lost their capacity to make mistakes in the process of fixing the Bug? Italy was a well-known laggard on considering the Bug, and in Kenya there was no funding to do anything until March 2000 (three months after the Bug should have stricken).

Written by omnologos

2007/May/11 at 21:01:21

Posted in Business, Computing

Unnatural Standard Computer Video Interfaces

with one comment

It has long been common wisdom to have rectangular monitors, be them TV or for PC’s, with landscape orientation, wider than taller.

Perhaps it is a way of mimicking the movie theatre experience, where such an orientation is in order to serve amphitheatre-like seating, and to provide context to the action.

Recently, things are gone even further down the same path, with Widescreen TV sets (and laptop PC monitors) all the rage.

That may as well be a good choice if all people want to do is watch movies. Not so for Computers of any sort.

Think about it: we are trained to read on portrait-oriented books. Even text fonts and standard printer paper are taller than wider (not to mention our bodies, faces and windows apart from exceptional cases).

Most of us use computers for reading and writing messages, for blogs and comments, for developing programming code, and in most cases to surf the internet.

It would be therefore much better to re-orient the monitors sideways, making their long side vertical.

I have been using such a configuration for more than two years and there is simply no comparison regarding having a more natural experience with portrait-oriented monitors, with far less need of eye and neck movements to keep track of the content of the screen.

Portrait-viewing is rather easy to do on a PC (or Tablet PC), but unfortunately next-to-impossible to find on a laptop computer.

But lo-and-behold: Adobe Inc.’s hugely popular Acrobat Reader does allow re-orientation indeed, making reading of electronic documents almost completely equivalent to paper ones’.

Is portrait-orientation the next step towards the utopian dream called “paperless office“? We will know when manufacturers will, one day, pick up such an obvious idea.

Written by omnologos

2007/Feb/06 at 13:23:36

A Mole of Bytes

with one comment

(aka the Dig-The-Gigabyte Campaign)

Is computing rapidly turning itself into a hi-tech version of Howard Stern’s famous “Who Wants to be a Turkish Billionaire?” ?

My son asked me yesterday to explain what is a “Gigabyte”. I tried to describe the meaning of a little bit more than a billion tiny little things hidden in a PC. But then I stopped quickly: how was I going to clarify the meaning of having forty of those “gigabytes” in my laptop’s hard drive alone? And 200 of them in my desktop computer. And a thousand of them (a terabyte) in the latest high-spec PC

And at current growth rates, hard-disk capacity is increasing 10-fold every 5 years. It is perfectly clear then that by the time he’s 19 in 2021, we will have to cope with the impossibility of comprehending what we’ve got, and silly-sounding terms like petabytes (well, it sounds like 8-bit flatulence in Italian anyway)

From there onwards it’s going to be exabytes in 2035, zettabytes in 2050 and I’ll be turning 100 literally in yoda-yoda-land (yottabytes, some million billion billion bytes that will grace our computers in the middle of the 2060)

There is however no need for all this aggravation…let’s learn from Chemistry and dear old Avogadro’s Number

So here’s my proposal:

1. Dig the Giga, Tera, Peta, Etcetc-bytes asap

2. Define a Mole of Bytes as 6.023x(10 to the power of 23) of them

3. Resize the capacities now. Say, a 100 Gigabyte disk becomes a mere 166 femtoMole. To sport even 100 Terabytes of storage area, will only mean less than 200 picoMoles of Bytes

This will surely give some renewed perspective to the whole business of visualizing trends in computing, and show that there is a long long way ahead before we can declare ourselves satisfied with our computational powers

UPDATE: there is now a blog dedicated to the “Mole of Bytes” idea. And some interesting thoughts from DARPA.

Written by omnologos

2006/May/22 at 01:19:33

Posted in Computing, Innovation

From SOA to the Service-Oriented Enterprise

leave a comment »

The concepts of Agility and Service-Oriented Architecture are being marketed specifically as a new revolution in the way IT is provided to the Business. Such a view is unnecessarily reductive at best (why only IT?) and self-defeating at worst (is SOA just a marketing fad?).
The benefits of Agility and SOA are not under discussion. But for them to fully succeed, IT can and must support its rationalization efforts by providing the ancillary but necessary tools in order to help the business undergo the associated cultural changes

Beyond Agile IT
The buzz regarding Agility and Service Orientation is about “breaking away from the past”. Old, monolithic, inflexible applications will be supplanted by new, swift, adaptable, communicative and nimble systems. There is however a distinct feeling that it may all be just hype, with interest fuelled mostly by large marketing campaigns.
In a computer-literate society, advertisement can indeed entice people to find more about the latest trend in information management services. Such an interest can then generate revenues for those that somehow manage to be at the forefront of the new technology.
One problem with this: in a computer-literate society, business managers are exposed to a profusion of industry magazines not afraid to deal with IT issues and their history, making increasingly difficult to close down an argument by saying, “So-and-so consultancy firm knows best”. The usual comparison is between the arguments used to promote Web Services and SOA and the 1990’s EDI “revolution-that-never-was”.
There are surely only so many times Clients can repeat the same mistake (spending on some new technology hoping for it to solve all sorts of problems and herald a new, efficient, cost-effective way to do business). In the case of Agile IT, the underlying challenge is to verify that the proposed architecture does really matter to the Business.
Forget technology for a short while then. Let’s concentrate on what the concepts of Agility and SOA mean to what the Business actually cares about, namely their business. Will this make the real difference and make the “it’s just hype” tribe to eat their hats?

Agile Business
Start from Project Finance: when more than a single business unit supports a project, complex approvals involve several senior business people. Those may actually feel encouraged to wait for the one area that will definitely need the new service, to pay for it on its own. The end result is a tardy, corporate sloth.
Just as in Procurement: even if everybody agrees that market data, hardware, software licenses, etc would cost much less if orders were always shared and coordinated, profligate corporations are seldom able to leverage resources they already paying for. Business areas source their requirements independently, fearing the risks and additional costs of “working together”.
Adding control layers in corporate HQ to overcome this situation would only make it worse. The promotion of SOA and Agility has to be based on encouraging the various business areas to finance service-oriented projects.
Additional budget can be rewarded to areas that build and share service-oriented systems and assets, and amortization plans refinanced, with yearly charges shared by all the areas that could benefit from them. In the true spirit of Agility, the entire organisation would push itself towards becoming an Agile, Service-Oriented Enterprise, where sharing encompasses everything, including teams re-shuffled to adapt to changing requirements. With each service and application clearly identifiable, out- and in-sourcing become simpler, at infrastructure and application management level.

IT and the Agile Enterprise
Not-agile and not-service-oriented organizations are resistant to change so IT must help instigate and drive SOA’s extension into the whole business, providing the necessary tools that will support such a change.
First of all, paraphrasing a political question: “who stays up with the sick system?” With services shared among several business areas, will anyone feel responsible for them, or will they all wait for HQ to take care?
IT can help Business Areas clarify ownership, for instance by involving the relevant business managers into all the decisions concerning the implementation of the service.
Collaboration tools can also encourage business areas to cooperate more effectively. These may include information share systems to internally publicize the services that are being built or planned for in the SOA, and that thus could be used by other areas.
The outcome data can then be used at Board level, where careful management will mean setting aside in the budget awards for the business areas more successful in providing services, providing therefore yet an additional incentive for SOA to become the norm. Additional monitoring tools for the Board can include metrics on which services are more shared, and communications channels letting the various business areas ask for financing or other kind of support when embarking in the realization of what can be a service for the entire Company

Conclusions: what IT can and should do to promote SOA
Leaving Agility confined to the IT area will make it just another fad ready to be supplanted by next marketing campaign. The alternative is for Service-Oriented Architecture concepts to be extended outside the IT departments and agility becoming simply the norm in most businesses, where the gains in terms of increased efficiencies and therefore productivity are all too evident.
Expanding SOA into Service-Oriented Enterprise will imply skills of Change Management not easy to be found, with failure beckoning and SOA getting discarded at the first possible occasion. It will be all too easy for IT personnel to behave like enlightened apostles of the new credo of Agility and Service-Oriented Architecture, condescendingly explaining them to the illiterate masses of senior business managers. Such a behaviour will not bring any fruitful results but (perhaps) in the few companies where the CIO/CTO has major decision powers.
Indeed, the cultural changes associated with Agility and Service-Orientation will have to start from IT itself. For once, there is the chance of helping the Business make and support the transition by providing the necessary tools on top of the new technology. If this opportunity will be taken not we will witness not only a major revolution in the way IT is provided, but even more importantly the entire Business-IT relationship finally getting into adulthood

Written by omnologos

2003/Oct/17 at 22:36:54

The Loosely-Coupled R.a.ï.s. – to the rescue of Web Services

leave a comment »

NASA, SETI, RAID, WiFi Solutions to the rescue of Reliability and Quality-of-Service

The Business Software market is expecting improvements in Reliability, Availability and in general Quality-of-Service (QoS) for Web Services (WS) to gain widespread acceptance. R.a.ï.s. (Redundant Array of Independent Services) achieves this by making Client Applications subscribe to several independent Services performing the same functionality. Inspired by solutions implemented at NASA, by the SETI@Home initiative and in the RAID technology, R.a.ï.s. provides advantages to WS Suppliers as well, by making the market intrinsically larger and by providing a potent selling tool in showing their WS being on par with if not better than the competition.

1. Advantages of Web Services

For an introduction see IBM's "Web Services 101" . Briefly, a WS is a Web-based application that communicates to other applications using the Web Services open standards: IP as backbone, XML to tag the data transferred using SOAP, and WSDL to describe / UDDI to list the available services . By using those standards WS can become a very powerful tool, allowing Companies to communicate their data internally and externally independently from their underlying IT systems. WS can increase the possibility for business integration while reducing the need for duplication of data between applications. Furthermore, Developers can use the best technology available for each task without worrying about custom integration coding .

2. Open questions: Reliability and Quality-of-Service

Pervasive usage of WS will depend on the ability of Clients to trust and manage performance. In particular good Reliability and Quality-of-Service (QoS ) are important , and especially so when a WS is to be provided by an external Company.
In fact, parallel can be drawn with the Application Service Provider (ASP) model, where Clients had to rely on another company’s ability to provide reliable applications and proper data management, often without basic tools for checking checking errors, high performance, resilience and availability.
Solutions proposed in the area of WS security include SAML  and XKMS , while the rest is still not clearly defined. Furthermore, unscrupulous WS Suppliers could “milk the Client” as neither service suspension nor replacement with a different supplier’s are feasible solutions. The criteria of choice of a WS or another are also still vague . As the number of available, competing WS will increase more and more systems will perform similar functions, leaving the Client with the task of picking a supplier from a tangle of possibilities.

3. Solutions from history: NASA, SETI, RAID…and WiFi

Technology has confronted issues of Reliability and “QoS” in the past.

a) NASA: The Space Shuttle’s onboard main computing system has to guarantee extremely high reliability. Alongside highly-dependable components, the designers chose a quintuple of identical computers performing the same processing and submitting the results to each other. Failure of one computer  is easily spotted, with its data being different from the others (Majority Rule). The faulty systems exclude themselves from further control of the spaceship, whose security is still guaranteed by the presence of 3 or 4 fully functioning computers .

b) SETI@Home: In one of the first examples of grid computing, each node is sent packets containing a fraction of the data collected by a radiotelescope. Results are checked by a centralised system looking for extraterrestrial signals. SETI@Home has to cope with bogus data sent back by some users. This issue was overcome by sending the same packets to several nodes: again, results that vary from the majority are discarded thus nullifying all attempts at distorting the data .

c) RAID: A well-known technology developed for increased reliability is RAID (Redundant Array of Independent (or Inexpensive) Disks). This is the solution of choice when both data access speed and fault tolerance are of particular relevance. The simplest RAID implementation is the so-called Level 0, where the same information is written in two or more drives in combination (data striping). At higher levels, errors are corrected using control codes . Once more the solution is to use multiple data copies

d) WiFi: WirelessFidelity is the term describing any technology  enabling wireless LAN connectivity under the IEEE 802.11 family of specifications. WiFi is promising a revolution just in making Internet access available everywhere at negligible costs. On top of that, WiFi is one of the first examples of Open Spectrum technology. Instead of strictly going through a single channel, transmission uses several frequencies at once . This, alongside error correction and packet re-send capabilities, eliminates the need for protection against interference.

In common above is the idea of eliminating reliance on single items in the system: computers at NASA, processing nodes on SETI@Home, disks for RAID, transmission channels on WiFi.

4. Application to WS: R/A/I/S

This concept has inspired a solution to WS Reliability and QoS with R.a.ï.s. (Redundant Array of Independent Services).
Under R.a.ï.s., Client Applications  subscribe to an array of WS  performing the same processing (redundant), provided by different suppliers  and independent from each other. Results are compared, and data discordant from the majority discarded. The result is a highly reliable WS architecture with an intrinsically high QoS.
As an example, let’s imagine application “A” subscribing to 5 WS, performing the same function but each developed, maintained and hosted by different Suppliers.
The datasets coming back from each WS are reconciled . If identical, "A" will proceed using any one of them. If any dataset differs from the others, it is discarded and its Service marked as faulty.
"A" can still proceed regardless, using any other result .

5. QoS and Reliability improvements

R.a.ï.s. improves QoS as:

a) With a large dose of competition built into the architecture, Clients no longer rely on the successes, failures and whims of a single external Company.

b) It fully utilises the nature of the Internet, as chances of simultaneous attacks on independent suppliers (including DoS) are less likely than on a single one Also the risk derived by delays in the network is contained as late or unreachable Services can simply be discarded .

c) The risk of handling incorrect data due to bugs in the WS Producer’s code is greatly reduced by choosing independent Suppliers. Software bugs in each WS are in fact much easier to spot, and the Supplier can deal with them without compromising the WS Consumer’s functionality.

6. Example Web Services

Some example obviously suited for R.a.ï.s., as several Suppliers can easily provide the same functionality:

a) Global Bank Holiday Calendar

b) Event Management System

c) Market Data

7. Types of Reconciliation

Apart from when different values are returned, datasets can be considered discordant under other circumstances, for example when a WS appears consistently late in its responses.
The above can be performed using a majority rule or extending it to include a weighted-voting system, reducing the reliance on one or more low-quality Services.
The extent of the data checking can also be varied. With large datasets, reconciliation speed can be increased by using subsets of the data, or statistical checking, or comparing control “parity” data .
This can be used to deal with additional processing power with large or complex reconciliations, for example when there are demands to handle faults of one or more Services.

8. Performing the Reconciliation

The WS Consumer itself may conduct the data reconciliation, allowing its managers to keep full control of its behaviour.
At the Client’s side, another choice is delegating a separate Reconciliation Machine to compare the data received from all the Producers to all the local Consumers, making possible:

a) The running of a Company-wide R.a.ï.s. policy

b) Easier implementation of additional processing power as needed as system upgrades make the data larger and more complex.

9. Sizing

The number of WS to use for the R.a.ï.s. framework will in general be odd, for the obvious reason of avoiding the deadlock caused by the same number of WS reporting different datasets (e.g. a 1vs.1 or a less likely  2vs.2 situation). For similar reasons, it is risky to use a 3-WS configuration, as the failure of one would increase the chance of a 1vs.1 deadlock.
On the other hand, the number of WS should be kept as low as possible, to minimise the reconciliation processing power. A sensible solution is therefore to use 5 Services .

10. Handling of and Recovery from failure of one or more WS

Apart from discarding its data, managing of the failure of one WS can involve several optional stages, for example:

a) Dropping the faulty Service and subscribing to another one automatically, for example from a directory listing. This can be either temporary or permanent according to appropriate Contracts for “Emergency Supply”

b) Re-interrogating the faulty WS in the future, up to a certain number of times

c) Reporting the fault and the relevant data automatically to the Supplier

d) Communicating the failure of one WS to other Companies that are using it, either publicly or privately, in an open or anonymous fashion.

As with the Reconciliation, this process can be performed by the Application itself, by the Reconciliation Machine or by a purpose-built system.
Careful selection of the Suppliers will likely make the simultaneous failure of several WS an extremely rare occurrence. Client Companies needing to handle it anyway can implement tools for the automatic selection of additional Services (see 10.a).

11. Suppliers: Availability, Selection and Advantages

The R.a.ï.s. framework relies on the availability of several WS performing similar functions, and Due Diligence in selecting which WS to use, including verifying their independence.
The first point is virtually guaranteed by the already large number of suppliers. Concerning selection, R.a.ï.s. itself could help. In fact, a WS used by a R.a.ï.s. Client has the selling point of being at least on par with the competition.
Listings containing the number of Customers using each Producer could then become the basis for WS League Tables, to be used during the Due Diligence phase, instead of sifting through anonymous, huge WS directories.
This is also an obvious advantage for the best Suppliers, as Services near the top of the League Table are evidently easier to sell. Moreover, QA is continuously conducted on live-data, making even internal quality controls easier to perform and verify. Finally, Clients have the incentive of supporting a large number of independent Suppliers, without which most of the advantages of R.a.ï.s. would be lost .

12. Costs: Independent or also Inexpensive?

Under a rather simplistic analysis R.a.ï.s. might appear as an increase of costs, with WS Consumers having to pay multiple Service fees. In practice there are several factors mitigating that situation:

a) R.a.ï.s. dramatically decreases the risks of not being able to run an Application and of handling incorrect data due to problems at the WS Supplier’s side and/or communication failures. The costs of those occurrences need to be factored in when opting for WS, and they may be one of the most important reasons holding off the WS market.
b) The framework guarantees a larger supply, as the market is larger . Also, the need for independent Services makes monopoly conditions less likely to form, keeping the Service fees low.

c) Suppliers can slash subscription costs under particular circumstances, for example when subsidising their presence in order to make an impact in the League Table.

d) Contracts can accommodate Client discounts for the service of providing live-data continuous QA.

e) Similarly, Client dues can be calculated on the actual amount of processing power used, excluding the occasions when the WS was considered faulty.

f) Clients can loosely federate themselves when using a specific WS to share information on its reliability and performance, decreasing the risk of failure even further .

The careful exploitation of these, combined to all the other advantages in terms of Reliability and QoS, can compensate the Client for additional costs (if any) due to R.a.ï.s.’s multiple subscriptions, thus making the I of R.a.ï.s. mean Inexpensive in addition to Independent like for the RAID acronym.

1.  "Web Services 101" by Bob Sutor, Director of Web Services Strategy, IBM
2.  From the Webopedia:
3.  Presentation by Simon Walkden, Global Head of IT Architecture, UBS Warburg available at
4.  QoS includes reliability, management, monitoring and security
5.  See "Thinking about Implementing a Web Services Strategy?" by Brian Buehling
6.  Security Assertion Markup Language, XML-based
7.  XML Key Management Specification, allowing use of PKI
8.  Both "customer milking" and vague choice criteria were also problems already present in the ASP model
9.  Or even the simultaneous failure of two returning identical faulty results
10.  The simultaneous identical failure of 3 computers can be considered too improbable an event to be granted consideration.
11.  This process is also speeding up the signal processing, as the system is not relying on the availability of idle time on a single PC.
12.  At RAID Level 3, the control data is written in a dedicated disk. At Level 5, they are themselves striped across the available disks.
13.  As long as it is certified and approved by the “WiFi Alliance” organisation
14.  A total of 14 channels on the 2.4-GHz band in the case of 802.11
15.  Also known as WS "Consumers"
16.  Also known as WS "Producers". Note that the function performed by the Producer could be any within a standard WS Architecture, including data processing, billing, orchestration, and so on.
17.  It could be different external Companies, or different Departments within the same Company
18.  See below for types and location of the reconciliation
19.  This rule can be applied even if 2 WS do not agree with the others, again by picking up as “true” any dataset from the remaining 3 services.
20.  Therefore shielding the WS Consumer also from interruptions for example for software upgrades at the Suppliers’ side.
21.  Just as for any data transfer
22.  Less likely as it would involve at least 2 Web Services failing identically, despite being independent from each other
23.  Just as the Space Shuttle uses 5 onboard computers. Note that if one WS is marked as faulty, deadlock could be prevented by temporarily discarding another one and still leaving 3 Services would be available to the WS Consumer.
24.  For example, a small number of suppliers would increase rates and decrease the quality assured by independent verification of results.
25.  Larger because each Consumer needs more than one Producer
26.  The other members could drop a Service that had become untrustworthy in the eyes of a member of the Federation, or this could lobby the Supplier as a whole for improvements, debugging, etc.

Written by omnologos

2003/May/27 at 23:34:44

Posted in Computing, Web Services