Saturday, August 20, 2011

Open Source Android OS

Google's Open Source Android OS Will Free the Wireless Web
By Daniel Roth 06.23.08


Google wants to bring the coolest bits of the Web to your cell phone.
Illustration: Christian Montenegro "Is this interesting to Google?" That's what Andy Rubin was asking Larry Page. It was a spring day in 2005, and the two were in a conference room just off the main lobby at Google's headquarters. A simple yes and Rubin would have walked away happy.

They had met three years before, when Rubin was about to launch a smartphone he'd invented called the Sidekick. At the time, Google was just an up-and-comer, trailing AOL and even Lycos in traffic. But Rubin, a well-known Silicon Valley player, chose Google as the Sidekick's default search engine. Page was flattered by the unexpected endorsement. So when Rubin called out of the blue and requested this meeting, well, Page couldn't say no.

The Google cofounder arrived late, as usual. Rubin walked to the whiteboard and began his pitch. There were nearly 700 million cell phones sold each year compared with fewer than 200 million PCs — and the gap was widening. Increasingly, he said, phones were the way people wanted to connect with each other and with everything else. Yet the mobile industry was stuck in the dark ages. Unlike the Web, where open standards had fostered a multitude of cool companies and applications, mobile was a tyrannical, closed system, repelling all innovators and disrupters who tried to gain entrance.

Rubin said his startup, called Android, had the solution: a free, open source mobile platform that any coder could write for and any handset maker could install. He would make his money by selling support for the system — security services, say, or email management. Android would have the spirit of Linux and the reach of Windows. It would be a global, open operating system for the wireless future.

Rubin didn't want money from Page. He already had funding. What he wanted was Google's imprimatur — even an email from Page would do. Rubin figured he could attract more VC funds with the search giant on board, possibly with a hint that Google might be interested in developing its own branded phone. He pulled out a prototype.

Page picked up the device. He had been personally frustrated yet fascinated by the mobile market for years. He already knew the numbers — he didn't need Rubin to tell him how many PCs and mobile phones were out there. He also knew that it added up to a massive problem for Google.

The desktop metaphor was fading. Phones were going to replace PCs as the main gateway to the Internet, and they were going to do it soon. Why would consumers tether themselves to a PC when phones were growing more and more powerful — and were cheaper, too?

But because cell phones ran on different software, had less memory, and operated under the constraints of pay-per-byte wireless networks, the mobile Web was a stripped-down, mimeographed version of the real thing. Reading and surfing and — more to the point — viewing Google ads was a slow, stultifying chore. Even worse, a second-class Web could derail Google's grand strategy. The company was trying to worm its way deeper into users' lives by hosting applications and personal files on Google servers, then dishing them out to the always-connected consumer whenever and wherever needed. That was easy on PCs, but phones didn't play nice with the cloud. Google dominated the Web today, but tomorrow might be a different story.

Working the problem had been a nightmare. Google engineers had a closet overflowing with mobile phones to test the company's wireless applications — mobile Google, Blogger, search over SMS. There were dozens of operating systems to navigate, a mobile Tower of Babel completely at odds with the easy access and universal language of the Web.

What worried Page most was that the only firm from the PC world that seemed to be successfully navigating the mobile labyrinth was Microsoft, one of Google's biggest rivals. The Windows Mobile platform had less than 10 percent of the US smartphone market, but it was growing fast. Microsoft's system, however, was the ugly stepsister of what Rubin was proposing: Redmond executives cared less about opening up the Net to mobile users than about tying the mobile operating system into its desktop dominance. A decade ago, Microsoft had underestimated the growth of the Web and then lost control of it to Google. Now it looked like it was Google's turn to be caught flat-footed.


Andy Rubin wants to bring the coolest bits of the web to your cell phone.
Photo: Joe PuglieseIf Google had it bad, users had it worse. Every year since 2002, the wireless sector managed to place at or near the top of the Better Business Bureau's tally of the most complained-about industries. Americans would rather do business with a used-car salesman or a collection agent than with a customer service rep for, say, T-Mobile or Motorola. And who could blame them? The plans were expensive, pricing was complex and capricious, and the phones never lived up to expectations. Constant innovation, the first principle of Page and Rubin's world, was anathema to phone companies. There had to be pent-up demand out there for something better.

So was Rubin's pitch interesting to Page? Absolutely. But he didn't want to stick his logo on Rubin's phone. Or write a supportive email. He had a better idea: Google would buy Android.

Rubin was floored. He had come in looking for an encouraging word and left with the biggest payday in his life. (The eventual purchase price was estimated at as much as $50 million.) Now all he had to do was live up to his own hype.

"Google's model is to build a killer app, then monetize it later," Rubin says. We're sitting in another conference room across the street from where he and Page struck their deal three years ago. The building, which houses Google's mobile division, is Rubin's domain now. There's a self-piloting model helicopter bearing an Android logo parked in the hall — Rubin builds them in his spare time. Beyond are floors of people who think of nothing but the cellular future of their employer. In the lobby, a flatscreen TV shows a spinning globe with animated flares erupting wherever people are using Google to search from their mobile phones. This fall, when the first Android phones hit the market, those flares will presumably flame even higher.

Rubin is tall and skinny and a casual dresser even by Google standards. He's 45 but seems younger. Sitting with one leg tucked beneath him, he explains the mission of the Googlefied Android to me, but I barely follow the words. I'm staring at his phone. It's clearly a demo — black, scuffed, covered with fingerprints; most of the face is taken up by the screen. Rubin absentmindedly slides it around the big wooden table, then picks it up and shifts it from hand to hand. It's maddening. All I want to do is get a closer look at his killer app.

After Google bought Android in July 2005, Silicon Valley pulsed with gossip and speculation about what the search giant was planning. Everyone figured Apple had a phone in the works and assumed Google must be developing one too. Rubin and his cofounders, Rich Miner, Nick Sears, and Chris White, weren't talking. "Trying to guess Google's next move recently replaced digging through Steve Jobs' garbage ... at the top of our weekend activities list," wrote tech blog Engadget. When Apple unveiled the iPhone last summer, expectations for a gPhone — could it be called anything else? — grew even more feverish.

But when Google finally broke its silence in early November, there was nothing about a gPhone. Instead, there was a press release. Thirty-four companies — firms like Texas Instruments, Intel, T-Mobile, and Sprint Nextel — were joining Google to build a wireless interface based on open source Linux software. The group dubbed itself the Open Handset Alliance. Competitors sighed in relief. This was how Google planned to shake up the nearly trillion-dollar global wireless market? A consortium?

"Their efforts are just some words on paper," remarked Steve Ballmer, CEO of Microsoft, at a conference in Japan. "Another Linux platform," shrugged the CEO of Symbian, the dominant smartphone operating system outside the US.

A week later, Google upped the ante. The company put a free Android software developer's kit on its Web site and announced the Developer Challenge, with $10 million in prize money to be parceled out to the creators of the best applications for the new system — a great social networking tool, say, or a handwriting recognition program. The Challenge was an open call; anyone was invited to take a shot.

Those hoping for a new gadget to rival the iPhone finally understood that Google had something radically different in mind. Apple's device was an end in itself — a self-contained, jewel-like masterpiece locked in a sleek protective shell. Android was a means, a seed intended to grow an entire new wireless family tree. Google was never in the hardware business. There would be no gPhone — instead, there would be hundreds of gPhones.

Saturday, April 30, 2011

Cloud computing: A Threat to Indian Outsourcers?

Cloud computing, defined as a subscription-based or pay-per-use service that in real time, and over the Internet, extends existing capabilities of Information Technology, remains at an early stage of conceptual development. Services do range from full scale applications such as accounting and storage to niche services such as spam filtering.




Proponents of cloud computing contend that it erodes the requirements for major capital expenditures on IT infrastructure to customer applications. However, will cloud computing replace outsourcing and does Cloud computing "represents a fundamental shift in how financial companies pay for and access IT services?"




Cloud computing differs from traditional outsourcing in a number of respects. The contractual commitments, sometimes defined as subscriptions, tend to be for short periods of time, as little as a session to a month. The contracts rarely have up-front tariff charges.




The services are available are on demand but, while cloud computing services may be capable of some scaling they are most certainly not capable of unlimited instant scaling and addition of near unlimited resource. Semantically, cloud computing may be defined as "instant outsourcing."




Indian outsourcers may consider extending their outsourcing services to the cloud computing domain, where their existing IT infra-structure services have spare resources capacity. They do have the resources to fill that gap in instant outsourcing through almost unlimited scaling and addition of near unlimited resources.




Where Indian outsourcers consider formally entering the area of cloud computing services, they should position cloud computing services as separate and distinct from their existing outsourcing services, containing no overlapping services with core outsourcing, even to existing clients. Pricing models differ.




While delivery of cloud computing services may be personalized, its services and service strategy is not collaborative. Outsourcers may consider using cloud computing as a means of selling non-core applications and services, which can impede the financial incremental benefits of major outsourcing contracts.




Many institutions, particularly in the financial services sector, are unlikely to entrust major aspects of data use and application to cloud computing services, unless and until their trust in those services has grown.




So, issues such as data security, systems integration, unexpected and tactical demand for capacity will be critical service hurdles that all cloud computing providers will have to clear to engage major clients in cloud computing in core areas of their technology structure and services provision.




Major external technology service provision is likely to remain a traditional strategically based outsourcing service. The need to respond tactically and spontaneously to immediate and short term business demands will erode the non-core elements of technology outsourcing.




If cloud computing can position itself an element of strategic information technology planning, then it will start to make more substantial inroads into traditional outsourcing.

How to write fast code

How to write fast code
There was a time, early in my programming career, when I needed to rewrite a particular program (a very small one) to make it run faster. I was quite new to programming and thought that the way to get something to run faster was to rewrite it in assembly. In those days, you could unroll a loop in assembly and pretty much count on getting a worthwhile speedup, if it was a tight loop to begin with.

Fortunately, I had a fabulous mentor in those days, a coder with wisdom and experience far beyond his years. The person in question was a first-class code ninja and a master circuit designer, a genius of Woz-like proportions. Silicon obeyed him the way marble obeyed Michelangelo.

When it came to code, John could do astounding things. He could optimize (and did optimize) virtually any algorithm for any situation, and do it in so little code that you'd sit there studying the printout, wondering where the heck the algorithm went! I remember John had this peculiar way of making loops vanish, for example. They'd turn into table-lookups or recursion or self-modifying code, or some combination of the three.

One day my mentor asked me what I was working on and I told him. I mentioned that I was frantically searching for a way to speed up my little program. I described a few of the things I'd tried so far. He listened intently.

When I was done talking, John gave me some of the most profound advice any programming expert has ever given me. (It was profound for me, at the time. Maybe it'll be stupid-sounding to you.)

"The CPU," he said, "runs at a certain speed. It can execute a fixed number of instructions per second, and no more. There is a finite limit to how many instructions per second it can execute. Right?"

"Right," I said.

"So there is no way, really, to make code go faster, because there is no way to make instructions execute faster. There is only such a thing as making the machine do less."

He paused for emphasis.

"To go fast," he said slowly, "do less."

To go fast, do less. Do less; go fast. Yes, of course. It makes perfect sense. There's no other way to make a program run faster except to make it do less. (Here, when I say "program," I'm not talking about complex, orchestrated web apps or anything with fancy dependencies, just standalone executables in which there's a "main loop.")

Key takeaway: Don't think in terms of making a slow piece of code run faster. Instead, think in terms of making it do less.

In many cases, doing less means using a different algorithm. Then again, it may be as simple as inserting a few if-elses to check for a few trivial (but frequently encountered) "special cases" and return early, before entering a fully-generalized loop.

It may mean canonicalizing your data in some way before passing it to the main routine, so that the main routine doesn't have to include code that checks for corner cases.

The tricks are endless, but they end up with the CPU doing less, not more; and that's the key.

The "go fast do less" mantra has been a valuable one for me, paying off in many ways, in many situations, over the years. It has helped me understand performance issues in a different kind of way. I'm grateful to have been exposed to that concept early in my career. So I provide it here for you to use (or not use) as you see fit

Friday, December 18, 2009

java database test

import java.sql.*;
import java.io.*;

public class JDBCTest
{
public static void main(String args[])
{
try{
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
Connection c=DriverManager.getConnection
("jdbc:odbc:rama;uid=scott;pwd=tiger;");

Statement st=c.createStatement();
ResultSet rs=st.executeQuery("Select stno,stname,stmarks from student");
try{
while(rs.next())
{
System.out.print(rs.getInt("stno")+" ");
System.out.print(rs.getString("stname")+" ");
System.out.println(rs.getString("stmarks"));

}
}
catch(Exception e)
{
System.out.println("inside:"+e);
}
}
catch(Exception e)
{
System.out.println(e);
}
}
}


Calculator

import java.awt.*;
import java.awt.event.*;
import java.applet.*;

/*
*/

public class calc extends Applet implements ActionListener{
String msg = "",flag = "";
int i=0,j=0;
Button one,two,three,four,five,six,seven,eight,nine,zero;
Button plus,minus,mul,div,equal,ce;
TextField text;
Button blist[] = new Button[10];

public void init(){
setLayout(null);
one = new Button("1");
two = new Button("2");
three = new Button("3");
four = new Button("4");
five = new Button("5");
six = new Button("6");
seven = new Button("7");
eight = new Button("8");
nine = new Button("9");
zero = new Button("0");

plus = new Button("+");
minus = new Button("-");
mul = new Button("*");
div = new Button("/");
equal = new Button("=");
ce = new Button("c");

one.setBounds(200,200,20,20);
two.setBounds(230,200,20,20);
three.setBounds(260,200,20,20);
four.setBounds(200,230,20,20);
five.setBounds(230,230,20,20);
six.setBounds(260,230,20,20);
seven.setBounds(200,260,20,20);
eight.setBounds(230,260,20,20);
nine.setBounds(260,260,20,20);
zero.setBounds(200,290,20,20);

plus.setBounds(290,200,20,20);
minus.setBounds(290,230,20,20);
mul.setBounds(290,260,20,20);
div.setBounds(290,290,20,20);
equal.setBounds(260,290,20,20);
ce.setBounds(230,290,20,20);

text = new TextField(10);
text.setBounds(200,170,110,20);
blist[0] = (Button) add(zero);
blist[1] = (Button) add(one);
blist[2] = (Button) add(two);
blist[3] = (Button) add(three);
blist[4] = (Button) add(four);
blist[5] = (Button) add(five);
blist[6] = (Button) add(six);
blist[7] = (Button) add(seven);
blist[8] = (Button) add(eight);
blist[9] = (Button) add(nine);
add(plus);
add(minus);
add(mul);
add(div);
add(equal);
add(ce);
add(text);
for(int i=0;i<10;i++)
blist[i].addActionListener(this);
plus.addActionListener(this);
minus.addActionListener(this);
mul.addActionListener(this);
div.addActionListener(this);
equal.addActionListener(this);
ce.addActionListener(this);
text.addActionListener(this);
}

public void actionPerformed(ActionEvent ae){
String str = ae.getActionCommand();
if(str.equals("1"))
i = i*10 + 1;
else if(str.equals("2"))
i = i*10 + 2;
else if(str.equals("3"))
i = i*10 + 3;
else if(str.equals("4"))
i = i*10 + 4;
else if(str.equals("5"))
i = i*10 + 5;
else if(str.equals("6"))
i = i*10 + 6;
else if(str.equals("7"))
i = i*10 + 7;
else if(str.equals("8"))
i = i*10 + 8;
else if(str.equals("9"))
i = i*10 + 9;
else if(str.equals("0"))
i = i*10;
if (str.equals("=")){
if (flag.equals("+"))
i += j;
if (flag.equals("-"))
i = j-i;
if (flag.equals("*"))
i *= j;
if (flag.equals("/"))
i = j/i;
}
if (str.equals("+")){
if (flag.equals("+"))
{i += j;j=i;}
else
{j = i;i=0;}
flag = "+";
}
if (str.equals("-")){
if (flag.equals("-"))
{ i = j-i;j=i;}
else
{j = i;i=0;}
flag = "-";
}
if (str.equals("*")){
if (flag.equals("*"))
{ i *= j;j=i;}
else
{j = i;i=0;}
flag = "*";
}
if (str.equals("/")){
if (flag.equals("/"))
{ i = j/i;j=i;}
else
{j = i;i=0;}
flag = "/";
}
if (str.equals("c"))
{ i = 0;j=0;flag = "";}

text.setText(i+"");
if (str.equals("=")) i=0;
repaint();
}

public void paint(Graphics g){
g.drawString(msg,100,100);
}
}

Sunday, November 22, 2009

pg poject topic

Projecttopics.info

Home
Sitemap

Network Monitoring System Communication

Micro Controller based Power Theft Identifier

All rights reserved ® Copyright © V2computers 2007 through 2010