Sponsored Content
Special Forums UNIX and Linux Applications Virtualization and Cloud Computing Data Warehouse evolving towards CEP? Post 302178227 by Linux Bot on Tuesday 25th of March 2008 04:10:13 AM
Old 03-25-2008
Data Warehouse evolving towards CEP?

vincent
Tue, 25 Mar 2008 03:15:31 +0000
Whilst at DAMA last week I managed to miss the Teradata talk on “active data warehouses“. Luckily James Taylor blogged comprehensively on the talk, and although it seems Teradata declined to make the presentation available to attendees, I’m guessing it was pretty much the same as this one (”Google is your friend”/”Time to Yahoooo”, etc).
Now, DAMA is targeted at Data Professionals, many of whom also have to deal with data warehouses to store longer term data for analysis and analytics. Yet here is a highly respected DW company, who sells mostly in the DW space, advocating an event-driven approach to analysing your data. Fascinating! Furthermore, they presented “event-driven” use cases (albeit old ones) such as real-time event processing for the airline industry that we have already seen adopt CEP. But then, the use of an ESB, event-store, and rule-engine as a DIY CEP engine is a perfectly valid approach to event processing (cost notwithstanding) versus an off-the-shelf CEP engine (not mentioning any names of course).
At the same time, we see a similar development in the BI space as indicated by this IntelligentEnterprise comment on BI Emerging Technologies. The key term here is “in-memory analytics” although some of the other “emerging technologies” may also seem familiar (namely: advanced visualization - cue TIBCO Spotfire - and cloud computing - although in this case they refer to hardware clouds rather than event clouds).
Image

Source...
 
TALK(1) 						    BSD General Commands Manual 						   TALK(1)

NAME
talk -- talk to another user SYNOPSIS
talk person [ttyname] DESCRIPTION
Talk is a visual communication program which copies lines from your terminal to that of another user. Options available: person If you wish to talk to someone on your own machine, then person is just the person's login name. If you wish to talk to a user on another host, then person is of the form 'user@host'. ttyname If you wish to talk to a user who is logged in more than once, the ttyname argument may be used to indicate the appropriate terminal name, where ttyname is of the form 'ttyXX' or 'pts/X'. When first called, talk contacts the talk daemon on the other user's machine, which sends the message Message from TalkDaemon@his_machine... talk: connection requested by your_name@your_machine. talk: respond with: talk your_name@your_machine to that user. At this point, he then replies by typing talk your_name@your_machine It doesn't matter from which machine the recipient replies, as long as his login name is the same. Once communication is established, the two parties may type simultaneously; their output will appear in separate windows. Typing control-L (^L) will cause the screen to be reprinted. The erase, kill line, and word erase characters (normally ^H, ^U, and ^W respectively) will behave normally. To exit, just type the interrupt character (normally ^C); talk then moves the cursor to the bottom of the screen and restores the terminal to its previous state. As of netkit-ntalk 0.15 talk supports scrollback; use esc-p and esc-n to scroll your window, and ctrl-p and ctrl-n to scroll the other win- dow. These keys are now opposite from the way they were in 0.16; while this will probably be confusing at first, the rationale is that the key combinations with escape are harder to type and should therefore be used to scroll one's own screen, since one needs to do that much less often. If you do not want to receive talk requests, you may block them using the mesg(1) command. By default, talk requests are normally not blocked. Certain commands, in particular nroff(1), pine(1), and pr(1), may block messages temporarily in order to prevent messy output. FILES
/etc/hosts to find the recipient's machine /var/run/utmp to find the recipient's tty SEE ALSO
mail(1), mesg(1), who(1), write(1), talkd(8) BUGS
The protocol used to communicate with the talk daemon is braindead. Also, the version of talk(1) released with 4.2BSD uses a different and even more braindead protocol that is completely incompatible. Some vendor Unixes (particularly those from Sun) have been found to use this old protocol. Old versions of talk may have trouble running on machines with more than one IP address, such as machines with dynamic SLIP or PPP connec- tions. This problem is fixed as of netkit-ntalk 0.11, but may affect people you are trying to communicate with. HISTORY
The talk command appeared in 4.2BSD. Linux NetKit (0.17) November 24, 1999 Linux NetKit (0.17)
All times are GMT -4. The time now is 10:26 AM.
Unix & Linux Forums Content Copyright 1993-2022. All Rights Reserved.
Privacy Policy