Linux kernel developer’s guide published

The Linux Foundation has released a guide for developers who wish to contribute Linux code.

A guide to the kernel development process aims to encourage participation by new programmers by explaining what’s involved. Some developers and businesses attempting to submit changes to the Linux kernel find themselves tangled up with the processes used, according to the guide, which was written by Jonathan Corbet, executive editor of lwn.net and himself a Linux developer.

“A developer who does not understand the kernel community’s ways (or, worse, who tries to flout or circumvent them) will have a frustrating experience in store,” Corbet warned.

One major stumbling block is coders not taking into account the development lifecycle. According to the guide, patches deemed stable are “merged” into the mainline kernel at the beginning of the lifecycle, every two to three months.

The “merge window” lasts for two weeks, and is then closed. After that time, project lead Linus Torvalds issues a release candidate kernel, which is then stabilised. Developers who try to merge new features outside the merge window “tend to get an unfriendly reception”, wrote Corbet, as usually only release-candidate fixes are accepted.

Dissatisfaction also arises from confusion over how patches are reviewed before being merged, according to the guide.

“Much developer frustration comes from a lack of understanding of this process or from attempts to circumvent it,” wrote Corbet, who added that patches go through a series of reviews before and after they are accepted into the kernel.

At the moment, there are more than 1,000 developers at more than 100 companies making contributions to the kernel, according to the Linux Foundation. The not-for-profit organisation said the 30-page guide is central to its efforts to expand this community.

Mark Taylor, president of the Open Source Consortium, said that while it isn’t that difficult to contribute to open-source projects, to avoid disappointment there are processes that must be adhered to.

“The bigger and more important the project, the more likely it is to have a number of levels,” Taylor told ZDnet.co.uk on Friday. “Enterprise-class projects, including the Linux kernel, have more processes, but that shows how seriously they take the project. It’s less difficult to get code into a project if you understand the rules.”

Taylor added that it was “a misconception that open-source projects are total anarchy”, and that enterprise-class projects, including Linux, often have a “beneficent dictator”.

“It’s not chaos – they have rules,” said Taylor. “They have a beneficent dictator. Linus in the Linux kernel has lieutenants around him, [as does] Jeremy Allison at Samba.”
Guide: http://ldn.linuxfoundation.org/how-participate-linux-community

Torvalds: No picnic to become major Linux coder

Linux project lead Linus Torvalds has said it is not easy to become a major contributor to the Linux kernel.

In an email interview with ZDNet.co.uk on Friday, Torvalds said that, while it is relatively easy for coders and organisations to contribute small patches, the contribution of large patches, developed in isolation, could lead to both new and established contributors becoming frustrated.

“It’s definitely not easy to become a ‘big contributor’,” wrote Torvalds. “For one thing, the kernel is quite complex and big, and it inevitably simply takes time to learn all the rules — not just for the code, but for how the whole development environment works. Similarly, for a new developer, it will take time before people start recognising the name and start trusting the developer to do the right things.”

However, Torvalds argued that Linux kernel processes do make it easy to contribute small patches.

“[We] make it fairly easy for people to ease into kernel development,” wrote Torvalds. “It seems to be working too. We literally have thousands of people with patches attributed to them in each release.”

Torvalds wrote that nobody should expect to start sending “big and complex” patches early, as it takes time for new contributors and established coders to learn how to interact effectively.

“The worst thing anybody can do is to study the kernel alone and try to learn things in private, and then, however many months later, present all the established kernel developers with a big patch that just comes out of the blue,” wrote Torvalds. “That’s just going to be frustrating for everybody.”

Torvalds advised new contributors to “start small” by sending “trivial patches”.

“It may not sound exciting but, quite frankly, I don’t think anybody who starts out believing that they want to rewrite some big piece of the kernel should even bother. Reality isn’t that simple.”

Torvalds admitted that frustrated developers may become alienated by the Linux development process, which he said could be improved.

“I don’t think a ‘perfect’ process exists,” wrote Torvalds. “Of  course, some people will be alienated, and there’s no doubt that the process could probably be improved.”

The developer warned that Linux kernel development was “not a ‘warm and fuzzy’ environment where people sing Kumbaya around the fireplace” and that some “very opinionated people” were involved.

“The kernel is about pretty harsh technical issues, and mistakes are really frowned upon,” wrote Torvalds. “In an OS kernel, there are simply more security and stability requirements, and the bar is really higher in some respects. That will inevitably also reflect in the response to patches.”

Nonetheless, Torvalds said the patching process in Linux was more about human interaction than a quantifiable set of steps, such as those listed in official international standards processes.

Although thousands of developers are involved in Linux kernel coding, Torvalds argued that the development process was still efficient. “I think that one of the things we’ve been very good at is to scale up with a good network of maintainers, so that most people involved actually don’t work closely with more than a handful of people,” he wrote.

Mark Taylor, president of the Open Source Consortium, told ZDNet.co.uk on Friday that, in general, enterprise-class open-source projects are designed to scale appropriately.

“The whole process scales very well,” said Taylor. “Normally the people you find at the core [of open-source projects] are professional software engineers; these guys know how to run software projects.”

Torvalds’ and Taylor’s comments follow the publication of a guide to Linux kernel development by the Linux Foundation, which aims to prevent developers becoming frustrated with the process. The guide was made available on Wednesday.

Guide: http://ldn.linuxfoundation.org/how-participate-linux-community

regmon

regmon and filemon are the two important tools used in malware analysis.

any malware, when it first infects the Windoze box, it infects the registry. the reason behind this is to make sure that the malware runs every time windoze boots up and to disable other security settings of windoze / av’s.

regmon tool basically monitors any access to the registry. there are about 14 – 16 routines in the windoze kernel (also called virtual machine manager) which deals with all i/o operations on registry. the technique is like the old TSR and IVT hooking one, where regmon hooks into these chain and anything accessing these routines will pass through regmon as well.

during DOS days all viruses will try to hook themselves into interrupt vector table and put themselves in TSR mode. the same applies in windoze with some fancy names. regmon’s heart is the regvxd.vxd code. this inserts or hooks itself into those 16 routines. regvxd.vxd is a Virtual Device Driver.

so before loading the malware, take a snapshot of the registry using regmon. then load the malware into the sandbox or the VM system and run the regmon. regmon clearly shows what all the key / values got changed ..

more coming …

get regmon from here http://technet.microsoft.com/en-us/sysinternals/bb896652.aspx

from the oneha|f Lab
(oneh.wordpress.com)

more about oneha|f

come and join, if you are a person interested in malware research, love systems programming, hit your head in asm instructions, and what so ever related to depth of systems programming …

 

malware research is an interesting area … we will learn about extreme programming concepts, nice techniques, and depth about computer networks and computer itself …

 

the main reason to create this group is to unite people in this arena … please no spammers, no script kiddies, no junkies … you can only join through people who are already in the group …

 

the group is highly moderated … the reason is … we don’t want to allow some one to come and sniff our messages, ask for tutorials, look for exploit codes … please don’t bug us .. we are already busy ! …

 

 

you can reach this group at http://groups.google.com/group/onehalf

 

and the web blog is at http://oneh.wordpress.com

malware research group

I have opened a new group called ” oneha|f “

a place for people to do malware research, malware code analysis, behaviour analysis, discuss about defending malwares, incident response and much more …

focus will be more on code analysis, reverse engineering, assembly, worm techniques and what not …

Independence day

happy Independence day

my favourite dos error messages

want to recollect all the error messages I used to get while working on DoS… it was very funny, that every time I get error messages, I had book called MS-DOS internals, which i used to refer … It was hard for me to understand these much as I was only 14 years old … but soon I remembered everything and ways to handle those …

Bad command or file name

General failure reading drive X

Abort, Retry, Fail?

Non-system disk or disk error

Replace and press any key when ready

Write protect error

Access denied 

Incorrect DOS Version

Duplicate file name or file not found

Not ready reading drive X

Abort, Retry, Fail?

Not ready writing device PRN

Abort, Retry, Fail?

my favourite DOS programs

I was thinking what all the Dos programs I have used … it was hard to recollect, since I used all these some 10 years back !

 

 

So here goes the list …..

 

OS

 

MS DoS version 4.01  - 6.22 -> offcourse it has to be

 

 

 

Major softwares

 

Wordstar 4, 5 and 7 -> don’t know why I missed 6

dBase III plus

Lotus 1-2-3 -> not able to recollect the version

 

 

Utilities

 

pkzip and pkunzip -> ohhh those days

PCTools

Norton Disk Doctor

 

 

Programming Languages

 

Turbo Basic

GWBasic

Turbo C

Turbo Pascal

 

Games

 

Prince of Persia -> it took 5 months for me to complete .. no idea about cheat codes

Paratrooper

DAVE

Digger

Cat

Bricks

 

 

ooops … and many I can remember … will try to update …..

Latest antivirus test results from Andreas Marx

As always, good stuff from Andreas Marx of Av-Test.org

 

We have just finished a new comparison test of AV software. All products (in the “best” available Security Suite edition) were last updated on January 7, 2008 and tested on Windows XP SP2 (English).

 

First, we checked the signature-based on-demand detection of all products against more than 1 Mio. samples we’ve found spreading or which were distributed during the last six months (this means, we have not used any “historic” samples.) We included all malware categories in the test: Trojan Horses, backdoors, bots, worm and viruses. Instead of just presenting the results, we have ranked the product this time, from “very good” (++) if the scanner detected more than 98% of the samples to “poor” (–) when less than 85% of the malware was detected.

 

Secondly, we checked the number of false positives of the products have generated during a scan of 65,000 known clean files. Only products with no false positives received a “very good” (++) rating.

 

In case of the proactive detection category, we have not only focussed on signature- and heuristic-based proactive detection only (based on a retrospective test approach with a one week old scanner).

 

Instead of this, we also checked the quality of the included behavior based guard (e.g. Deepguard in case of F-Secure and TruPrevent in case of Panda). We used 3,500 samples for the retrospective test as well as 20 active samples for the test of the “Dynamic Detection” (and blocking) of malware.

 

Furthermore, we checked how long AV companies usually need to react in case of new, widespread malware (read: outbreaks), based on 55 different samples from the entire year 2007. “Very good” (++) AV product developers should be able to react within less than two hours.

 

Another interesting test was the detection of active rootkit samples. While it’s trivial for a scanner to detect inactive rootkits using a signature, it can be really tricky to detect this nasty malware when they are active and hidden. We checked the scanner’s detection against 12 active rootkits.

 

Having such a multi-faceted test methodology is important — an antivirus engine could, for example, have extraordinarily high detection, but high false positives. And, a retrospective test allows you to see how well an antivirus’ heuristics work. It’s good to look at all the parameters in order to judge efficacy.

 

I’ve put the test results into PDF. You can see the main results here and the details of the test of signature detection here.

 

Results:

 

http://www.sunbelt-software.com/ihs/alex/avtestresults_2D2008q1.pdf

http://www.sunbelt-software.com/ihs/alex/avtestsigresults_2D2008q1.pdf

Steve Wozniak

Q From e-mail:
Mr. Wozniak, Like your other e-fans, I am a great admirer of your work. Just doing what you did at the time that you were able to do it is an incredible feat. I was left with a big question after seeing the TNT movie, and reading more about the creation of Apple. HP had rights to anything you developed, yet the naively passed on your concept. Why did they pass, and did they actually have to sign legal rights to you to develop your product? Also, this may sound odd, but I collect autographs and I was wondering if you have an address or P.O. Box that I could send a self addressed stamped envelope to and possibly request your autograph? Thanks alot for taking the time to respond to your fans.

WOZ:
I’d just designed and built the computer that was to become the Apple I for fun. I enjoyed my computer club, I liked designing, and I liked showing others how much you could do with so little. When Steve suggested forming a company, it wasn’t a matter of Hewlett Packard having a stake in my work. That came later. With the Apple I, I first WANTED Hewlett Packard to make it. I totally loved that company. I had a lot of incredible friends there and I loved the atmosphere and the history of the company and I loved their products too.

So I met with the lab manager, Miles Judd, and my Section Leader and my Group Leader and maybe more. I laid out how inexpensive it was to build a machine for regular people that could be programmed in BASIC. Miles was not at all like the actor in “Pirates.” He was very intrigued by this idea. He had been high up in the Hewlett Packard lab in Colorado Springs, out of which had come several desktop scientific calculators, the forerunners of my own lab’s handheld calculaters. He knew that a desktop machine running BASIC for $800 was a super idea. He had to RELUCTANTLY turn down the project at that time because of problems with Hewlett Packard getting into something on the ground floor. They weren’t at all the sort of company that could risk outside pieces ruining their reputition and making customer support difficult. The outside component would be the user’s home TV. Also, he didn’t have the resources, the bodies. But he was intrigued and would stop me for months thereafter to tell me that he hadn’t been able to sleep after hearing the idea.

So Steve and I formed the partnership to sell PC boards for $40 when they’d cost us $20. I thought we’d lose fail to sell 50 of these and lose some of our investment but Steve said at least we’d have a company. Who could turn that down.

I didn’t leave Hewlett Packard. After we made a PC board, my direct boss said that I should contact HP’s legal department. I did so, they questioned all the HP divisions about interest in an $800 BASIC computer, and gave me a letter to the effect of no interest.

After some time, our own HP lab started a small computer project. Not the fun, open computer that the Apple I was. This HP project had a keyboard, a small monitor, a microprocessor, dynamic RAM, printer interfaces, a built-in tape drive, and even a BASIC language. 5 people alone were to work on the BASIC. I’d just done all these thing singlehanded for the Apple I. So I went to the new lab manager and asked to be transfered to that project. I told him that my first love was computers and I was tired of working on calculators. I said I’d do any small engineering job available. But I got turned down.

With the Apple II, Mike Markkula was willing to put in $250,000. That’s worth a lot more of today’s dollars. It seemed like a big deal. But I still LOVED Hewlett Packard. I had a good engineering job in a good engineering company and I had security for life. I didn’t have pressure to leave engineering for management there. I designed computers like the Apple I and the Apple ][ on my own time for fun. I could always do that. My whole life would be good staying at HP.

Actually, I was afraid that with my lack of interpersonal skills and with my 'softness' I would be devoured by the wolves in any role but engineering. I was afraid that if we started this company, I'd be kicked out as soon as it started with my invention, and that maybe I'd lose my stock. So I told Mike and Steve Jobs that I wouldn't start Apple as a real company. Steve got my friends and relatives to call me and try to talk me into it. But I didn't budge. Then my friend Allen Baum called. Allen was my only computer friend in high school and college. He had introduced me to HP in the first place. He also worked at HP. Allen is the only other person that did any computer design of the Apple ][, helping code the monitor program.

Allen said that I could start Apple and go into management and get rich. Or that I could starte Apple and stay an engineer and get rich. This was the first time I’d heard anyone suggest that you COULD start a company and stay an engineer and keep designing in a lab. That was what I needed, and I left HP that day or the next. I first told one friend I was leaving, then another. But I couldn’t find my boss. People kept coming up to me all day saying that they’d heard that I was leaving. I was afraid my boss would hear it elsewhere before he heard it from me. HP was very gracious and I was able to leave that day, telling them what I was leaving to try.