I would love to know how Ximian expects its products to integrate MS.net strategy. Will Ximian products integrate with.net? If so, how Ximian is planning to do it? When it is planning to do it?
Because it would end with my argument with my boss
phone rings:
boss: "Where the heck is file youre suposed to send me?"
me (turning off Quake 3 and opening eudora): "im sending it right now, I had to reboot the computer because of a Windows crash and I lost the file... I had to do it again! Dont worry, I just finished it and im sending it right now!!"
"I started making 1,500 now I do more than $12,000 a month WORKING AT HOME"
I guess companies as big as yahoo should at least forbid such banners to be presented on their site... come on, they sould have thousands of companies fighting for banner space at yahoo! But, if yahoo (just as as example) being as big as it is dont stop this stuff in a near future these kind of ads will be everywhere from clothes to food!:))
they'll be extensively used because they're easy to pirate for free.
isnt that what happened to windows? They let people/companies pirate it for free for about 5 years, then when everbody got used to it they paid many anti-piracy campaigns and the government to start seeking people/companies who used that pirated copies... ok ok, youre the owner of a 1000 employees company, are you going to pay the license of use for 1000 windows copies or spending money buying another OS, training all 1000 employees, contracting support, etc, etc, etc???
Xbox is a clever step of MS into home market. PS2 hardware is much much much more powerfull! The problem is: Xbox is easier to program!!
So were already seeing Xbox games taking advantage of most of the box power... it is much harder to develop PS2 games, we can take PS1 as an example, at the very begining almost no games had good graphics cause developers were yet getting used to the new plataform, after they get used to the stuff they released games such as Metal Gear Solid, Grand Turismo, etc which took advantage of the system power...
The same is going on with PS2, were NOW seeing many great games taking advantage of all PS2 power, we have GT3, the new metal gear solid... Xbox has great games but, unfortunatly, they are not as beatiful as PS2 games, just take a look at the specs and youll will see PS2 advantage in some aspects which can make games much more pretty on it. Gamecube is the weaker (graphically speaking) plataform available today, but they are not focused on real-life graphical quality games, they are just focused on games that people will play forever because theyre so good! IMHO a mix of both real graphic and better games is the best, but no system seem capable of that today!
IMHO xbox may not have a so bright future ahead, games quality is not the best, game quantity is not the highest and many Software Houses announced they are not focused on Xbox, thats pretty sad because the more the competition is the better the videogames are going to be in the future!
ps.: you all may find Im Sony fanatic but I dont even have a videogames, I just speak what I read, hear and see from friends and people who understand a lot about this...:))
If a get 1 buck from ever spammer that sends me unwanted messages Im gonna get rich soon!:))
Is there a law in US that obligates spammers to give people money or that makes spam a crime? Here in Brazil we have no such law neither any law that makes spam a crime. I believe obligating these stupid people to pay some money to people they send spam would descrease A LOT the amount of unwanted messages we get everday...
I installed KDE3 on my box right now, I configured it so it would be just like my old kde 2.2, installation ran with no problems at all. First login was no so fast but after I configured it it became little faster than my previous 2.2 instalation. Konqueror is much much much better! Overall performance seems to be much higher, the system looks much smoother and applications like Konqueror seems to be loading a little faster. Its also really pretty. I dont know if anyone realised that memory usage with KDE 3 opened and system idle is much lower... I frequently had like 40% of memory usage with only kde 2.2 opened now im experiencing "only" 18%... dont know if it is my poor system or a normal kde stuff... ok, ill write more when i discovery anything else...
Does the PS2 have enough processor power to run the same EQ that a PC runs?
Well, i have a P3-800mhz, Geforce 2, 192mb RAM and i can barely run the game, i dont know if the PS2 will be able to run it even in a minimized version...
Take me as an example. I run my companys website and sometimes I have to correct some urgent errors at home (i dont like to do that, but i get some extra money)... last weekend I had to download the whole site because of urgent repair I had to make, ok, the site is 470 mb, I had to upload it back 2 hours late!:(( I also run a FTP server at home however its limited to 2 users, but both of them have 256kbps cable connections (just like me) and we change files and CD images frequentely. I also run 2 personal websites, there are some heavy home-made video uploads to them and limiting upload/download bandwith would make me stop maintaining them. Altough I dont believe that there are much users like me out there (excluding/. audience) I believe limiting bandwith is just like limiting our freedom, I choose a service that expensive so I had enough speed and availability to maitain my hobbies/work.
Correct me if Im wrong, but the perspective of Napster going back online is somewhat non-existent. Ok, what are these people buying them? The network? The servers? The old technology? As far as Im concerned the only stuff they might be interested in is the user database, which is kinda old since napster is not used anymore for more than 1 year (im correct?) and this is time enough for most of its newbie users to change e-mail address (thus transforming the database into an whole bunch of useless e-mails and usersnames)...
i refreshed it and it appeared, if anyone finds any problem this is the content:
April 8, 2002 | The office of Meir "Manny" Lehman is a cozy one. Located on the outer edge of the Imperial College of Technology campus in South Kensington, London, it offers room for all the basic amenities: a desk, two chairs, a Macintosh G4 and a telephone. Still, for a computer scientist nearing the end of a circuitous 50-year career, the coziness can be a bit confining.
"You'll have to forgive me," apologizes Lehman at one point, sifting through a pile of research papers on a nearby shelf. "Since I lost my secretary, I can't seem to find anything."
The pile, a collection of recently published papers investigating the topic of software evolution, a topic Lehman helped inaugurate back in the 1970s, is something of a taunting tribute. Written by professional colleagues at other universities, each paper cites Lehman's original 1969 IBM report documenting the evolutionary characteristics of the mainframe operating system, OS/360, or his later 1985 book "Program Evolution: Processes of Software Change," which expands the study to other programs. While the pile's growing size offers proof that Lehman and his ideas are finally catching on, it also documents the growing number of researchers with whom Lehman, a man with dwindling office space and even less in the way of support, must now compete.
"And to think," says Lehman, letting out a dry laugh. "When I first wrote about this topic, nobody took a blind bit of notice."
Software evolution, i.e. the process by which programs change shape, adapt to the marketplace and inherit characteristics from preexisting programs, has become a subject of serious academic study in recent years. Partial thanks for this goes to Lehman and other pioneering researchers. Major thanks, however, goes to the increasing strategic value of software itself. As large-scale programs such as Windows and Solaris expand well into the range of 30 to 50 million lines of code, successful project managers have learned to devote as much time to combing the tangles out of legacy code as to adding new code. Simply put, in a decade that saw the average PC microchip performance increase a hundredfold, software's inability to scale at even linear rates has gone from dirty little secret to industry-wide embarrassment.
"Software has not followed a curve like Moore's Law," says University of Michigan computer scientist John Holland, noting the struggles of most large-scale software programs during a 2000 conference on the future of technology. "In order to make progress here it is not simply a matter of brute force. It is a matter of getting some kind of relevant theory that tells us where to look."
For Lehman, the place to look is within the software development process itself, a system Lehman views as feedback-driven and biased toward increasing complexity. Figure out how to control the various feedback loops -- i.e. market demand, internal debugging and individual developer whim -- and you can stave off crippling over-complexity for longer periods of time. What's more, you might even get a sense of the underlying dynamics driving the system.
Lehman dates his first research on the topic of software evolution back to 1968. That was the year Lehman, then working as a researcher at IBM's Yorktown Heights facility, received an assignment to investigate IBM's internal software development process. Managers at rival Bell Labs had been crowing about per-developer productivity, and IBM managers, feeling competitive, wanted proof that IBM developers were generating just as many lines of code per man-year as their AT&T counterparts.
Lehman looked at the development of OS/360, IBM's flagship operating system at the time. Although the performance audit showed that IBM researchers were churning out code at a steady rate, Lehman found the level of debugging activity per individual software module to be decreasing at an equal rate; in other words, programmers were spending less and less time fixing problems in the code. Unless IBM programmers had suddenly figured out a way to write error-free code -- an unlikely assumption -- Lehman made a dire prediction: OS/360 was heading over a cliff. IBM, in stressing growth over source-code maintenance, would soon be in need of a successor operating system.
Although IBM executives largely ignored the report, Lehman's prediction was soon borne out. By 1971, developers had encountered complexity problems while attempting to install virtual memory into the operating system, problems which eventually forced the company to split the OS/360 code base into two, more easily manageable offshoots. The linear growth curve that seemed so steady in the 1960s suddenly looked like the trail of a test missile spiraling earthward.
Lehman's report would eventually earn a small measure of fame when University of North Carolina professor and former OS/360 project manager Frederick P. Brooks excoriated the IBM approach to software management in his 1975 book "The Mythical Man Month." Using Lehman's observations as a foundation for his own "Brooks Law" tenet -- "adding manpower to a late software project makes it later" -- Brooks argued that all software programs are ultimately doomed to succumb to their own internal inertia.
"Less and less effort is spent on fixing original design flaws; more and more is spent on fixing flaws introduced by earlier fixes," wrote Brooks. "As time passes, the system becomes less and less well-ordered. Sooner or later the fixing ceases to gain any ground. Each forward step is matched by a backward one. Although in principle usable forever, the system has worn out as a base for progress."
By 1975, Lehman, with the help of fellow researcher Laszlo Belady, was well on the way to formulating his own set of laws. A quarter century after their creation, the laws read like a mixture of old developer wisdom and common textbook physics. Take, for example, Lehman's "Second Law" of software evolution, a software reworking of the Second Law of Thermodynamics.
"The entropy of a system increases with time unless specific work is executed to maintain or reduce it."
Such statements put Lehman, who would leave IBM to take a professorship at Imperial College, into uncharted waters as a computer scientist. Halfway between the formalists, old-line academics who saw all programs as mathematical proofs in disguise, and the realists, professional programmers who saw software as a form of intellectual duct tape, Lehman would spend the '70s and '80s arguing for a hybrid point of view: Software development can be predictable if researchers were willing to approach it at a systems level.
"As I like to say, software evolution is the fruit fly of artificial systems evolution," Lehman says. "The things we learn here we can reapply to other studies: weapon systems evolution, growth of cities, that sort of thing."
That Lehman conspicuously leaves out biological systems is just one reason why his profile has slipped over the last decade. At a time when lay authors and fellow researchers feel comfortable invoking the name of Charles Darwin when discussing software technology, Lehman holds back. "The gap between biological evolution and artificial systems evolution is just too enormous to expect to link the two," he says.
Nevertheless, Lehman aspires to the same level of intellectual impact. While he was in retirement during the early 1990s, his early ideas jelled into one big idea: What if somebody were to formulate a central theory of software evolution akin to Darwin's theory of natural selection? In 1993, Lehman took an emeritus position at Imperial College and began work on the FEAST Hypothesis. Short for Feedback, Evolution and Software Technology, FEAST fine-tunes the definition of evolvable software programs, differentiating between "S-type" and "E-type": S-type or specification-based programs and algorithms being built to handle an immutable task, and "E-type" programs being built to handle evolving tasks. Focusing his theory on the larger realm of E-type programs, Lehman has since expanded his original three software laws to eight.
Included within the new set of laws are the Law of Continuing Growth ("The functional capability of E-type systems must be continually increased to maintain user satisfaction over the system lifetime") and the Law of Declining Quality ("The quality of E-type systems will appear to be declining unless they are rigorously adapted, as required, to take into account changes in the operational environment"). For added measure, Lehman has also thrown in the Principle of Software Uncertainty, which states, "The real world outcome of any E-type software execution is inherently uncertain with the precise area of uncertainty also unknowable."
While the new statements still read like glossed-over truisms, Lehman says the goal is to get the universal ideas on paper in the hopes that they might lead researchers to a deeper truth. After all, saying "objects fall down instead of up" was a truism until Sir Isaac Newton explained why.
"Whenever I talk, people start off with blank faces," Lehman admits. "They say, 'But you haven't told us anything we didn't already know.' To that I say, there's nothing to be ashamed of in coming up with the obvious, especially when nobody else is coming up with it."
For extra ammo, Lehman also has expanded the graphs and data from his original studies in the 1970s. Taken together, they show most large software programs growing at an inverse square rate -- think of your typical Moore's Law growth curve rotated 180 degrees -- before succumbing to over-complexity.
Whether the curves serve as anything more than a conversation-starter is still up for debate. Chris Landauer, a computer scientist at the Aerospace Corporation and a fellow guest speaker with Lehman at a February conference on software evolution at the University of Hertfordshire, was impressed by the Lehman pitch.
"He has real data from real projects, and they show real phenomena," Landauer says. "I've seen other sets of numbers, but these guys have something that might actually work."
At the same time, however, Landauer wonders if the explanation for similar growth trajectories across different systems isn't "sociological." In other words, do programmers, by nature, prefer to add new code rather than substitute or repair existing code? Landauer also worries about whether the use of any statistic in an environment as creative as software development leads to automatic red herrings. "I mean, how long does it take a person to come up with a good idea?" Landauer asks. "The answer is we just don't know."
Michael Godfrey, a University of Waterloo scientist, is equally hesitant but still finds the Lehman approach useful. In 2000, Godfrey and a fellow Waterloo researcher, Qiang Tu, released a study showing that several open-source software programs, including the Linux kernel and fetchmail, were growing at geometric rates, breaking the inverse squared barrier constraining most traditionally built programs. Although the discovery validated arguments within the software development community that large system development is best handled in an open-source manner, Godfrey says he is currently looking for ways to refine the quantitative approach to make it more meaningful.
"It's as if you're trying to talk about the architecture of a building by talking about the number of screws and two-by-fours used to build it," he says. "We don't have any idea of what measurement means in terms of software."
Godfrey cites the work of another Waterloo colleague, Rick Holt, as promising. Holt has come up with a browser tool for studying the degree of variation and relationship between separate offshoots of the original body of source code. Dubbed Beagle, the tool is named after the ship upon which Charles Darwin served as a naturalist from 1831 to 1836.
Like Landauer, Godfrey expresses concern that a full theory of software evolution might be too "fuzzy" for most engineering-minded programmers. Still, he credits Lehman for opening the software field to newer, more intriguing lines of inquiry. "It's the gestalt 'Aha' of his work that I find more interesting than the numbers," Godfrey says.
For Lehman, the lack of a scientific foundation to the software-engineering field is all the more reason to keep digging. Fellow researchers can quibble over the value of judging software in terms of total lines of code, but until they come up with better metrics or better theories to explain the data, software engineering will always be one down in the funding and credibility department. A former department head, Lehman recalls the budgetary battles and still chafes over the slights incurred. Now, as he sits in a cramped office, trying to recruit new corporate benefactors and a new research staff, he must deal once again with those who label software development a modern day form of alchemy -- i.e. all experiment but no predictable result.
"In software engineering there is no theory," says Lehman, echoing Holland. "It's all arm flapping and intuition. I believe that a theory of software evolution could eventually translate into a theory of software engineering. Either that or it will come very close. It will lay the foundation for a wider theory of software evolution."
When that day comes, Lehman says, software engineers will finally be able to muscle aside their civil, mechanical and electrical engineering counterparts and take a place at the grown-ups' table. As for getting bigger offices, well, he sees that as a function of showing the large-scale corporations that fund university research how to better control software feedback cycles so their programs stay healthier longer. Until then, the search for a theory has rendered Lehman less of a Darwin and more of an Ahab -- a man in search of both fulfillment and a little revenge.
Once I worked as admin in a company near my home. OS/2 was the OS on the servers and I always thought if was a great product... it almost never crashed (I saw it crashing once and i dont even remember how it was... BSOD?:)))... ok, it was almost a decade ago I really dont remember) we used to compile some unix softwares on it... it was great... our system was a dual-boot of OS/2 and windows NT (i dont even remember de version, one of the first maybe) and OS/2 was hell lot faster! much more reliable (in terms im not even going to mention)! and much, much, much more easy to deal with!
Slashdot Mirror
I would love to know how Ximian expects its products to integrate MS .net strategy. Will Ximian products integrate with .net? If so, how Ximian is planning to do it? When it is planning to do it?
Thanks
Because it would end with my argument with my boss
phone rings:
boss: "Where the heck is file youre suposed to send me?"
me (turning off Quake 3 and opening eudora): "im sending it right now, I had to reboot the computer because of a Windows crash and I lost the file... I had to do it again! Dont worry, I just finished it and im sending it right now!!"
"I started making 1,500 now I do more than $12,000 a month WORKING AT HOME"
:))
I guess companies as big as yahoo should at least forbid such banners to be presented on their site... come on, they sould have thousands of companies fighting for banner space at yahoo! But, if yahoo (just as as example) being as big as it is dont stop this stuff in a near future these kind of ads will be everywhere from clothes to food!
They have time and courage!! :)) we wouldnt put our mobos/cpus inside oil just for the hell of it, would we? :)))
http://www.crazypc.com/articles/watercool.htm
with link now: http://www.overclockers.com/tips653/
HOLY SHIT:
e x.shtml
http://www.eimod.com/overclocking/rob/veg_oil/ind
http://www.overclockers.com/tips653/
http://www.crazypc.com/articles/watercool.htm
:))
I prefer this one!
agreed! :)))
:))
he could have used super-glue instead!
I played Halo and DOA3. As i said you i liked metal gear 2 grphics best...
:)))
well... my computer is better than both anyway!
well, at least the games i played were not so good... metal gear solid 2 was much more beautifull than anything else on Xbox...
they'll be extensively used because they're easy to pirate for free.
isnt that what happened to windows? They let people/companies pirate it for free for about 5 years, then when everbody got used to it they paid many anti-piracy campaigns and the government to start seeking people/companies who used that pirated copies... ok ok, youre the owner of a 1000 employees company, are you going to pay the license of use for 1000 windows copies or spending money buying another OS, training all 1000 employees, contracting support, etc, etc, etc???
"Micros~1 way of winning a competition"
Xbox is a clever step of MS into home market. PS2 hardware is much much much more powerfull! The problem is: Xbox is easier to program!!
:))
So were already seeing Xbox games taking advantage of most of the box power... it is much harder to develop PS2 games, we can take PS1 as an example, at the very begining almost no games had good graphics cause developers were yet getting used to the new plataform, after they get used to the stuff they released games such as Metal Gear Solid, Grand Turismo, etc which took advantage of the system power...
The same is going on with PS2, were NOW seeing many great games taking advantage of all PS2 power, we have GT3, the new metal gear solid... Xbox has great games but, unfortunatly, they are not as beatiful as PS2 games, just take a look at the specs and youll will see PS2 advantage in some aspects which can make games much more pretty on it. Gamecube is the weaker (graphically speaking) plataform available today, but they are not focused on real-life graphical quality games, they are just focused on games that people will play forever because theyre so good! IMHO a mix of both real graphic and better games is the best, but no system seem capable of that today!
IMHO xbox may not have a so bright future ahead, games quality is not the best, game quantity is not the highest and many Software Houses announced they are not focused on Xbox, thats pretty sad because the more the competition is the better the videogames are going to be in the future!
ps.: you all may find Im Sony fanatic but I dont even have a videogames, I just speak what I read, hear and see from friends and people who understand a lot about this...
If a get 1 buck from ever spammer that sends me unwanted messages Im gonna get rich soon! :))
Is there a law in US that obligates spammers to give people money or that makes spam a crime? Here in Brazil we have no such law neither any law that makes spam a crime. I believe obligating these stupid people to pay some money to people they send spam would descrease A LOT the amount of unwanted messages we get everday...
well, i always thought computers were better gaming plataforms now i know why! :))))
I installed KDE3 on my box right now, I configured it so it would be just like my old kde 2.2, installation ran with no problems at all. First login was no so fast but after I configured it it became little faster than my previous 2.2 instalation. Konqueror is much much much better! Overall performance seems to be much higher, the system looks much smoother and applications like Konqueror seems to be loading a little faster. Its also really pretty. I dont know if anyone realised that memory usage with KDE 3 opened and system idle is much lower... I frequently had like 40% of memory usage with only kde 2.2 opened now im experiencing "only" 18%... dont know if it is my poor system or a normal kde stuff... ok, ill write more when i discovery anything else...
Does the PS2 have enough processor power to run the same EQ that a PC runs?
Well, i have a P3-800mhz, Geforce 2, 192mb RAM and i can barely run the game, i dont know if the PS2 will be able to run it even in a minimized version...
am i wrong?
Take me as an example. I run my companys website and sometimes I have to correct some urgent errors at home (i dont like to do that, but i get some extra money)... last weekend I had to download the whole site because of urgent repair I had to make, ok, the site is 470 mb, I had to upload it back 2 hours late! :(( I also run a FTP server at home however its limited to 2 users, but both of them have 256kbps cable connections (just like me) and we change files and CD images frequentely. I also run 2 personal websites, there are some heavy home-made video uploads to them and limiting upload/download bandwith would make me stop maintaining them. Altough I dont believe that there are much users like me out there (excluding /. audience) I believe limiting bandwith is just like limiting our freedom, I choose a service that expensive so I had enough speed and availability to maitain my hobbies/work.
Correct me if Im wrong, but the perspective of Napster going back online is somewhat non-existent. Ok, what are these people buying them? The network? The servers? The old technology? As far as Im concerned the only stuff they might be interested in is the user database, which is kinda old since napster is not used anymore for more than 1 year (im correct?) and this is time enough for most of its newbie users to change e-mail address (thus transforming the database into an whole bunch of useless e-mails and usersnames)...
i refreshed it and it appeared, if anyone finds any problem this is the content:
April 8, 2002 | The office of Meir "Manny" Lehman is a cozy one. Located on the outer edge of the Imperial College of Technology campus in South Kensington, London, it offers room for all the basic amenities: a desk, two chairs, a Macintosh G4 and a telephone. Still, for a computer scientist nearing the end of a circuitous 50-year career, the coziness can be a bit confining.
"You'll have to forgive me," apologizes Lehman at one point, sifting through a pile of research papers on a nearby shelf. "Since I lost my secretary, I can't seem to find anything."
The pile, a collection of recently published papers investigating the topic of software evolution, a topic Lehman helped inaugurate back in the 1970s, is something of a taunting tribute. Written by professional colleagues at other universities, each paper cites Lehman's original 1969 IBM report documenting the evolutionary characteristics of the mainframe operating system, OS/360, or his later 1985 book "Program Evolution: Processes of Software Change," which expands the study to other programs. While the pile's growing size offers proof that Lehman and his ideas are finally catching on, it also documents the growing number of researchers with whom Lehman, a man with dwindling office space and even less in the way of support, must now compete.
"And to think," says Lehman, letting out a dry laugh. "When I first wrote about this topic, nobody took a blind bit of notice."
Software evolution, i.e. the process by which programs change shape, adapt to the marketplace and inherit characteristics from preexisting programs, has become a subject of serious academic study in recent years. Partial thanks for this goes to Lehman and other pioneering researchers. Major thanks, however, goes to the increasing strategic value of software itself. As large-scale programs such as Windows and Solaris expand well into the range of 30 to 50 million lines of code, successful project managers have learned to devote as much time to combing the tangles out of legacy code as to adding new code. Simply put, in a decade that saw the average PC microchip performance increase a hundredfold, software's inability to scale at even linear rates has gone from dirty little secret to industry-wide embarrassment.
"Software has not followed a curve like Moore's Law," says University of Michigan computer scientist John Holland, noting the struggles of most large-scale software programs during a 2000 conference on the future of technology. "In order to make progress here it is not simply a matter of brute force. It is a matter of getting some kind of relevant theory that tells us where to look."
For Lehman, the place to look is within the software development process itself, a system Lehman views as feedback-driven and biased toward increasing complexity. Figure out how to control the various feedback loops -- i.e. market demand, internal debugging and individual developer whim -- and you can stave off crippling over-complexity for longer periods of time. What's more, you might even get a sense of the underlying dynamics driving the system.
Lehman dates his first research on the topic of software evolution back to 1968. That was the year Lehman, then working as a researcher at IBM's Yorktown Heights facility, received an assignment to investigate IBM's internal software development process. Managers at rival Bell Labs had been crowing about per-developer productivity, and IBM managers, feeling competitive, wanted proof that IBM developers were generating just as many lines of code per man-year as their AT&T counterparts.
Lehman looked at the development of OS/360, IBM's flagship operating system at the time. Although the performance audit showed that IBM researchers were churning out code at a steady rate, Lehman found the level of debugging activity per individual software module to be decreasing at an equal rate; in other words, programmers were spending less and less time fixing problems in the code. Unless IBM programmers had suddenly figured out a way to write error-free code -- an unlikely assumption -- Lehman made a dire prediction: OS/360 was heading over a cliff. IBM, in stressing growth over source-code maintenance, would soon be in need of a successor operating system.
Although IBM executives largely ignored the report, Lehman's prediction was soon borne out. By 1971, developers had encountered complexity problems while attempting to install virtual memory into the operating system, problems which eventually forced the company to split the OS/360 code base into two, more easily manageable offshoots. The linear growth curve that seemed so steady in the 1960s suddenly looked like the trail of a test missile spiraling earthward.
Lehman's report would eventually earn a small measure of fame when University of North Carolina professor and former OS/360 project manager Frederick P. Brooks excoriated the IBM approach to software management in his 1975 book "The Mythical Man Month." Using Lehman's observations as a foundation for his own "Brooks Law" tenet -- "adding manpower to a late software project makes it later" -- Brooks argued that all software programs are ultimately doomed to succumb to their own internal inertia.
"Less and less effort is spent on fixing original design flaws; more and more is spent on fixing flaws introduced by earlier fixes," wrote Brooks. "As time passes, the system becomes less and less well-ordered. Sooner or later the fixing ceases to gain any ground. Each forward step is matched by a backward one. Although in principle usable forever, the system has worn out as a base for progress."
By 1975, Lehman, with the help of fellow researcher Laszlo Belady, was well on the way to formulating his own set of laws. A quarter century after their creation, the laws read like a mixture of old developer wisdom and common textbook physics. Take, for example, Lehman's "Second Law" of software evolution, a software reworking of the Second Law of Thermodynamics.
"The entropy of a system increases with time unless specific work is executed to maintain or reduce it."
Such statements put Lehman, who would leave IBM to take a professorship at Imperial College, into uncharted waters as a computer scientist. Halfway between the formalists, old-line academics who saw all programs as mathematical proofs in disguise, and the realists, professional programmers who saw software as a form of intellectual duct tape, Lehman would spend the '70s and '80s arguing for a hybrid point of view: Software development can be predictable if researchers were willing to approach it at a systems level.
"As I like to say, software evolution is the fruit fly of artificial systems evolution," Lehman says. "The things we learn here we can reapply to other studies: weapon systems evolution, growth of cities, that sort of thing."
That Lehman conspicuously leaves out biological systems is just one reason why his profile has slipped over the last decade. At a time when lay authors and fellow researchers feel comfortable invoking the name of Charles Darwin when discussing software technology, Lehman holds back. "The gap between biological evolution and artificial systems evolution is just too enormous to expect to link the two," he says.
Nevertheless, Lehman aspires to the same level of intellectual impact. While he was in retirement during the early 1990s, his early ideas jelled into one big idea: What if somebody were to formulate a central theory of software evolution akin to Darwin's theory of natural selection? In 1993, Lehman took an emeritus position at Imperial College and began work on the FEAST Hypothesis. Short for Feedback, Evolution and Software Technology, FEAST fine-tunes the definition of evolvable software programs, differentiating between "S-type" and "E-type": S-type or specification-based programs and algorithms being built to handle an immutable task, and "E-type" programs being built to handle evolving tasks. Focusing his theory on the larger realm of E-type programs, Lehman has since expanded his original three software laws to eight.
Included within the new set of laws are the Law of Continuing Growth ("The functional capability of E-type systems must be continually increased to maintain user satisfaction over the system lifetime") and the Law of Declining Quality ("The quality of E-type systems will appear to be declining unless they are rigorously adapted, as required, to take into account changes in the operational environment"). For added measure, Lehman has also thrown in the Principle of Software Uncertainty, which states, "The real world outcome of any E-type software execution is inherently uncertain with the precise area of uncertainty also unknowable."
While the new statements still read like glossed-over truisms, Lehman says the goal is to get the universal ideas on paper in the hopes that they might lead researchers to a deeper truth. After all, saying "objects fall down instead of up" was a truism until Sir Isaac Newton explained why.
"Whenever I talk, people start off with blank faces," Lehman admits. "They say, 'But you haven't told us anything we didn't already know.' To that I say, there's nothing to be ashamed of in coming up with the obvious, especially when nobody else is coming up with it."
For extra ammo, Lehman also has expanded the graphs and data from his original studies in the 1970s. Taken together, they show most large software programs growing at an inverse square rate -- think of your typical Moore's Law growth curve rotated 180 degrees -- before succumbing to over-complexity.
Whether the curves serve as anything more than a conversation-starter is still up for debate. Chris Landauer, a computer scientist at the Aerospace Corporation and a fellow guest speaker with Lehman at a February conference on software evolution at the University of Hertfordshire, was impressed by the Lehman pitch.
"He has real data from real projects, and they show real phenomena," Landauer says. "I've seen other sets of numbers, but these guys have something that might actually work."
At the same time, however, Landauer wonders if the explanation for similar growth trajectories across different systems isn't "sociological." In other words, do programmers, by nature, prefer to add new code rather than substitute or repair existing code? Landauer also worries about whether the use of any statistic in an environment as creative as software development leads to automatic red herrings. "I mean, how long does it take a person to come up with a good idea?" Landauer asks. "The answer is we just don't know."
Michael Godfrey, a University of Waterloo scientist, is equally hesitant but still finds the Lehman approach useful. In 2000, Godfrey and a fellow Waterloo researcher, Qiang Tu, released a study showing that several open-source software programs, including the Linux kernel and fetchmail, were growing at geometric rates, breaking the inverse squared barrier constraining most traditionally built programs. Although the discovery validated arguments within the software development community that large system development is best handled in an open-source manner, Godfrey says he is currently looking for ways to refine the quantitative approach to make it more meaningful.
"It's as if you're trying to talk about the architecture of a building by talking about the number of screws and two-by-fours used to build it," he says. "We don't have any idea of what measurement means in terms of software."
Godfrey cites the work of another Waterloo colleague, Rick Holt, as promising. Holt has come up with a browser tool for studying the degree of variation and relationship between separate offshoots of the original body of source code. Dubbed Beagle, the tool is named after the ship upon which Charles Darwin served as a naturalist from 1831 to 1836.
Like Landauer, Godfrey expresses concern that a full theory of software evolution might be too "fuzzy" for most engineering-minded programmers. Still, he credits Lehman for opening the software field to newer, more intriguing lines of inquiry. "It's the gestalt 'Aha' of his work that I find more interesting than the numbers," Godfrey says.
For Lehman, the lack of a scientific foundation to the software-engineering field is all the more reason to keep digging. Fellow researchers can quibble over the value of judging software in terms of total lines of code, but until they come up with better metrics or better theories to explain the data, software engineering will always be one down in the funding and credibility department. A former department head, Lehman recalls the budgetary battles and still chafes over the slights incurred. Now, as he sits in a cramped office, trying to recruit new corporate benefactors and a new research staff, he must deal once again with those who label software development a modern day form of alchemy -- i.e. all experiment but no predictable result.
"In software engineering there is no theory," says Lehman, echoing Holland. "It's all arm flapping and intuition. I believe that a theory of software evolution could eventually translate into a theory of software engineering. Either that or it will come very close. It will lay the foundation for a wider theory of software evolution."
When that day comes, Lehman says, software engineers will finally be able to muscle aside their civil, mechanical and electrical engineering counterparts and take a place at the grown-ups' table. As for getting bigger offices, well, he sees that as a function of showing the large-scale corporations that fund university research how to better control software feedback cycles so their programs stay healthier longer. Until then, the search for a theory has rendered Lehman less of a Darwin and more of an Ahab -- a man in search of both fulfillment and a little revenge.
the site is slashdoted already... does anyone have a mirror?
Once I worked as admin in a company near my home. OS/2 was the OS on the servers and I always thought if was a great product... it almost never crashed (I saw it crashing once and i dont even remember how it was... BSOD? :)))... ok, it was almost a decade ago I really dont remember) we used to compile some unix softwares on it... it was great... our system was a dual-boot of OS/2 and windows NT (i dont even remember de version, one of the first maybe) and OS/2 was hell lot faster! much more reliable (in terms im not even going to mention)! and much, much, much more easy to deal with!
:)))
great product!
DOS is not dead at all! Microsoft released a brand new version called Windows XP... thou they claim DOS is not used there anymore... :))))
:))
sorry... had to say it!
hahhahah! :)) do you have any of those extra not used memories there to sell me? :))