Innovation--CHANGE IS WHAT WE NEED
ON SPOT SOLUTION TO ALL YOUR PROBLEMS.
Sunday, January 16, 2011
Friday, December 10, 2010
Why Learn C?
I know many of you wander why to learn a language whose coding was written four decades before,a language which is now preceded by more advance & user friendly languages, for answering all your queries i have this article for you..
C is the most commonly used programming language for writing operating systems. Unix was the first operating system written in C. Later Microsoft Windows, Mac OS X, and GNU/Linux were all written in C. Not only is C the language of operating systems, it is the precursor and inspiration for almost all of the most popular high-level languages available today. In fact, Perl, PHP, Python, and Ruby are all written in C.
By way of analogy, let's say that you were going to be learning Spanish, Italian, French, or Portuguese. Do you think knowing Latin would be helpful? Just as Latin was the basis of all of those languages, knowing C will enable you to understand and appreciate an entire family of programming languages built upon the traditions of C. Knowledge of C enables freedom.
Why C, and not assembly language?
While assembly language can provide speed and maximum control of the program, C provides portability.
Different processors are programmed using different Assembly languages and having to choose and learn only one of them is too arbitrary. In fact, one of the main strengths of C is that it combines universality and portability across various computer architectures while retaining most of the control of the hardware provided by assembly language.
For example, C programs can be compiled and run on the HP 50g calculator (ARM processor), the TI-89 calculator (68000 processor), Palm OS Cobalt smartphones (ARM processor), the original iMac (PowerPC), the Arduino (Atmel AVR), and the Intel iMac (Intel Core 2 Duo). Each of these devices has its own assembly language that is completely incompatible with the assembly language of any other.
Assembly, while extremely powerful, is simply too difficult to program large applications and hard to read or interpret in a logical way. C is a compiled language, which creates fast and efficient executable files. It is also a small "what you see is all you get" language: a C statement corresponds to at most a handful of assembly statements, everything else is provided by library functions.
So is it any wonder that C is such a popular language?
Like toppling dominoes, the next generation of programs follows the trend of its ancestors. Operating systems designed in C always have system libraries designed in C. Those system libraries are in turn used to create higher-level libraries (like OpenGL, or GTK), and the designers of those libraries often decide to use the language the system libraries used. Application developers use the higher-level libraries to design word processors, games, media players and the like. Many of them will choose to program in the language that higher-level library uses. And the pattern continues on and on and on...
Why C, and not another high-level language?
The primary design of C is to produce portable code while maintaining performance and minimizing footprint, as is the case for operating systems or other programs where a "high-level" interface would affect performance. It is a stable and mature language whose features are unlikely to disappear for a long time and has been ported to most, if not all, platforms.
For example, C programs can be compiled and run on the HP 50g calculator (ARM processor), the TI-89 calculator (68000 processor), Palm OS Cobalt smartphones (ARM processor), the original iMac (PowerPC), the Arduino (Atmel AVR), and the Intel iMac (Intel Core 2 Duo). While nearly all popular programming languages will run on at least one of these devices, C may be the only programming language that runs on more than 3 of these devices.
One powerful reason is memory allocation. Unlike most computer languages, C allows the programmer to write directly to memory. Key constructs in C such as structs, pointers and arrays are designed to structure, and manipulate memory in an efficient, machine-independent fashion. In particular, C gives control over the memory layout of data structures. Moreover dynamic memory allocation is under the control of the programmer, which inevitably means that memory deallocation is the burden of the programmer. Languages like Java and Perl shield the programmer from having to worry about memory allocation and pointers. This is usually a good thing, since dealing with memory allocation when building a high-level program is a highly error-prone process. However, when dealing with low level code such as the part of the OS that controls a device, C provides a uniform, clean interface. These capabilities just do not exist in other languages such as Java.
While Perl, PHP, Python and Ruby may be powerful and support many features not provided by default in C, they are not normally implemented in their own language. Rather, most such languages initially relied on being written in C (or another high-performance programming language), and would require their implementation be ported to a new platform before they can be used.
As with all programming languages, whether you want to choose C over another high-level language is a matter of opinion and both technical and business requirements.
C is the most commonly used programming language for writing operating systems. Unix was the first operating system written in C. Later Microsoft Windows, Mac OS X, and GNU/Linux were all written in C. Not only is C the language of operating systems, it is the precursor and inspiration for almost all of the most popular high-level languages available today. In fact, Perl, PHP, Python, and Ruby are all written in C.
By way of analogy, let's say that you were going to be learning Spanish, Italian, French, or Portuguese. Do you think knowing Latin would be helpful? Just as Latin was the basis of all of those languages, knowing C will enable you to understand and appreciate an entire family of programming languages built upon the traditions of C. Knowledge of C enables freedom.
Why C, and not assembly language?
While assembly language can provide speed and maximum control of the program, C provides portability.
Different processors are programmed using different Assembly languages and having to choose and learn only one of them is too arbitrary. In fact, one of the main strengths of C is that it combines universality and portability across various computer architectures while retaining most of the control of the hardware provided by assembly language.
For example, C programs can be compiled and run on the HP 50g calculator (ARM processor), the TI-89 calculator (68000 processor), Palm OS Cobalt smartphones (ARM processor), the original iMac (PowerPC), the Arduino (Atmel AVR), and the Intel iMac (Intel Core 2 Duo). Each of these devices has its own assembly language that is completely incompatible with the assembly language of any other.
Assembly, while extremely powerful, is simply too difficult to program large applications and hard to read or interpret in a logical way. C is a compiled language, which creates fast and efficient executable files. It is also a small "what you see is all you get" language: a C statement corresponds to at most a handful of assembly statements, everything else is provided by library functions.
So is it any wonder that C is such a popular language?
Like toppling dominoes, the next generation of programs follows the trend of its ancestors. Operating systems designed in C always have system libraries designed in C. Those system libraries are in turn used to create higher-level libraries (like OpenGL, or GTK), and the designers of those libraries often decide to use the language the system libraries used. Application developers use the higher-level libraries to design word processors, games, media players and the like. Many of them will choose to program in the language that higher-level library uses. And the pattern continues on and on and on...
Why C, and not another high-level language?
The primary design of C is to produce portable code while maintaining performance and minimizing footprint, as is the case for operating systems or other programs where a "high-level" interface would affect performance. It is a stable and mature language whose features are unlikely to disappear for a long time and has been ported to most, if not all, platforms.
For example, C programs can be compiled and run on the HP 50g calculator (ARM processor), the TI-89 calculator (68000 processor), Palm OS Cobalt smartphones (ARM processor), the original iMac (PowerPC), the Arduino (Atmel AVR), and the Intel iMac (Intel Core 2 Duo). While nearly all popular programming languages will run on at least one of these devices, C may be the only programming language that runs on more than 3 of these devices.
One powerful reason is memory allocation. Unlike most computer languages, C allows the programmer to write directly to memory. Key constructs in C such as structs, pointers and arrays are designed to structure, and manipulate memory in an efficient, machine-independent fashion. In particular, C gives control over the memory layout of data structures. Moreover dynamic memory allocation is under the control of the programmer, which inevitably means that memory deallocation is the burden of the programmer. Languages like Java and Perl shield the programmer from having to worry about memory allocation and pointers. This is usually a good thing, since dealing with memory allocation when building a high-level program is a highly error-prone process. However, when dealing with low level code such as the part of the OS that controls a device, C provides a uniform, clean interface. These capabilities just do not exist in other languages such as Java.
While Perl, PHP, Python and Ruby may be powerful and support many features not provided by default in C, they are not normally implemented in their own language. Rather, most such languages initially relied on being written in C (or another high-performance programming language), and would require their implementation be ported to a new platform before they can be used.
As with all programming languages, whether you want to choose C over another high-level language is a matter of opinion and both technical and business requirements.
Thursday, December 9, 2010
Who's reading your Twitter DMs?
Every Twitter application you authorise has near-complete control over your account – and that includes your private data

"What will we do," asked Bill Thompson recently, "when the next WikiLeaks hoard is every Twitter DM [direct message] or Facebook chat transcript?"
That's unlikely to happen, of course. Julian Assange's team are more concerned with international affairs than bothering the millions of casual Twitterers. If you're not on the public stage, the chances are that you're just not notable enough for Wikileaks.
Of course, there are still plenty of folks that would cause chaos in suburbia if they could, just for the laughs. I'm a little closer to this subject than most – because I can read your private Twitter messages.Well, maybe not yours, specifically. But the odds are good that – if I wanted to – I could look through the direct messages of several of the people who'll read this.
A few months ago, after Twitter had implemented its OAuth authorisation system, I was hired to put together a Twitter toy application – one of those little web pages that offers some sort-of-interesting statistic about your tweets, as long as you log in with your Twitter account. Of course, it then invites you to tweet that statistic out to your friends – along with a link and a small advertising message.
The trouble is that Twitter's authorisation process makes no distinction between small toys like that and big applications like TweetDeck that handle your entire account. Toys only need to read public messages and perhaps tweet once, but usually request, and are being given "read and write" permission, which means they can do every action Twitter can provide an authorised user: the power to change profile pictures, follow and block users, and – crucially – read direct messages. Changing your password doesn't lock them out either; you need to explicitly revoke their access.
So if I wanted to, I could use the authorisations given to the toy application to download the direct messages of all of its thousands of users. I'm not going to, of course – it's illegal and unethical – but curiosity is a powerful thing. Imagine a web page that simply asks "Whose inbox would you like to read?". Would you trust everyone you know not to use it? How about everyone they know? What if the attack had already been performed by someone else, and they'd actively leaked those messages to the world – would you still be able to resist seeing what was in your friends' inboxes if the damage was already done?Using existing applications' permissions isn't the only potential attack. Toy applications with poor security could provide a back door into people's Twitter accounts without their creators' knowledge. And those with espionage on their minds could create an application that works as advertised until it sees a particular user; the world's millions of inboxes might not be of interest, but specific ones might be.
Bill Thompson's WikiLeaks scenario, where every Twitter DM is somehow released, is unlikely. But without wanting to scaremonger, I'd say that unless Twitter starts using granular, Facebook-like authorisation, it's a matter of when – not if – an application goes rogue. Mischief isn't a strong motivator for releasing personal data (the risks are too high) but it only takes one script-kiddie cracker with a desire for notoriety, and suddenly The Pirate Bay is serving "two-million-twitter-DMs.rar" to anyone who's interested.
The bottom line is this: almost every Twitter application you authorise, no matter how trivial, has near-complete control over your account. This is not a new revelation, but it still takes a lot of people by surprise. If you haven't recently checked the Connections page of your Twitter account to see which applications you've authorised, you should. And revoke them unless you're certain you want to take the risk of them going rogue at some point
Wednesday, December 8, 2010
Google unveils Chrome OS for notebooks - but puts it off to mid-2011
If the world needs an OS for netbooks and notebooks that depends on cloud connectivity, Google has the product for it - but not for six or seven months
Google has shown off its Chrome OS, the operating system that will power a new range of notebooks - but says its launch will be delayed until "mid-2011" with no indication of price or performance characteristics of machines that will run it.
The idea behind the Chromium OS is that it will coordinate with cloud services, especially Google's, to minimise the amount of local storage required and to allow people to use any Chromium device to access the same cloud-saved data and synchronise locally-stored data to the cloud.The launch has been delayed because Chrome OS still has too many bugs - 2,227 according to the official page, including "sync is not working" which was the top one at the time of writing.
The huge question is whether Chrome OS will challenge Windows on low-end machines, particularly netbooks. But with the netbook market shrinking as buyers shift towards tablets, there are questions too about whether Chrome OS is too little, too late: Android is doing remarkably well on mobile phones and tablets, while Microsoft has managed to persuade netbook makers to use a low-end version of Windows 7.
Plus Chrome OS will require the user to have regular - though not persistent - connectivity to the internet."We think cloud computing will define computing as we know it," said Eric Schmidt, Google's chief operating officer, at the announcement - which falls notably short of a launch. "Finally there is a viable third choice for an operating system."
Some Linux, and particularly Ubuntu fans, might wonder which three he's talking about, given that Windows and Mac OS X are the two OSs you can buy in the shops. Is Schmidt saying Ubuntu isn't viable, or just that you can't get it in the shops?
Then again, Chrome OS is a Linux-based OS, so Linux fans might have cause to like it - the way that Google took Android, another Linux build, from zero to hero in the smartphone market could be seen as a good sign.
Sundar Pichai, Google's head of product for Chrome, said that "This is a profound shift" and that Chrome is an attempt to "re-think the personal experience for the modern web". He told the BBC: "Chrome is nothing but the web."
But rather than launching the OS, as had been expected, yesterday Google announced a "pilot programme" insisting that Chrome OS is "for people who live in the web" and announcing that everyone who takes part will receive a Cr-48 notebook, a new piece of reference hardware for Chrome OS, and will be expected to tell Google how they progress. (You have to be 18 and based in the US - sorry, UK folks.)
Google has put up an image gallery of the Cr-48 - whose black casing and keyboard make it look exactly like one of Apple's "BlackBook" (black MacBook) models from three years ago, though with barely any connectors - I spot a power lead, USB connector, display connector, but no Ethernet jack.
You can take a quiz to see if you live on the web sufficiently for Chrome: apparently most people (possibly most who have taken the quiz) get a 7.5 out ot 10, but it's very easy to game.
There are some intriguing tweaks to the feature set of the devices: notebooks won't include Caps Lock keys ("We expect this will improve the quality of comments across the web" - good luck with that).
In addition the OS will have "verified boot" - meaning that it on startup it will ensure nothing on the machine or its software has been altered, by comparing hashes for the machine and a reference. If they differ, it could indicate malicious meddling - and at that point Chrome OS will alert the user. The idea is that that will preclude the possibility of viruses or malware infecting programs, or of malicious software being installed on the system without the user's knowledge.
Data residing on the machines will be encrypted by default, at the home directory level. Google says that's for two reasons: so that friends can easily share machines without worrying about whether people can share their data; and to avoid the risk of data loss if you lose the portable device that Chromium runs on. (Of course, that protection will only be as strong as your password.)
This does have its own wrinkles: what if there's a disk error? "If a user authenticates successfully, but all attempts to create or access an encrypted image fail, then login does not fail. Instead, the user receives an empty home directory that uses tmpfs. This means that all the locally stored data will be inaccessible, but it ensures that even though using an encrypted image wasn't possible, no sensitive user data will end up stored on disk."Which means you'll have to download it back from the cloud. But in the US Google is going to partner with Verizon to offer data plans, though it will be a contract-free scheme
Subscribe to:
Posts (Atom)


