Friday, April 06, 2007
Tuesday, January 16, 2007
Readers' Choice Awards - TechWeb
Complete article here
Readers Choice Award winners list
Best BI Suite Winner: Business Objects
Runner-Up: Cognos
Best Performance Management Suite Winner: Microsoft
Runner-Up: Oracle
Best Search Software Winner: Google
Runner-Up: FAST
Best Customer Analytics Winner: Microsoft
Runner-Up: Oracle
Best Web Analytics Winner: WebTrends
Runner-Up: TeaLeaf Technology
Best Data Mining or Statistical Analysis Winner: SAS
Runner-Up: SPSS
Best Text Mining Software Winner: IBM
Runner-Up: SAS
Best Data Visualization Software Winner: IBM
Runner-Up: Visual Insights
Best Customer Data Integration Software Winner: Oracle
Runner-Up: IBM
Best Data Quality and Profiling Software Winner: SAS DataFlux
Runner-Up: Business Objects Firstlogic
Best Metadata Management Software Winner: IBM
Runner-Up: Hyperion Solutions
Best ETL Software Winner: Microsoft
Runner-Up: Informatica
Best EII Software Winner: IBM
Runner-Up: Composite Software
Best Database Management System Winner: Oracle
Runner-Up: Microsoft
Best Data Warehouse/ BI Appliance Winner: NCR Teradata
Runner-Up: IBM
Best XML Database Winner: Microsoft
Runner-Up: Oracle
Best Business Process Management Suite Winner: Microsoft
Runner-Up: IBM
Best Business Rules Engine Winner: Fair Isaac
Runner-Up: Pegasystems
Best Business Activity Monitoring Software Winner: TIBCO
Runner-Up: WebMethods
Best Portal Platform Winner: IBM
Runner-Up: BEA Systems Plumtree
Best IT/Business Services Winner: IBM Global Services
Runner-Up: Accenture
Best ERP Software Winner: Oracle
Runner-Up: SAP
Best Data and Document Capture Software Winner: Adobe
Runner-Up: IBM
Best Enterprise Service Bus Winner: IBM
Runner-Up: Oracle
Best SOA Tools Winner: Microsoft
Runner-Up: IBM
Best Collaborative Content Management Software Winner: Microsoft
Runner-Up: IBM
Best CRM Suite Winner: Oracle
Runner-Up: Microsoft
Best Web Content Management Software Winner: Microsoft
Runner-Up: Adobe (Macromedia)
Best XML Content Publishing Software Winner: Adobe Systems
Runner-Up: Tie--Altova and HyperVision
Best Application Change Management Software Winner: BMC
Runner-Up: CA
Best Corporate Governance and Compliance Solutions Winner: Hyperion Solutions
Runner-Up: IBM
Best Enterprise Architecture/Process Modeling Software Winner: CA
Runner-Up: Proforma
Best IT Service Management Software Winner: Hewlett-Packard
Runner-Up: IBM
Best B2B Integration Software Winner: IBM
Runner-Up: Microsoft
Best Supply Chain Management System Winner: Oracle
Runner-Up: SAP
Best GIS Winner: Microsoft
Runner-Up: ESRI
Best Complex Event Processing Software Winner: TIBCO
Runner-Up: Progress Software
Readers Choice Award winners list
Best BI Suite Winner: Business Objects
Runner-Up: Cognos
Best Performance Management Suite Winner: Microsoft
Runner-Up: Oracle
Best Search Software Winner: Google
Runner-Up: FAST
Best Customer Analytics Winner: Microsoft
Runner-Up: Oracle
Best Web Analytics Winner: WebTrends
Runner-Up: TeaLeaf Technology
Best Data Mining or Statistical Analysis Winner: SAS
Runner-Up: SPSS
Best Text Mining Software Winner: IBM
Runner-Up: SAS
Best Data Visualization Software Winner: IBM
Runner-Up: Visual Insights
Best Customer Data Integration Software Winner: Oracle
Runner-Up: IBM
Best Data Quality and Profiling Software Winner: SAS DataFlux
Runner-Up: Business Objects Firstlogic
Best Metadata Management Software Winner: IBM
Runner-Up: Hyperion Solutions
Best ETL Software Winner: Microsoft
Runner-Up: Informatica
Best EII Software Winner: IBM
Runner-Up: Composite Software
Best Database Management System Winner: Oracle
Runner-Up: Microsoft
Best Data Warehouse/ BI Appliance Winner: NCR Teradata
Runner-Up: IBM
Best XML Database Winner: Microsoft
Runner-Up: Oracle
Best Business Process Management Suite Winner: Microsoft
Runner-Up: IBM
Best Business Rules Engine Winner: Fair Isaac
Runner-Up: Pegasystems
Best Business Activity Monitoring Software Winner: TIBCO
Runner-Up: WebMethods
Best Portal Platform Winner: IBM
Runner-Up: BEA Systems Plumtree
Best IT/Business Services Winner: IBM Global Services
Runner-Up: Accenture
Best ERP Software Winner: Oracle
Runner-Up: SAP
Best Data and Document Capture Software Winner: Adobe
Runner-Up: IBM
Best Enterprise Service Bus Winner: IBM
Runner-Up: Oracle
Best SOA Tools Winner: Microsoft
Runner-Up: IBM
Best Collaborative Content Management Software Winner: Microsoft
Runner-Up: IBM
Best CRM Suite Winner: Oracle
Runner-Up: Microsoft
Best Web Content Management Software Winner: Microsoft
Runner-Up: Adobe (Macromedia)
Best XML Content Publishing Software Winner: Adobe Systems
Runner-Up: Tie--Altova and HyperVision
Best Application Change Management Software Winner: BMC
Runner-Up: CA
Best Corporate Governance and Compliance Solutions Winner: Hyperion Solutions
Runner-Up: IBM
Best Enterprise Architecture/Process Modeling Software Winner: CA
Runner-Up: Proforma
Best IT Service Management Software Winner: Hewlett-Packard
Runner-Up: IBM
Best B2B Integration Software Winner: IBM
Runner-Up: Microsoft
Best Supply Chain Management System Winner: Oracle
Runner-Up: SAP
Best GIS Winner: Microsoft
Runner-Up: ESRI
Best Complex Event Processing Software Winner: TIBCO
Runner-Up: Progress Software
Monday, January 15, 2007
Steve Ballmer Speaks Passionately about Microsoft, Leadership ... and Passion
For Microsoft, 2006 was a year of new product introductions: the Windows Vista operating system, a new version of Office and the Zune music player, to name a few. For Microsoft CEO Steve Ballmer -- who spoke at Wharton recently as part of the school's Leadership Lecture series -- these new products serve as a reminder of his goals: Convince customers that Microsoft's latest products are ground-breaking, transform a company with $44 billion in sales into an agile innovator, compete against new business models and recruit enough talent to keep the software giant relevant 25 years from now.
Read the full article here
Read the full article here
Wednesday, January 03, 2007
YouOS
Its been a while since something has really caught my interest, i must hand it to the folks at YouOS.com, they have done a marvelous job. Goto www.youos.com and give it a spin.
Prior to the Web 2.0 initiatives implementing an operating system using the web would have been unthinkable, but as with most of the applications based on Web 2.0 trend it would take more than great idea to get people to actually use the YouOS.
It was interesting to see how they managed to get so much done using basic HTML and javascript. On a related note the Microsoft intitiative of creating widgets(also referred to as gadgets) is also very interesting. See microsoftgadgets.com for details. Gadgets allow you to install the component to a page in your site seamlessly. Think of it as installing gadgets that porvide some level of service directly into you site - now thats super cool.
Prior to the Web 2.0 initiatives implementing an operating system using the web would have been unthinkable, but as with most of the applications based on Web 2.0 trend it would take more than great idea to get people to actually use the YouOS.
It was interesting to see how they managed to get so much done using basic HTML and javascript. On a related note the Microsoft intitiative of creating widgets(also referred to as gadgets) is also very interesting. See microsoftgadgets.com for details. Gadgets allow you to install the component to a page in your site seamlessly. Think of it as installing gadgets that porvide some level of service directly into you site - now thats super cool.
The Java Problem
This is the internal memo sent by Sun Microsystems about the problems they were facing with java - insightful- but whats really interesting is that the problems listed in the memo are in JDK 1.3 and 1.4 and it wasnt identified to be a major problem in the orginal JDK version
The Java Problem
Author: Julian S. Taylor
Reviewed by: Steve Talley, Mark Carlson, Henry Knapp, Willy (Waikwan) Hui,
Eugene Krivopaltsev, Peter Madany, Michael Boucher
Executive Summary
While the Java language provides many advantages over C and C++, its
implementation on Solaris presents barriers to the delivery of reliable
applications. These barriers prevent general acceptance of Java for
production software within Sun. A review of the problem indicates that these
issues are not inherent to Java but instead represent implementation
oversights and inconsistencies common to projects which do not communicate
effectively with partners and users.
Within Sun, the institutional mechanism for promoting this sort of
communication between partners is the System Architecture Council codified
in the Software Development Framework (SDF). We propose that the process of
releasing our Java implementation will benefit from conformance with the
SDF.
Introduction
This document details the difficulties that keep our Solaris Java
implementation from being practical for the development of common software
applications. It represents a consensus of several senior engineers within
Sun Microsystems. We believe that our Java implementation is inappropriate
for a large number of categories of software application. We do not believe
these flaws are inherent in the Java platform but that they relate to
difficulties in our Solaris implementation.
We all agree that the Java language offers many advantages over the
alternatives. We would generally prefer to deploy our applications in Java
but the implementation provided for Solaris is inadequate to the task of
producing supportable and reliable products.
Our experience in filing bugs against Java has been to see them rapidly
closed as "will not fix". 22% of accepted non-duplicate bugs against base
Java are closed in this way as opposed to 7% for C++. Key examples include:
4246106 Large virtual memory consumption of JVM
4374713 Anonymous inner classes have incompatible serialization
4380663 Multiple bottlenecks in the JVM
4407856 RMI secure transport provider doesn't timeout SSL sessions
4460368 For jdk1.4, JTable.setCellSelectionEnabled() does not work
4460382 For Jdk1.4, the table editors for JTable do not work.
4433962 JDK1.3 HotSpot JVM crashes Sun Management Center Console
4463644 Calculation of JTable's height is different for jdk1.2 and jdk1.4
4475676 [under jdk1.3.1, new JFrame launch causes jumping]
In personal conversations with Java engineers and managers, it appears that
Solaris is not a priority and the resource issues are not viewed as serious.
Attempts to discuss this have not been productive and the message we hear
routinely from Java engineering is that new features are key and
improvements to the foundation are secondary. This is mentioned only to make
it clear that other avenues for change have been explored but without
success. Here we seek to briefly present the problem and recommend a
solution.
Defining the Java Problem
These are the problems we have observed which we believe indicate the need
for an improved implementation and a modified approach.
1. The support model seems flawed
Since Java is not a self-contained binary, every Java program depends
fundamentally upon the installed Java Runtime Environment (JRE). If that JRE
is broken, correction and relief is required. This sort of relief needs to
happen in a timely manner and needs to fix only the problem without the
likelihood of introducing additional bugs. Java Software does not provide
such relief.
Java packages are released (re-released) every four or five months,
introducing bug fixes and new features and new bugs with each release. These
releases are upgrading packages which remove all trace of the prior
installed packages and cannot be down-graded in the event of an error. The
standard release taxonomy used by the Architecture Review Committees (ARCs)
was developed for use by Solaris and our other mission-critical software
products to help solve these and many other problems.
It is impractical for a project based on Java to correct bugs in the Java
implementation. Java Software corrects bugs only by releasing an entire new
version. For that reason, projects seek to deliver their own copy of Java so
they can maintain it without fear of a future upgrade. Outside vendors, such
as TogetherJ, specify a particular release of Java for their product. The
customer must locate that release and install it. If a future product seeks
to use a different version, that version has to be installed side-by-side
with the prior version or TogetherJ may no longer function.
The ARCs commonly see project submittals requesting permission to ship their
own version of Java. The ARCs have been routinely forbidding projects to do
this even though they are aware of specific cases wherein interfaces or
their underlying behaviors have changed incompatibly across minor releases.
The threat of losing the ability to directly support such a substantial part
of their product has inhibited projects from choosing Java as their
implementation language and caused widely-discussed problems for customers
of projects that have used Java. Consider that the Java language supports
rapid development, simple testing and access to a wide variety of platforms.
Why are the shelves at CompUSA (a Linux friendly store) not crammed with
W32/Linux/etc offerings written in Java? As it stands client-side Java
remains primarily a web language partly because the Netscape platform runs
Java 1.1.5 and has not changed for years. It is buggy but very stable.
This indicates that Java must strictly enforce backward compatibility across
minor releases and must adhere to Sun release taxonomy for the
identification of releases. Further, existing releases must support some
sort of remedy akin to a patch so that existing installations can be
corrected through existing methods.
2. The JRE is very large.
The JRE is significantly larger than comparable runtime environments when
considering resident set size (memory dedicated to this specific program).
It has been seen to grow to as much as 900M. This has a drastic effect on
both performance and resource usage. It also means that multiple JREs
present critical resource constraints on the servers for such thin-client
systems as SunRays. Typical resident set requirements for Java2 programs
include:
Hello World 9M
SMC Server 38M
SLVM GUI 60M
Component Manager 160M
TogetherJ 300 - 900M
The largest program in that list is TogetherJ. From the standpoint of
resource requirements, TogetherJ does much of what Rational Rose does but
Rational Rose appears to function in less than 250M. Startup time is
effected as well. For example, on an Ultra10 TogetherJ requires 5 minutes to
load and start. SMC, Sun's flagship system admin console, takes between one
and two minutes to reach the point that it can be used.
Some of this problem appears to relate to the JRE. We do not have the time
or money to conduct a serious side-by-side study of Java vs other languages
and are therefore calling upon our personal experiences with Java
development. The fact that these experiences are hard to quantify forces us
to try to support the validity of this concern through existing research.
A study performed by an outside team appears to indicate a rough parity in
performance between Java and a common implementation of another OO language
called Python (see IEEE Computing, October 2000, "An Empirical Comparison of
Seven Programming Languages" by Lutz Prechelt of the University of
Karlsruhe). Both platforms are Object Oriented, support web applications,
serialization, internet connections and native interfaces. The key
difference is that Python is a scripting language. This means there is no
compilation to byte code so the Python runtime environment has to do two
things in addition to what the Java runtime environment does. It has to
perform syntax checks and it must parse the ascii text provided by the
programmer. Both of those tasks are performed at compile time by Java and so
that capability does not have to be in the JRE.
Given this data, it appears that the JRE can actually be simpler than the
Python RE since Java does at least some of this work at compile time. The
example above of "Hello World" is a good method for getting an idea of the
minimum support code required at runtime. This support code includes garbage
collector, byte code interpreter, exception processor and the like. Hello
World written in Java2 requires 9M for this most basic support
infrastructure. By comparison, this is slightly larger than automountd on
Solaris8. The Python runtime required to execute Hello World is roughly
1.6M.
Further examples of what is possible include the compiling OO languages
Eiffel and Sather which fit their garbage collector, exception processor and
other infrastructure into roughly 400K of resident set. While the Java VM
(as demonstrated above) grows rapidly as more complex code is executed, the
Python VM grows quite slowly. Indeed, an inventory control program written
entirely in Python having a SQL database, a curses UI, and network
connectivity requires only 1.7M of resident set. This seems to indicate that
the resident set requirements of the JRE could be reduced by at least 80%.
Imagine what happens if our current implementation of Java were ubiquitous
and all 150 users on a SunRay server were running one and only one Java
program equivalent to Component Manager above. The twenty-four gigabytes of
RAM the server would have to supply exclusively to these users is well
beyond the typical configuration. RAM is cheap but performance is what we
sell, all customers on that SunRay server would see significant performance
degradation even with the maximum amount of RAM installed as all other
processes were forced to reside on swap.
The resident set size required by the JRE makes it impractical to run Java
in an initial Solaris install environment. It is impractical to run it as a
non-terminating daemon. A Java daemon could be started from inetd run long
enough to do its job and then quit but the rpc protocol required to pass the
socket port to the daemon is very complex and not Java-friendly. Java
applications cannot be executed at boot time since the loading of the VM
introduces an unacceptable performance degradation. If the Java runtime were
as small as that of Python, it is likely that the Java daemon would become
popular and could provide basic services to applications written in any
number of languages.
3. Extensions do not support modularity.
As new extensions are introduced, they are released separately under their
own names and distributed generally. Each one may go through several
revisions as separate modules. At some point, they are then folded into base
Java, tying base Java's version to the versions of dozens of smaller yet
distinct functionalities. These functionalities are then restricted to a
draconian backward-compatibility rule since once folded in, they are no
longer selectable modules. Examples include modules that used to be called
Swing, RTI, IDL, JSSE and JAAS. These are all good things that should be
part of Java. Our concern is that these are not separable modules which can
evolve as requirements change.
The Java system for evolving the interface (deprecation) does not serve
production software very well. Once the interface disappears, the product
just breaks. If the Java base were simpler and the more advanced features
(those most likely to be deprecated) were delivered as versioned modules, it
would be possible for a commercial product to retain it's older modules on
the system and survive a large number of Java upgrades.
Production quality programs written in Java, like TogetherJ, indicate a
specific Java version which must be installed before the program is run. If
another program is installed, requiring a higher Java version, the user may
be forced to decide which program stays and which goes away. Alternatively,
the other Java version could be installed to a different base directory but
this requires considerable sophistication on the part of the user,
complicates administration and violates the ARC big rule that common
software must be shared.
4. It is not backward-compatible across minor releases.
Among the various incompatibilities across minor releases are:
a) In JDK 1.1 Class.fields() returns only public variables. In 1.2,
protected and private variables are returned.
b) Swing table sizing calculation changed from Java 1.3 to 1.4.
c) Swing JFrame launch behavior changed significantly from Java 1.2.2 to
Java 1.3.1.
Each of these examples is simple, but they demonstrate the general problem
that people cannot program for a particular release of Java and expect that
their programs will continue to run. This is a serious problem now, but has
the potential to become a show-stopper as technology such as auto-update
advances.
What is perhaps more important is that the perception of Java as an unstable
platform is widespread. This perception is restated with every Java-based
project to come to ARC. Within Sun, Java is not viewed as a satisfactory
language for the construction of commercial applications. This perception
and the record require addressing.
The Java Problem is Recognized Internally
That our Java implementation is perceived as inappropriate for many uses is
supported by internal documents and policies. For example:
1. SOESC AI - 092501.2 Java Dependencies for Deployment
In this document provided to SOESC, John Perry describes the concerns
regarding the Solaris "JVM dependencies for deployment". Following is an
excerpt:
-------
- Large footprint of applications when run on Solaris. A simple application
("hello world" type) has a total footprint of 35-40 megs on Solaris 9 (build
48, using Java 1.4 build 82) on both Intel and Sparc machines. Sparc
machines, by far, have a much higher resident footprint then Intel machines
(~30 megs, compared to ~11 megs). The same program run on a Windows machine
has a footprint of ~5 megs, resident footprint being ~3.5 megs
- Slow start up times prevents Java applications from being started while
Solaris is booting up and during mini-root time. This requires applications
which are written in Java to have some kind of mechanism to start-up after
the OS has been fully started.
- Instability of Native code (JNI) which can cause the entire VM to crash.
-------
2. Teams Are Looking for Options
The CIMOM (supporting WBEM) is a Java daemon. It initially occupies around
40M of RSS but grows from there. In order to address this problem, at least
one Sun Engineer, Peter Madany, has been doing research to determine Java
daemon memory utilization when running on a currently unsupported J2ME VM on
Solaris. In other words, we are looking into demonstrating that resource
exhaustion on Solaris Servers could be avoided by using some of the
techniques used in an edition of Java intended for very small systems.
3. New Projects Explain Why They Are Not Using Java
Quoting from the recently submitted Nile case (SARC/2001/617) now under
review:
-------
These libraries should be commercial implementations and must be in native
platform code (ie not Java or Perl). Native code is a requirement because
one of the core requirements for the proxy is for minimum impact on the
target host. Java has too large a footprint (both memory and disk image) and
may not be installed on the customer's host.
-------
4. ARCs Include the Java Problem in Rejection Reasoning
Quoting from the recently rejected SunMC PMA case (LSARC/2000/457):
-------
The CLI interpreter is implemented in Java, and the overhead of starting a
JVM for each command execution is prohibitive. At least one of the votes to
reject was related to this inappropriate use of Java. The Solaris
implementation of Java is slow and very large. While this project did not
provide a measurement of resident set for their CLI, the minimum RSS for the
JVM is known to be 9MB and the typical RSS for a similar Java program is 30
to 40MB, and takes up to 15 seconds to start. The project team admitted in
the review that this CLI may be used on a daily basis. For such a CLI, the
delays and resource requirements of the Solaris Java implementation are
unacceptable.
-------
5. Customers and Field Engineers Are Noticing the Problem
Following is an excerpt from Kevin Tay's e-mail to three Java aliases
regarding a customer installation of a third-party product written in Java
called Vitria. We see typical very large RSS numbers compared to a WinNT
implementation combined with increased resource usage from Solaris7 to
Solaris8:
-------
Customer said they have something like 450+ container servers and 80+
automator server for the Vitria system. So the estimation for the hardware
RAM is around 9GB for USII machine and 14-15GB for the USIII machine.
Questions:
1. Why is Sun systems using so much more memory?
2. Why is the UltraSPARC III/Solaris 8 system using a lot more memory than a
UltraSPARC II/Solaris 7 system (with every other thing being equal)?
3. How can I reduce the memory utilization of the UltraSPARC III system?
-------
NOTE: The response to this e-mail was to suggest moving to a different build
of Java 1.2.2 since the indicated build on Solaris 8 had a known bug; it
should be noted, however, that the 9GB memory footprint for Solaris7 is
still unusually large.
6. Close Call in Solaris9
Bug ID 4526853 describes a bug in Core Java which used to be an external
module called JSSE. Among other products, PatchPro and PatchManager depend
on the JSSE. As long as the module could be used, the JSSE interface could
be trusted to remain stable despite extensive changes in core Java. Now the
Java architecture makes it impossible to use the module. This bug in core
Java completely disables PatchPro and PatchManager. It was introduced in
build 83 of Java 1.4. It was detected and corrected before the final build
of Solaris9. If it had not been detected before the final build, it would
have shipped with Solaris9 FCS.
For those products that depend upon JSSE and operate on multiple OSs, there
would have been no recourse except to deliver with their product an entire
new Java distribution. This distribution would have to upgrade the existing
Java installation. The fact that various products depend upon specific
versions would mean that such an upgrade would carry the risk of breaking
other Java-based software on the target system.
Correcting the Java Problem
We strongly recommend that management require Java to conform to the
Software Development Framework especially from the standpoint of ARCreview.
We believe that the next release of the Sun Java implementation should be
brought to ARC while still in the prototype phase. Both PSARC and LSARC have
dealt with the Java issues peripherally, recognizing numerous problems but
unable to effect change in the underlying source of the difficulties -
namely Java. By bringing the Sun Java implementation through ARC, these
issues can be resolved.
The Java Problem
Author: Julian S. Taylor
Reviewed by: Steve Talley, Mark Carlson, Henry Knapp, Willy (Waikwan) Hui,
Eugene Krivopaltsev, Peter Madany, Michael Boucher
Executive Summary
While the Java language provides many advantages over C and C++, its
implementation on Solaris presents barriers to the delivery of reliable
applications. These barriers prevent general acceptance of Java for
production software within Sun. A review of the problem indicates that these
issues are not inherent to Java but instead represent implementation
oversights and inconsistencies common to projects which do not communicate
effectively with partners and users.
Within Sun, the institutional mechanism for promoting this sort of
communication between partners is the System Architecture Council codified
in the Software Development Framework (SDF). We propose that the process of
releasing our Java implementation will benefit from conformance with the
SDF.
Introduction
This document details the difficulties that keep our Solaris Java
implementation from being practical for the development of common software
applications. It represents a consensus of several senior engineers within
Sun Microsystems. We believe that our Java implementation is inappropriate
for a large number of categories of software application. We do not believe
these flaws are inherent in the Java platform but that they relate to
difficulties in our Solaris implementation.
We all agree that the Java language offers many advantages over the
alternatives. We would generally prefer to deploy our applications in Java
but the implementation provided for Solaris is inadequate to the task of
producing supportable and reliable products.
Our experience in filing bugs against Java has been to see them rapidly
closed as "will not fix". 22% of accepted non-duplicate bugs against base
Java are closed in this way as opposed to 7% for C++. Key examples include:
4246106 Large virtual memory consumption of JVM
4374713 Anonymous inner classes have incompatible serialization
4380663 Multiple bottlenecks in the JVM
4407856 RMI secure transport provider doesn't timeout SSL sessions
4460368 For jdk1.4, JTable.setCellSelectionEnabled() does not work
4460382 For Jdk1.4, the table editors for JTable do not work.
4433962 JDK1.3 HotSpot JVM crashes Sun Management Center Console
4463644 Calculation of JTable's height is different for jdk1.2 and jdk1.4
4475676 [under jdk1.3.1, new JFrame launch causes jumping]
In personal conversations with Java engineers and managers, it appears that
Solaris is not a priority and the resource issues are not viewed as serious.
Attempts to discuss this have not been productive and the message we hear
routinely from Java engineering is that new features are key and
improvements to the foundation are secondary. This is mentioned only to make
it clear that other avenues for change have been explored but without
success. Here we seek to briefly present the problem and recommend a
solution.
Defining the Java Problem
These are the problems we have observed which we believe indicate the need
for an improved implementation and a modified approach.
1. The support model seems flawed
Since Java is not a self-contained binary, every Java program depends
fundamentally upon the installed Java Runtime Environment (JRE). If that JRE
is broken, correction and relief is required. This sort of relief needs to
happen in a timely manner and needs to fix only the problem without the
likelihood of introducing additional bugs. Java Software does not provide
such relief.
Java packages are released (re-released) every four or five months,
introducing bug fixes and new features and new bugs with each release. These
releases are upgrading packages which remove all trace of the prior
installed packages and cannot be down-graded in the event of an error. The
standard release taxonomy used by the Architecture Review Committees (ARCs)
was developed for use by Solaris and our other mission-critical software
products to help solve these and many other problems.
It is impractical for a project based on Java to correct bugs in the Java
implementation. Java Software corrects bugs only by releasing an entire new
version. For that reason, projects seek to deliver their own copy of Java so
they can maintain it without fear of a future upgrade. Outside vendors, such
as TogetherJ, specify a particular release of Java for their product. The
customer must locate that release and install it. If a future product seeks
to use a different version, that version has to be installed side-by-side
with the prior version or TogetherJ may no longer function.
The ARCs commonly see project submittals requesting permission to ship their
own version of Java. The ARCs have been routinely forbidding projects to do
this even though they are aware of specific cases wherein interfaces or
their underlying behaviors have changed incompatibly across minor releases.
The threat of losing the ability to directly support such a substantial part
of their product has inhibited projects from choosing Java as their
implementation language and caused widely-discussed problems for customers
of projects that have used Java. Consider that the Java language supports
rapid development, simple testing and access to a wide variety of platforms.
Why are the shelves at CompUSA (a Linux friendly store) not crammed with
W32/Linux/etc offerings written in Java? As it stands client-side Java
remains primarily a web language partly because the Netscape platform runs
Java 1.1.5 and has not changed for years. It is buggy but very stable.
This indicates that Java must strictly enforce backward compatibility across
minor releases and must adhere to Sun release taxonomy for the
identification of releases. Further, existing releases must support some
sort of remedy akin to a patch so that existing installations can be
corrected through existing methods.
2. The JRE is very large.
The JRE is significantly larger than comparable runtime environments when
considering resident set size (memory dedicated to this specific program).
It has been seen to grow to as much as 900M. This has a drastic effect on
both performance and resource usage. It also means that multiple JREs
present critical resource constraints on the servers for such thin-client
systems as SunRays. Typical resident set requirements for Java2 programs
include:
Hello World 9M
SMC Server 38M
SLVM GUI 60M
Component Manager 160M
TogetherJ 300 - 900M
The largest program in that list is TogetherJ. From the standpoint of
resource requirements, TogetherJ does much of what Rational Rose does but
Rational Rose appears to function in less than 250M. Startup time is
effected as well. For example, on an Ultra10 TogetherJ requires 5 minutes to
load and start. SMC, Sun's flagship system admin console, takes between one
and two minutes to reach the point that it can be used.
Some of this problem appears to relate to the JRE. We do not have the time
or money to conduct a serious side-by-side study of Java vs other languages
and are therefore calling upon our personal experiences with Java
development. The fact that these experiences are hard to quantify forces us
to try to support the validity of this concern through existing research.
A study performed by an outside team appears to indicate a rough parity in
performance between Java and a common implementation of another OO language
called Python (see IEEE Computing, October 2000, "An Empirical Comparison of
Seven Programming Languages" by Lutz Prechelt of the University of
Karlsruhe). Both platforms are Object Oriented, support web applications,
serialization, internet connections and native interfaces. The key
difference is that Python is a scripting language. This means there is no
compilation to byte code so the Python runtime environment has to do two
things in addition to what the Java runtime environment does. It has to
perform syntax checks and it must parse the ascii text provided by the
programmer. Both of those tasks are performed at compile time by Java and so
that capability does not have to be in the JRE.
Given this data, it appears that the JRE can actually be simpler than the
Python RE since Java does at least some of this work at compile time. The
example above of "Hello World" is a good method for getting an idea of the
minimum support code required at runtime. This support code includes garbage
collector, byte code interpreter, exception processor and the like. Hello
World written in Java2 requires 9M for this most basic support
infrastructure. By comparison, this is slightly larger than automountd on
Solaris8. The Python runtime required to execute Hello World is roughly
1.6M.
Further examples of what is possible include the compiling OO languages
Eiffel and Sather which fit their garbage collector, exception processor and
other infrastructure into roughly 400K of resident set. While the Java VM
(as demonstrated above) grows rapidly as more complex code is executed, the
Python VM grows quite slowly. Indeed, an inventory control program written
entirely in Python having a SQL database, a curses UI, and network
connectivity requires only 1.7M of resident set. This seems to indicate that
the resident set requirements of the JRE could be reduced by at least 80%.
Imagine what happens if our current implementation of Java were ubiquitous
and all 150 users on a SunRay server were running one and only one Java
program equivalent to Component Manager above. The twenty-four gigabytes of
RAM the server would have to supply exclusively to these users is well
beyond the typical configuration. RAM is cheap but performance is what we
sell, all customers on that SunRay server would see significant performance
degradation even with the maximum amount of RAM installed as all other
processes were forced to reside on swap.
The resident set size required by the JRE makes it impractical to run Java
in an initial Solaris install environment. It is impractical to run it as a
non-terminating daemon. A Java daemon could be started from inetd run long
enough to do its job and then quit but the rpc protocol required to pass the
socket port to the daemon is very complex and not Java-friendly. Java
applications cannot be executed at boot time since the loading of the VM
introduces an unacceptable performance degradation. If the Java runtime were
as small as that of Python, it is likely that the Java daemon would become
popular and could provide basic services to applications written in any
number of languages.
3. Extensions do not support modularity.
As new extensions are introduced, they are released separately under their
own names and distributed generally. Each one may go through several
revisions as separate modules. At some point, they are then folded into base
Java, tying base Java's version to the versions of dozens of smaller yet
distinct functionalities. These functionalities are then restricted to a
draconian backward-compatibility rule since once folded in, they are no
longer selectable modules. Examples include modules that used to be called
Swing, RTI, IDL, JSSE and JAAS. These are all good things that should be
part of Java. Our concern is that these are not separable modules which can
evolve as requirements change.
The Java system for evolving the interface (deprecation) does not serve
production software very well. Once the interface disappears, the product
just breaks. If the Java base were simpler and the more advanced features
(those most likely to be deprecated) were delivered as versioned modules, it
would be possible for a commercial product to retain it's older modules on
the system and survive a large number of Java upgrades.
Production quality programs written in Java, like TogetherJ, indicate a
specific Java version which must be installed before the program is run. If
another program is installed, requiring a higher Java version, the user may
be forced to decide which program stays and which goes away. Alternatively,
the other Java version could be installed to a different base directory but
this requires considerable sophistication on the part of the user,
complicates administration and violates the ARC big rule that common
software must be shared.
4. It is not backward-compatible across minor releases.
Among the various incompatibilities across minor releases are:
a) In JDK 1.1 Class.fields() returns only public variables. In 1.2,
protected and private variables are returned.
b) Swing table sizing calculation changed from Java 1.3 to 1.4.
c) Swing JFrame launch behavior changed significantly from Java 1.2.2 to
Java 1.3.1.
Each of these examples is simple, but they demonstrate the general problem
that people cannot program for a particular release of Java and expect that
their programs will continue to run. This is a serious problem now, but has
the potential to become a show-stopper as technology such as auto-update
advances.
What is perhaps more important is that the perception of Java as an unstable
platform is widespread. This perception is restated with every Java-based
project to come to ARC. Within Sun, Java is not viewed as a satisfactory
language for the construction of commercial applications. This perception
and the record require addressing.
The Java Problem is Recognized Internally
That our Java implementation is perceived as inappropriate for many uses is
supported by internal documents and policies. For example:
1. SOESC AI - 092501.2 Java Dependencies for Deployment
In this document provided to SOESC, John Perry describes the concerns
regarding the Solaris "JVM dependencies for deployment". Following is an
excerpt:
-------
- Large footprint of applications when run on Solaris. A simple application
("hello world" type) has a total footprint of 35-40 megs on Solaris 9 (build
48, using Java 1.4 build 82) on both Intel and Sparc machines. Sparc
machines, by far, have a much higher resident footprint then Intel machines
(~30 megs, compared to ~11 megs). The same program run on a Windows machine
has a footprint of ~5 megs, resident footprint being ~3.5 megs
- Slow start up times prevents Java applications from being started while
Solaris is booting up and during mini-root time. This requires applications
which are written in Java to have some kind of mechanism to start-up after
the OS has been fully started.
- Instability of Native code (JNI) which can cause the entire VM to crash.
-------
2. Teams Are Looking for Options
The CIMOM (supporting WBEM) is a Java daemon. It initially occupies around
40M of RSS but grows from there. In order to address this problem, at least
one Sun Engineer, Peter Madany, has been doing research to determine Java
daemon memory utilization when running on a currently unsupported J2ME VM on
Solaris. In other words, we are looking into demonstrating that resource
exhaustion on Solaris Servers could be avoided by using some of the
techniques used in an edition of Java intended for very small systems.
3. New Projects Explain Why They Are Not Using Java
Quoting from the recently submitted Nile case (SARC/2001/617) now under
review:
-------
These libraries should be commercial implementations and must be in native
platform code (ie not Java or Perl). Native code is a requirement because
one of the core requirements for the proxy is for minimum impact on the
target host. Java has too large a footprint (both memory and disk image) and
may not be installed on the customer's host.
-------
4. ARCs Include the Java Problem in Rejection Reasoning
Quoting from the recently rejected SunMC PMA case (LSARC/2000/457):
-------
The CLI interpreter is implemented in Java, and the overhead of starting a
JVM for each command execution is prohibitive. At least one of the votes to
reject was related to this inappropriate use of Java. The Solaris
implementation of Java is slow and very large. While this project did not
provide a measurement of resident set for their CLI, the minimum RSS for the
JVM is known to be 9MB and the typical RSS for a similar Java program is 30
to 40MB, and takes up to 15 seconds to start. The project team admitted in
the review that this CLI may be used on a daily basis. For such a CLI, the
delays and resource requirements of the Solaris Java implementation are
unacceptable.
-------
5. Customers and Field Engineers Are Noticing the Problem
Following is an excerpt from Kevin Tay's e-mail to three Java aliases
regarding a customer installation of a third-party product written in Java
called Vitria. We see typical very large RSS numbers compared to a WinNT
implementation combined with increased resource usage from Solaris7 to
Solaris8:
-------
Customer said they have something like 450+ container servers and 80+
automator server for the Vitria system. So the estimation for the hardware
RAM is around 9GB for USII machine and 14-15GB for the USIII machine.
Questions:
1. Why is Sun systems using so much more memory?
2. Why is the UltraSPARC III/Solaris 8 system using a lot more memory than a
UltraSPARC II/Solaris 7 system (with every other thing being equal)?
3. How can I reduce the memory utilization of the UltraSPARC III system?
-------
NOTE: The response to this e-mail was to suggest moving to a different build
of Java 1.2.2 since the indicated build on Solaris 8 had a known bug; it
should be noted, however, that the 9GB memory footprint for Solaris7 is
still unusually large.
6. Close Call in Solaris9
Bug ID 4526853 describes a bug in Core Java which used to be an external
module called JSSE. Among other products, PatchPro and PatchManager depend
on the JSSE. As long as the module could be used, the JSSE interface could
be trusted to remain stable despite extensive changes in core Java. Now the
Java architecture makes it impossible to use the module. This bug in core
Java completely disables PatchPro and PatchManager. It was introduced in
build 83 of Java 1.4. It was detected and corrected before the final build
of Solaris9. If it had not been detected before the final build, it would
have shipped with Solaris9 FCS.
For those products that depend upon JSSE and operate on multiple OSs, there
would have been no recourse except to deliver with their product an entire
new Java distribution. This distribution would have to upgrade the existing
Java installation. The fact that various products depend upon specific
versions would mean that such an upgrade would carry the risk of breaking
other Java-based software on the target system.
Correcting the Java Problem
We strongly recommend that management require Java to conform to the
Software Development Framework especially from the standpoint of ARCreview.
We believe that the next release of the Sun Java implementation should be
brought to ARC while still in the prototype phase. Both PSARC and LSARC have
dealt with the Java issues peripherally, recognizing numerous problems but
unable to effect change in the underlying source of the difficulties -
namely Java. By bringing the Sun Java implementation through ARC, these
issues can be resolved.
Tuesday, January 02, 2007
Quotes
"The imagination of nature is far, far greater than the imagination of man."
- Richard Feynman
"The less confident you are, the more serious you have to act."
- Tara Ploughman
"We're even wrong about which mistakes we're making."
- Carl Winfeld
"Programs must be written for people to read, and only incidentally for machines to execute."
- Abelson & Sussman, SICP, preface to the first edition
"Your twenties are always an apprenticeship, but you don't always know what for."
- Jan Houtema
"That language is an instrument of human reason, and not merely a medium for the expression of thought, is a truth generally admitted."
- George Boole, quoted in Iverson's Turing Award Lecture
"Don't worry about what anybody else is going to do. The best way to predict the future is to invent it."
- Alan Kay
"But the audience is right. They're always, always right. You hear directors complain that the advertising was lousy, the distribution is no good, the date was wrong to open the film. I don't believe that. The audience is never wrong. Never."
- William Friedkin, in a NYT interview
"The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding."
- Brandeis
"The best writing is rewriting."
- E. B. White
"Premature optimization is the root of all evil (or at least most of it) in programming."
- Donald Knuth
The best lack all conviction, while the worst
Are full of passionate intensity.
- Yeats, The Second Coming
"We act as though comfort and luxury were the chief requirements of life, when all that we need to make us happy is something to be enthusiastic about."
- Einstein
"The path from good to evil goes through bogus."
- Tara Ploughman
"Many who burnt heretics in the ordinary way of their business were otherwise excellent people."
- G. M. Trevelyan, "Bias in History"
"The key to performance is elegance, not battalions of special cases."
- Jon Bentley and Doug McIlroy
"Politics is not the art of the possible. It consists in choosing between the disastrous and the unpalatable."
- J. K. Galbraith, Letter to Kennedy, 1962
"Keep away from people who try to belittle your ambitions. Small people always do that, but the really great make you feel that you, too, can become great."
- Mark Twain
"Any word you have to hunt for in a thesaurus is the wrong word."
- Stephen King
"However little television you watch, watch less."
- David McCullough
"As all these results were obtained, not by any heroic method, but by patient and detailed reasoning, I began to think it probable that philosophy had erred in adopting heroic remedies for intellectual difficulties, and that solutions were to be found merely by greater care and accuracy. This view I have come to hold more and more strongly as time went on, and it has led me to doubt whether philosophy, as a study distinct from science and possessed of a method of its own, is anything more than an unfortunate legacy from theology."
- Bertrand Russell, "Logical Atomism"
- Richard Feynman
"The less confident you are, the more serious you have to act."
- Tara Ploughman
"We're even wrong about which mistakes we're making."
- Carl Winfeld
"Programs must be written for people to read, and only incidentally for machines to execute."
- Abelson & Sussman, SICP, preface to the first edition
"Your twenties are always an apprenticeship, but you don't always know what for."
- Jan Houtema
"That language is an instrument of human reason, and not merely a medium for the expression of thought, is a truth generally admitted."
- George Boole, quoted in Iverson's Turing Award Lecture
"Don't worry about what anybody else is going to do. The best way to predict the future is to invent it."
- Alan Kay
"But the audience is right. They're always, always right. You hear directors complain that the advertising was lousy, the distribution is no good, the date was wrong to open the film. I don't believe that. The audience is never wrong. Never."
- William Friedkin, in a NYT interview
"The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning but without understanding."
- Brandeis
"The best writing is rewriting."
- E. B. White
"Premature optimization is the root of all evil (or at least most of it) in programming."
- Donald Knuth
The best lack all conviction, while the worst
Are full of passionate intensity.
- Yeats, The Second Coming
"We act as though comfort and luxury were the chief requirements of life, when all that we need to make us happy is something to be enthusiastic about."
- Einstein
"The path from good to evil goes through bogus."
- Tara Ploughman
"Many who burnt heretics in the ordinary way of their business were otherwise excellent people."
- G. M. Trevelyan, "Bias in History"
"The key to performance is elegance, not battalions of special cases."
- Jon Bentley and Doug McIlroy
"Politics is not the art of the possible. It consists in choosing between the disastrous and the unpalatable."
- J. K. Galbraith, Letter to Kennedy, 1962
"Keep away from people who try to belittle your ambitions. Small people always do that, but the really great make you feel that you, too, can become great."
- Mark Twain
"Any word you have to hunt for in a thesaurus is the wrong word."
- Stephen King
"However little television you watch, watch less."
- David McCullough
"As all these results were obtained, not by any heroic method, but by patient and detailed reasoning, I began to think it probable that philosophy had erred in adopting heroic remedies for intellectual difficulties, and that solutions were to be found merely by greater care and accuracy. This view I have come to hold more and more strongly as time went on, and it has led me to doubt whether philosophy, as a study distinct from science and possessed of a method of its own, is anything more than an unfortunate legacy from theology."
- Bertrand Russell, "Logical Atomism"
Time's Person of the Year: You
Time's Person of the Year: You
In 2006, the World Wide Web became a tool for bringing together the small contributions of millions of people and making them matter (orginal article by By LEV GROSSMAN here
In 2006, the World Wide Web became a tool for bringing together the small contributions of millions of people and making them matter (orginal article by By LEV GROSSMAN here
Thursday, December 28, 2006
Entrepreneurial Proverbs
Good article at http://radar.oreilly.com/archives/2006/03/entrepreneurial_proverbs.html
Friday, December 22, 2006
Steve Jobs @ Stanford
Stanford Report, June 14, 2005 'You've got to find what you love,' Jobs says
This is the text of the Commencement address at stanford college by Steve Jobs, CEO of Apple Computer and of Pixar Animation Studios, delivered on June 12, 2005.
I am honored to be with you today at your commencement from one of the finest universities in the world. I never graduated from college. Truth be told, this is the closest I've ever gotten to a college graduation. Today I want to tell you three stories from my life. That's it. No big deal. Just three stories.
The first story is about connecting the dots.
I dropped out of Reed College after the first 6 months, but then stayed around as a drop-in for another 18 months or so before I really quit. So why did I drop out?
It started before I was born. My biological mother was a young, unwed college graduate student, and she decided to put me up for adoption. She felt very strongly that I should be adopted by college graduates, so everything was all set for me to be adopted at birth by a lawyer and his wife. Except that when I popped out they decided at the last minute that they really wanted a girl. So my parents, who were on a waiting list, got a call in the middle of the night asking: "We have an unexpected baby boy; do you want him?" They said: "Of course." My biological mother later found out that my mother had never graduated from college and that my father had never graduated from high school. She refused to sign the final adoption papers. She only relented a few months later when my parents promised that I would someday go to college.
And 17 years later I did go to college. But I naively chose a college that was almost as expensive as Stanford, and all of my working-class parents' savings were being spent on my college tuition. After six months, I couldn't see the value in it. I had no idea what I wanted to do with my life and no idea how college was going to help me figure it out. And here I was spending all of the money my parents had saved their entire life. So I decided to drop out and trust that it would all work out OK. It was pretty scary at the time, but looking back it was one of the best decisions I ever made. The minute I dropped out I could stop taking the required classes that didn't interest me, and begin dropping in on the ones that looked interesting.
It wasn't all romantic. I didn't have a dorm room, so I slept on the floor in friends' rooms, I returned coke bottles for the 5¢ deposits to buy food with, and I would walk the 7 miles across town every Sunday night to get one good meal a week at the Hare Krishna temple. I loved it. And much of what I stumbled into by following my curiosity and intuition turned out to be priceless later on. Let me give you one example:
Reed College at that time offered perhaps the best calligraphy instruction in the country. Throughout the campus every poster, every label on every drawer, was beautifully hand calligraphed. Because I had dropped out and didn't have to take the normal classes, I decided to take a calligraphy class to learn how to do this. I learned about serif and san serif typefaces, about varying the amount of space between different letter combinations, about what makes great typography great. It was beautiful, historical, artistically subtle in a way that science can't capture, and I found it fascinating.
None of this had even a hope of any practical application in my life. But ten years later, when we were designing the first Macintosh computer, it all came back to me. And we designed it all into the Mac. It was the first computer with beautiful typography. If I had never dropped in on that single course in college, the Mac would have never had multiple typefaces or proportionally spaced fonts. And since Windows just copied the Mac, its likely that no personal computer would have them. If I had never dropped out, I would have never dropped in on this calligraphy class, and personal computers might not have the wonderful typography that they do. Of course it was impossible to connect the dots looking forward when I was in college. But it was very, very clear looking backwards ten years later.
Again, you can't connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something - your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life.
My second story is about love and loss.
I was lucky – I found what I loved to do early in life. Woz and I started Apple in my parents garage when I was 20. We worked hard, and in 10 years Apple had grown from just the two of us in a garage into a $2 billion company with over 4000 employees. We had just released our finest creation - the Macintosh - a year earlier, and I had just turned 30. And then I got fired. How can you get fired from a company you started? Well, as Apple grew we hired someone who I thought was very talented to run the company with me, and for the first year or so things went well. But then our visions of the future began to diverge and eventually we had a falling out. When we did, our Board of Directors sided with him. So at 30 I was out. And very publicly out. What had been the focus of my entire adult life was gone, and it was devastating.
I really didn't know what to do for a few months. I felt that I had let the previous generation of entrepreneurs down - that I had dropped the baton as it was being passed to me. I met with David Packard and Bob Noyce and tried to apologize for screwing up so badly. I was a very public failure, and I even thought about running away from the valley. But something slowly began to dawn on me – I still loved what I did. The turn of events at Apple had not changed that one bit. I had been rejected, but I was still in love. And so I decided to start over.
I didn't see it then, but it turned out that getting fired from Apple was the best thing that could have ever happened to me. The heaviness of being successful was replaced by the lightness of being a beginner again, less sure about everything. It freed me to enter one of the most creative periods of my life.
During the next five years, I started a company named NeXT, another company named Pixar, and fell in love with an amazing woman who would become my wife. Pixar went on to create the worlds first computer animated feature film, Toy Story, and is now the most successful animation studio in the world. In a remarkable turn of events, Apple bought NeXT, I retuned to Apple, and the technology we developed at NeXT is at the heart of Apple's current renaissance. And Laurene and I have a wonderful family together.
I'm pretty sure none of this would have happened if I hadn't been fired from Apple. It was awful tasting medicine, but I guess the patient needed it. Sometimes life hits you in the head with a brick. Don't lose faith. I'm convinced that the only thing that kept me going was that I loved what I did. You've got to find what you love. And that is as true for your work as it is for your lovers. Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven't found it yet, keep looking. Don't settle. As with all matters of the heart, you'll know when you find it. And, like any great relationship, it just gets better and better as the years roll on. So keep looking until you find it. Don't settle.
My third story is about death.
When I was 17, I read a quote that went something like: "If you live each day as if it was your last, someday you'll most certainly be right." It made an impression on me, and since then, for the past 33 years, I have looked in the mirror every morning and asked myself: "If today were the last day of my life, would I want to do what I am about to do today?" And whenever the answer has been "No" for too many days in a row, I know I need to change something.
Remembering that I'll be dead soon is the most important tool I've ever encountered to help me make the big choices in life. Because almost everything – all external expectations, all pride, all fear of embarrassment or failure - these things just fall away in the face of death, leaving only what is truly important. Remembering that you are going to die is the best way I know to avoid the trap of thinking you have something to lose. You are already naked. There is no reason not to follow your heart.
About a year ago I was diagnosed with cancer. I had a scan at 7:30 in the morning, and it clearly showed a tumor on my pancreas. I didn't even know what a pancreas was. The doctors told me this was almost certainly a type of cancer that is incurable, and that I should expect to live no longer than three to six months. My doctor advised me to go home and get my affairs in order, which is doctor's code for prepare to die. It means to try to tell your kids everything you thought you'd have the next 10 years to tell them in just a few months. It means to make sure everything is buttoned up so that it will be as easy as possible for your family. It means to say your goodbyes.
I lived with that diagnosis all day. Later that evening I had a biopsy, where they stuck an endoscope down my throat, through my stomach and into my intestines, put a needle into my pancreas and got a few cells from the tumor. I was sedated, but my wife, who was there, told me that when they viewed the cells under a microscope the doctors started crying because it turned out to be a very rare form of pancreatic cancer that is curable with surgery. I had the surgery and I'm fine now.
This was the closest I've been to facing death, and I hope its the closest I get for a few more decades. Having lived through it, I can now say this to you with a bit more certainty than when death was a useful but purely intellectual concept:
No one wants to die. Even people who want to go to heaven don't want to die to get there. And yet death is the destination we all share. No one has ever escaped it. And that is as it should be, because Death is very likely the single best invention of Life. It is Life's change agent. It clears out the old to make way for the new. Right now the new is you, but someday not too long from now, you will gradually become the old and be cleared away. Sorry to be so dramatic, but it is quite true.
Your time is limited, so don't waste it living someone else's life. Don't be trapped by dogma - which is living with the results of other people's thinking. Don't let the noise of other's opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition. They somehow already know what you truly want to become. Everything else is secondary.
When I was young, there was an amazing publication called The Whole Earth Catalog, which was one of the bibles of my generation. It was created by a fellow named Stewart Brand not far from here in Menlo Park, and he brought it to life with his poetic touch. This was in the late 1960's, before personal computers and desktop publishing, so it was all made with typewriters, scissors, and polaroid cameras. It was sort of like Google in paperback form, 35 years before Google came along: it was idealistic, and overflowing with neat tools and great notions.
Stewart and his team put out several issues of The Whole Earth Catalog, and then when it had run its course, they put out a final issue. It was the mid-1970s, and I was your age. On the back cover of their final issue was a photograph of an early morning country road, the kind you might find yourself hitchhiking on if you were so adventurous. Beneath it were the words: "Stay Hungry. Stay Foolish." It was their farewell message as they signed off. Stay Hungry. Stay Foolish. And I have always wished that for myself. And now, as you graduate to begin anew, I wish that for you.
Stay Hungry. Stay Foolish.
Thank you all very much.
This is the text of the Commencement address at stanford college by Steve Jobs, CEO of Apple Computer and of Pixar Animation Studios, delivered on June 12, 2005.
I am honored to be with you today at your commencement from one of the finest universities in the world. I never graduated from college. Truth be told, this is the closest I've ever gotten to a college graduation. Today I want to tell you three stories from my life. That's it. No big deal. Just three stories.
The first story is about connecting the dots.
I dropped out of Reed College after the first 6 months, but then stayed around as a drop-in for another 18 months or so before I really quit. So why did I drop out?
It started before I was born. My biological mother was a young, unwed college graduate student, and she decided to put me up for adoption. She felt very strongly that I should be adopted by college graduates, so everything was all set for me to be adopted at birth by a lawyer and his wife. Except that when I popped out they decided at the last minute that they really wanted a girl. So my parents, who were on a waiting list, got a call in the middle of the night asking: "We have an unexpected baby boy; do you want him?" They said: "Of course." My biological mother later found out that my mother had never graduated from college and that my father had never graduated from high school. She refused to sign the final adoption papers. She only relented a few months later when my parents promised that I would someday go to college.
And 17 years later I did go to college. But I naively chose a college that was almost as expensive as Stanford, and all of my working-class parents' savings were being spent on my college tuition. After six months, I couldn't see the value in it. I had no idea what I wanted to do with my life and no idea how college was going to help me figure it out. And here I was spending all of the money my parents had saved their entire life. So I decided to drop out and trust that it would all work out OK. It was pretty scary at the time, but looking back it was one of the best decisions I ever made. The minute I dropped out I could stop taking the required classes that didn't interest me, and begin dropping in on the ones that looked interesting.
It wasn't all romantic. I didn't have a dorm room, so I slept on the floor in friends' rooms, I returned coke bottles for the 5¢ deposits to buy food with, and I would walk the 7 miles across town every Sunday night to get one good meal a week at the Hare Krishna temple. I loved it. And much of what I stumbled into by following my curiosity and intuition turned out to be priceless later on. Let me give you one example:
Reed College at that time offered perhaps the best calligraphy instruction in the country. Throughout the campus every poster, every label on every drawer, was beautifully hand calligraphed. Because I had dropped out and didn't have to take the normal classes, I decided to take a calligraphy class to learn how to do this. I learned about serif and san serif typefaces, about varying the amount of space between different letter combinations, about what makes great typography great. It was beautiful, historical, artistically subtle in a way that science can't capture, and I found it fascinating.
None of this had even a hope of any practical application in my life. But ten years later, when we were designing the first Macintosh computer, it all came back to me. And we designed it all into the Mac. It was the first computer with beautiful typography. If I had never dropped in on that single course in college, the Mac would have never had multiple typefaces or proportionally spaced fonts. And since Windows just copied the Mac, its likely that no personal computer would have them. If I had never dropped out, I would have never dropped in on this calligraphy class, and personal computers might not have the wonderful typography that they do. Of course it was impossible to connect the dots looking forward when I was in college. But it was very, very clear looking backwards ten years later.
Again, you can't connect the dots looking forward; you can only connect them looking backwards. So you have to trust that the dots will somehow connect in your future. You have to trust in something - your gut, destiny, life, karma, whatever. This approach has never let me down, and it has made all the difference in my life.
My second story is about love and loss.
I was lucky – I found what I loved to do early in life. Woz and I started Apple in my parents garage when I was 20. We worked hard, and in 10 years Apple had grown from just the two of us in a garage into a $2 billion company with over 4000 employees. We had just released our finest creation - the Macintosh - a year earlier, and I had just turned 30. And then I got fired. How can you get fired from a company you started? Well, as Apple grew we hired someone who I thought was very talented to run the company with me, and for the first year or so things went well. But then our visions of the future began to diverge and eventually we had a falling out. When we did, our Board of Directors sided with him. So at 30 I was out. And very publicly out. What had been the focus of my entire adult life was gone, and it was devastating.
I really didn't know what to do for a few months. I felt that I had let the previous generation of entrepreneurs down - that I had dropped the baton as it was being passed to me. I met with David Packard and Bob Noyce and tried to apologize for screwing up so badly. I was a very public failure, and I even thought about running away from the valley. But something slowly began to dawn on me – I still loved what I did. The turn of events at Apple had not changed that one bit. I had been rejected, but I was still in love. And so I decided to start over.
I didn't see it then, but it turned out that getting fired from Apple was the best thing that could have ever happened to me. The heaviness of being successful was replaced by the lightness of being a beginner again, less sure about everything. It freed me to enter one of the most creative periods of my life.
During the next five years, I started a company named NeXT, another company named Pixar, and fell in love with an amazing woman who would become my wife. Pixar went on to create the worlds first computer animated feature film, Toy Story, and is now the most successful animation studio in the world. In a remarkable turn of events, Apple bought NeXT, I retuned to Apple, and the technology we developed at NeXT is at the heart of Apple's current renaissance. And Laurene and I have a wonderful family together.
I'm pretty sure none of this would have happened if I hadn't been fired from Apple. It was awful tasting medicine, but I guess the patient needed it. Sometimes life hits you in the head with a brick. Don't lose faith. I'm convinced that the only thing that kept me going was that I loved what I did. You've got to find what you love. And that is as true for your work as it is for your lovers. Your work is going to fill a large part of your life, and the only way to be truly satisfied is to do what you believe is great work. And the only way to do great work is to love what you do. If you haven't found it yet, keep looking. Don't settle. As with all matters of the heart, you'll know when you find it. And, like any great relationship, it just gets better and better as the years roll on. So keep looking until you find it. Don't settle.
My third story is about death.
When I was 17, I read a quote that went something like: "If you live each day as if it was your last, someday you'll most certainly be right." It made an impression on me, and since then, for the past 33 years, I have looked in the mirror every morning and asked myself: "If today were the last day of my life, would I want to do what I am about to do today?" And whenever the answer has been "No" for too many days in a row, I know I need to change something.
Remembering that I'll be dead soon is the most important tool I've ever encountered to help me make the big choices in life. Because almost everything – all external expectations, all pride, all fear of embarrassment or failure - these things just fall away in the face of death, leaving only what is truly important. Remembering that you are going to die is the best way I know to avoid the trap of thinking you have something to lose. You are already naked. There is no reason not to follow your heart.
About a year ago I was diagnosed with cancer. I had a scan at 7:30 in the morning, and it clearly showed a tumor on my pancreas. I didn't even know what a pancreas was. The doctors told me this was almost certainly a type of cancer that is incurable, and that I should expect to live no longer than three to six months. My doctor advised me to go home and get my affairs in order, which is doctor's code for prepare to die. It means to try to tell your kids everything you thought you'd have the next 10 years to tell them in just a few months. It means to make sure everything is buttoned up so that it will be as easy as possible for your family. It means to say your goodbyes.
I lived with that diagnosis all day. Later that evening I had a biopsy, where they stuck an endoscope down my throat, through my stomach and into my intestines, put a needle into my pancreas and got a few cells from the tumor. I was sedated, but my wife, who was there, told me that when they viewed the cells under a microscope the doctors started crying because it turned out to be a very rare form of pancreatic cancer that is curable with surgery. I had the surgery and I'm fine now.
This was the closest I've been to facing death, and I hope its the closest I get for a few more decades. Having lived through it, I can now say this to you with a bit more certainty than when death was a useful but purely intellectual concept:
No one wants to die. Even people who want to go to heaven don't want to die to get there. And yet death is the destination we all share. No one has ever escaped it. And that is as it should be, because Death is very likely the single best invention of Life. It is Life's change agent. It clears out the old to make way for the new. Right now the new is you, but someday not too long from now, you will gradually become the old and be cleared away. Sorry to be so dramatic, but it is quite true.
Your time is limited, so don't waste it living someone else's life. Don't be trapped by dogma - which is living with the results of other people's thinking. Don't let the noise of other's opinions drown out your own inner voice. And most important, have the courage to follow your heart and intuition. They somehow already know what you truly want to become. Everything else is secondary.
When I was young, there was an amazing publication called The Whole Earth Catalog, which was one of the bibles of my generation. It was created by a fellow named Stewart Brand not far from here in Menlo Park, and he brought it to life with his poetic touch. This was in the late 1960's, before personal computers and desktop publishing, so it was all made with typewriters, scissors, and polaroid cameras. It was sort of like Google in paperback form, 35 years before Google came along: it was idealistic, and overflowing with neat tools and great notions.
Stewart and his team put out several issues of The Whole Earth Catalog, and then when it had run its course, they put out a final issue. It was the mid-1970s, and I was your age. On the back cover of their final issue was a photograph of an early morning country road, the kind you might find yourself hitchhiking on if you were so adventurous. Beneath it were the words: "Stay Hungry. Stay Foolish." It was their farewell message as they signed off. Stay Hungry. Stay Foolish. And I have always wished that for myself. And now, as you graduate to begin anew, I wish that for you.
Stay Hungry. Stay Foolish.
Thank you all very much.
Monday, December 18, 2006
SAP BW
SAP NetWeaver: Demos
http://www.sap.com/platform/netweaver/demos/index.epx
https://www.sdn.sap.com/irj/sdn
https://www.sdn.sap.com/irj/sdn/bi-elearning
http://www.sap.com/platform/netweaver/demos/index.epx
https://www.sdn.sap.com/irj/sdn
https://www.sdn.sap.com/irj/sdn/bi-elearning
Psycholinguistics
Scholars who study how words affect our minds and emotions are called psycholinguists, words often carry emotional meanings that extend beyond their dictionary definitions
"The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use the words."
— Philip K. Dick
"There is only one way under high heaven to get anybody to do anything. And that is by making the other person want to do it."
— Dale Carnegie
"When you hear the word ‘save,’ it is usually the beginning of an advertisement designed to make you spend money."
— René Pierre-Gosset
"Sticks and stones can break your bones, but words can make your blood boil."
— Cullen Hightower
"Words, like eye glasses, blur everything that they do not make more clear."
— Joseph Joubert
The sixteen words that really sell
benefit
guarantee
money
results
easy
health
new
safe
free
how to
now
save
fun
love
proven
you/your
"The basic tool for the manipulation of reality is the manipulation of words. If you can control the meaning of words, you can control the people who must use the words."
— Philip K. Dick
"There is only one way under high heaven to get anybody to do anything. And that is by making the other person want to do it."
— Dale Carnegie
"When you hear the word ‘save,’ it is usually the beginning of an advertisement designed to make you spend money."
— René Pierre-Gosset
"Sticks and stones can break your bones, but words can make your blood boil."
— Cullen Hightower
"Words, like eye glasses, blur everything that they do not make more clear."
— Joseph Joubert
The sixteen words that really sell
benefit
guarantee
money
results
easy
health
new
safe
free
how to
now
save
fun
love
proven
you/your
Friday, December 15, 2006
Persuasion Pointers
Persuasion Pointers
Always make sure your body language matches your verbal communication. When your body language and words clash, your body language will have the greater impact.
You rarely get a second chance to make a favorable impression. It only takes four minutes to lock in a negative impression.
To create rapport using body language, face the other person, assume an open posture, lean forward, maintain eye contact, and shake hands.
Always present yourself in the most advantageous way possible. Dress to communicate authority, competence, and professionalism.
To deepen rapport, mirror the other person's posture, language, and rate of speech.
Control your tone of voice, speed of delivery, pitch, and volume to project confidence and authority. Use pauses for impact.
To detect deceit, look for contradictions and verbal mistakes. Watch for clashes between the verbal and nonverbal messages.
Always make sure your body language matches your verbal communication. When your body language and words clash, your body language will have the greater impact.
You rarely get a second chance to make a favorable impression. It only takes four minutes to lock in a negative impression.
To create rapport using body language, face the other person, assume an open posture, lean forward, maintain eye contact, and shake hands.
Always present yourself in the most advantageous way possible. Dress to communicate authority, competence, and professionalism.
To deepen rapport, mirror the other person's posture, language, and rate of speech.
Control your tone of voice, speed of delivery, pitch, and volume to project confidence and authority. Use pauses for impact.
To detect deceit, look for contradictions and verbal mistakes. Watch for clashes between the verbal and nonverbal messages.
Thought for the day
"When dealing with people, remember you are not dealing with creatures of logic, but with creatures of emotion, creatures bristling with prejudice and motivated by pride and vanity."
- DALE CARNEGIE
"The object of oratory is not truth but persuasion."
— Thomas Babington Macaulay
"Agreement is brought about by changing people's minds - other people's."
— S. I. Hayakawa
"Get your facts first, then you can distort them as you please."
-MARK TWAIN
"To be persuasive, we must be believable. To be believable, we must be credible. To be credible, we must be truthful."
— Edward R. Murrow
"The truth isn't the truth until people believe you."
— Bill Bernbach
Trust + Expertise = Credibility
Winston Churchill once asked Cockran(his mentor): "Bourke, what is the secret of eloquence?" Bourke replied: "Believing in what you are talking about." Cockran summed it up: "Sincerity — never speak what you don't believe"
"One of the most effective ways to get into a prospect's mind is to first admit a negative and then twist it into a positive."
"The truth isn't the truth until people believe you, and they can't believe you if they don't know what you're saying, and they can't know what you're saying if they don't listen to you, and they won't listen to you if you're not interesting, and you won't be interesting unless you say things imaginatively, originally, freshly."
"The law of candor must be used with great skill. First your negative must be widely perceived as a negative. It has to trigger instant agreement with your prospect's mind. Next you have to shift quickly to the positive. The purpose of candor is not to apologize. The purpose of candor is to set up a benefit that will convince your prospect."
Never assume that people trust you. Take every opportunity to prove that your word is your bond
"You don't get a second chance to make a first impression"
Mirroring Language
One of the best ways to build rapport through mirroring is to use the specialist vocabulary or jargon of the person whom you are trying to influence. Most great sellers consciously use their client's vocabulary or jargon when presenting.
Here are examples of a stockbroker selling to an accountant and to an architect; notice how the stockbroker weaves the vocabulary of her client into the conversation:
Example one: Selling stocks to an accountant. "I've analyzed your portfolio and think you should consider selling some stocks. The figures show that some of your holdings are weak. When you add up my ideas I'm sure you'll agree."
Example two: Selling stocks to an architect. "I've analyzed your holdings and see some need to change the structure of your portfolio of stocks. I've a few ideas that will give you a better foundation and better support. As you review the blueprint, I'm sure you'll agree."[30]
- DALE CARNEGIE
"The object of oratory is not truth but persuasion."
— Thomas Babington Macaulay
"Agreement is brought about by changing people's minds - other people's."
— S. I. Hayakawa
"Get your facts first, then you can distort them as you please."
-MARK TWAIN
"To be persuasive, we must be believable. To be believable, we must be credible. To be credible, we must be truthful."
— Edward R. Murrow
"The truth isn't the truth until people believe you."
— Bill Bernbach
Trust + Expertise = Credibility
Winston Churchill once asked Cockran(his mentor): "Bourke, what is the secret of eloquence?" Bourke replied: "Believing in what you are talking about." Cockran summed it up: "Sincerity — never speak what you don't believe"
"One of the most effective ways to get into a prospect's mind is to first admit a negative and then twist it into a positive."
"The truth isn't the truth until people believe you, and they can't believe you if they don't know what you're saying, and they can't know what you're saying if they don't listen to you, and they won't listen to you if you're not interesting, and you won't be interesting unless you say things imaginatively, originally, freshly."
"The law of candor must be used with great skill. First your negative must be widely perceived as a negative. It has to trigger instant agreement with your prospect's mind. Next you have to shift quickly to the positive. The purpose of candor is not to apologize. The purpose of candor is to set up a benefit that will convince your prospect."
Never assume that people trust you. Take every opportunity to prove that your word is your bond
"You don't get a second chance to make a first impression"
Mirroring Language
One of the best ways to build rapport through mirroring is to use the specialist vocabulary or jargon of the person whom you are trying to influence. Most great sellers consciously use their client's vocabulary or jargon when presenting.
Here are examples of a stockbroker selling to an accountant and to an architect; notice how the stockbroker weaves the vocabulary of her client into the conversation:
Example one: Selling stocks to an accountant. "I've analyzed your portfolio and think you should consider selling some stocks. The figures show that some of your holdings are weak. When you add up my ideas I'm sure you'll agree."
Example two: Selling stocks to an architect. "I've analyzed your holdings and see some need to change the structure of your portfolio of stocks. I've a few ideas that will give you a better foundation and better support. As you review the blueprint, I'm sure you'll agree."[30]
Dos and Don'ts for Entrepreneurs, from Those Who Have Actually Done It
Good article on entrepreneurship : funding your business and getting ideas for business
Friday, August 18, 2006
On SOA
What is SOA
Architectural Style
Business Alignment
Reduced assumptions (loose coupling)
Builds on ideas from component software, distributed objects, and MOM
Message based communication
A service is a program you interact with via message exchanges
-Services are built to last
-Encompass a business perspective
-Stability and robustness are critical
A system is a set of deployed services cooperating in a given task
-Systems are built to change
-Adapt to new services after deployment
Architectural Style
Business Alignment
Reduced assumptions (loose coupling)
Builds on ideas from component software, distributed objects, and MOM
Message based communication
A service is a program you interact with via message exchanges
-Services are built to last
-Encompass a business perspective
-Stability and robustness are critical
A system is a set of deployed services cooperating in a given task
-Systems are built to change
-Adapt to new services after deployment
On Architecture
What’s Architecture
“the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution”. (IEEE 1471)
Architecture defines major components ,
Architecture defines component relationships (structures) and interactions,
Architecture defines the rationale behind the components and the structure
Architecture is not a single structure -- no single structure is the architecture
Architecture represents the set of earliest design decisions
-Hardest to change
-Most critical to get right
Architecture is the first design artifact where a system’s quality attributes are addressed
Architecture serves as the blueprint for the system but also the project:
-Team structure
-Documentation organization
-Work breakdown structure
-Scheduling, planning, budgeting
-Unit testing, integration
Architecture establishes the communication and coordination mechanisms among components
Architecture is important
-it should be analyzed
Architecture can be prescribed
-decisions should be analyzed
Architecture is central for communicating
-it should be documented
Architecture is expensive to change
-it is cheaper to analyze early
Architecture affects the entire project
-many stakeholders should be involved
Requirements can be understood early
-architecture should be designed to meet them
Different view points
End user view:
Performance
Availability
Usability
Security
Developer’s view:
Maintainability
Portability
Reusability
Testability
Business user view
Time To Market
Cost and Benefits
Projected life time
Targeted Market
Integration with Legacy System
Roll back Schedule
“the fundamental organization of a system, embodied in its components, their relationships to each other and the environment, and the principles governing its design and evolution”. (IEEE 1471)
Architecture defines major components ,
Architecture defines component relationships (structures) and interactions,
Architecture defines the rationale behind the components and the structure
Architecture is not a single structure -- no single structure is the architecture
Architecture represents the set of earliest design decisions
-Hardest to change
-Most critical to get right
Architecture is the first design artifact where a system’s quality attributes are addressed
Architecture serves as the blueprint for the system but also the project:
-Team structure
-Documentation organization
-Work breakdown structure
-Scheduling, planning, budgeting
-Unit testing, integration
Architecture establishes the communication and coordination mechanisms among components
Architecture is important
-it should be analyzed
Architecture can be prescribed
-decisions should be analyzed
Architecture is central for communicating
-it should be documented
Architecture is expensive to change
-it is cheaper to analyze early
Architecture affects the entire project
-many stakeholders should be involved
Requirements can be understood early
-architecture should be designed to meet them
Different view points
End user view:
Performance
Availability
Usability
Security
Developer’s view:
Maintainability
Portability
Reusability
Testability
Business user view
Time To Market
Cost and Benefits
Projected life time
Targeted Market
Integration with Legacy System
Roll back Schedule
Subscribe to:
Posts (Atom)