Slashdot Mirror

I just figuring that the same thing has happened again, only the victims know what to do next, and will accept this with jaws tightly closed; Lets face it, when China sees Bill Gates before G.W., it is painfully obvious who is really in charge. The same result will be that once folks figure out what Microsoft is doing, the followers will adapt, and adopt. And those who follow the Open Source Solution will wonder what the fuss is all about.

"If you are not the lead dog, the scenery does not change much." - Dog Sledding Observation

can you give a pointer to this?

Officially classed as a WAD (Works As Designed) by RMS and company:

emacs setuid/movemail exploit Officially classed as a WAD by The GNU Foundation.

The Cuckoo's Egg

KFG

And some morons seem to think that this constitutes good software engineering...

The "moron" in question here is Nicholas Lesiecki, author of Java Tools for Extreme Programming: Mastering Open Source Tools Including Ant, JUnit, and Cactus. This review in Dr. Dobb's Journal calls it "original and useful".

He is also a contributor to Cactus, "a simple test framework for unit testing server-side java code", part of the Apache Jakarta project.

He is currently a software engineer and programming instructor with Google.

Looks like the author of this book was quite a fan of Data Munging with Perl. Wonder where he got the idea for this book from :-)

DDJ's reviewer also liked it, making the very good point that Dave Cross's book isn't really about perl.

This is the book which shows the roots of Unix: Lion's Commentary on UNIX 6th Ed. with source code

It's worth mentioning that even Sun comes down hard on AWT/Swing, and shows some of its flaws in their own report, The AWT Focus Subsystem.

Sun even has the guts to plainly state that Windows GUI techs in C++ and VB are improvements over Java options in the following section:

In addition, many developers noted that the APIs for FocusEvent and WindowEvent were insufficient because they did not provide a way for determining the "opposite" Component involved in the focus or activation change...

Since Microsoft Windows provides this functionality for free, developers migrating from Microsoft Windows C/C++ or Visual Basic to Java had been frustrated by the omission. (emph mine)

I believe Windows.Forms in .NET continues the intuitive GUI design Windows developers came to expect in the VB IDEs.

C# certainly took lessons from Java, and now Sun is returning the favor. The above document deals mostly with changes to GUI techs in Java 1.4 and flaws in 1.3 and prior, but this new survey at Sun makes me hopeful that Sun might, indeed, go back to the drawing board.

As Frederick P. Brooks, Jr. said in The Mythical Man-Month , always "Plan to Throw One Away"!

Also, check out the book "Aaron's Code: Meta-Art, Artificial Intelligence and the Work of Harold Cohen" and Dr. Dobbs article.

Having said that...

ttfkam wrote:
Do it in a higher-level language first. Make sure your algorithms are clean and efficient. If and only if you see a performance or resource problem do you rework portions(!!!) in C. As a bonus, the higher level language acts as a code template for faster C development.

Amen.

Kragg wrote (in his reply to ttfkam):
Prototyping in a higher-level language (c# is easy, java everyone knows) is a superb idea, provided you
- can release the final product as interpreted, with slow execution speed

Most programs spend 90% of their CPU time executing 10% of their code. If that 10% is optimized in a low-level language such as C, a large-scale interpreted program can boast performance that's virtually indistinguishable from an equivalent program written entirely in a low-level langauge. However, there's likely to be a huge difference in programmer productivity.

As a reference, see this Dr. Dobbs article, which states:
""" ... 90 percent of the software's running time occurs in only 10 percent of the code. This is the whole basis for virtual memory: Potentially, a program can run at full speed with only 10 percent of itself--or whatever the working set is--loaded into memory at any given time. Unlike that nasty segment stuff, the programmer does not specify any of this in advance. The operating system "discovers" a program's working set on-the-fly, through page faults.
"""

- can afford the time to port all to C, in which case DO, this is an excellent way to make a watertight C program

Why port 90% of the application's code to a low-level and less productive programming language, when that 90% will inevitably evolve and require maintenance as the program is utilized in unforeseen ways? I've never written a large program that didn't end up having features added incrementally over a long period of time after the initial release.

- are happy to learn how to make managed code/vm code call to native and vice-versa (this is far from a trivial problem)

If it's "far from a trivial problem", you're using the wrong tool.

Take Python, for example: it's simple to interface between Python and C using Python's C API. Recently, a tool named Pyrex has appeared that makes it almost trivial. Pyrex is amazing.

Kragg suggested prototyping in C# or Java, but Python surpasses both of those as a prototyping tool. Python is higher-level than C# or Java (and thus better suited to prototyping and/or malleable fusion with C) because it features:
- dynamic typing ("dynamic", not "weak" like Perl)
- no obession with a particular programming paradigm; use procedural, functional, or OO as appropriate
- high-level data structures built into the language
- more convenient dynamic code loading
- interactive development at a "Python prompt" (the value of this cannot be overestimated)
- no separate compilation step in the edit-test-debug cycle
- more concise syntax
- excellent interface capabilities to C (or C++ via Boost.Python, or Java via Jython)

I suggest that the fusion of a truly high-level (higher than Java-level) language with C is far more broadly applicable than Kragg claims.

> Anybody have any good stories of catching elusive hackers, or insights into how they might have got him?

The Cuckoo's Egg by Clifford Stoll is an engaging story of a grad student assigned to track down a 75 cent discrepency in computing resources. He eventually uncovers a ring of crackers working out of Germany for the KGB.

Read a review .

"It is ... a pleasure to review ... books that are both original and useful. The first is Richard Hightower and Nicholas Lesiecki's Java Tools for Extreme Programming, which describes five new Open-Source Java programming tools... Java Tools is readable and well organized... As a bonus, the authors show how to use these tools together; for example, how to automate reexecution of JUnit tests using Ant."

--Gregory V. Wilson

Check out the full review at

http://www.ercb.com/ddj/2002/ddj.0205.html

So this is like elevators using Fuzzy logic?. If you everyday work is in a building where the elevators uses Fuzzy Logic, you really notices when you move to a building where they don't. I would have thought that with the rate mobile masts are getting installed everywhere a technology that the article mentions, would already had be created? Now I have no knowledge about how these networks are controlled, but if there is no automated adjustments I can understand why there are so many "dead spots".

If the future book lends itself to self-publishing, why not?

The most successful self-publisher I know about is Edward Tufte. He has sold hundreds of thousands of copies of his three books. There is an interview in which he tells why and how he self-published.

An excerpt from that interview follows:

It turned out that all self-publishing required was a really good book designer, some money, and a large garage. For capital, I took out another mortgage on my house. This also concentrated my mind, in part because interest rates were 18% at the time. The bank officer said this was the second most unusual loan that she had ever made; first place belonged to a loan to a circus to buy an elephant!

My view on self-publishing was to go all out, to make the best and most elegant and wonderful book possible, without compromise. Otherwise, why do it? If I wanted to mess it up, I could have gone to a real publisher. And I also wanted a reasonable price so that the book would be widely accessible. It all worked out, dreamlike

Hey man, thanks alot, although I am currently a student, I have what I believe to be a diverse view of programming. Having transfered to a few different colleges I've learned that there is no one best language, or OS (although some on this site may argue :)). It looks as though my C++ background is a little less than stellar, and I am going to pick up this book http://www.ercb.com/feature/feature.0050.html. Even though I think I'll end up doing Unix Administration, I still enjoy programming Especially in C/C++... (Perl too :)).

Thanks Again,
Don.

I believe that quote belongs to Tannenbaum.
Its from Computer Networks: Third Edition.

"Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway."

See ERCB: Computer Networks X 2 for more info.

Consider your history. Why are there now two desktop environments for Linux? Well, we have reached this state because of liscensing issues. The Gnome project formed purely because people were unhappy with the KDE qt liscense.

The origin of the projects is no longer important. So if MIT suddenly is given the source code for all the printer drivers in use on their campus, should RMS give up the Free Software Foundation? (click here if that didn't make sense to you)
Why continue to divide out labor on two projects which both hope to achieve the same thing?

Because they plan to do this in completely different ways, also once they are mature the differences willbeself evident.

Imagine how much more polished the Linux desktop environment would be if all effort were focused on just one. Twice as much effort would be expended on it every day.

Anyone who has read Frederick Brooke's Mythical Man Month knows that your statements are a big misconception. Doubling the number of developers on a project does not double the amount of time taken to finish the project because new developers have to be brought up to speed and the layers of communication increase which leads to more errorsoccuring due to miscommunication. Basically there is a certain level of complexity where throwing more developers at a product produces little net gain. KDE and GNOME are at that level of complexity.

KDE is mainly C++, GNOME is mainly C (if you do not realize there is a fundamental difference in these languages then go to comp.lang.c or comp.lang.c++ and state this and see the responses you'll get). GNOME uses all sorts of CORBA stuff while KDE does not. GNOME uses OrBit while the few KDE developers who know CORBA used Mico. Both projects are extremely undocumented and very few, if any, have a complete grasp of the entire system in either case.

Quite frankly,if KDE and GNOME merged the efforts involved in adjusting to the merger would slow down development a lot more than any perceived current lack of developers does. In addition, some functionality that was a part of one or the other system would be lost (because stuff always gets trimmed in a merger).

A better suggestion is for KDE and GNOME to start actively pursing interoperability. Unfortunately this is one place were Open Source may fail. It is unlikely that GNOME interoperability is high on the list of any KDE developer's list of itches he/she wants scratched and vice versa. Thus since they are all simply volunteers they can't be made to do it like would happen in a professional development environment, where a manager can just assign a bunch of coders this task.


Finagle's First Law

Hey, the guy never said it was a GOOD argument! :>)

Actually, this same basic point was made by a writer at Dr. Dobbs who said in his article Python, C++, and Other Religions:

If you want to use all the programming tools that come with a full Linux installation these days, or use a metatool l ike autoconf, you have to master Perl, Python, Tcl, Emacs Lisp, two major flavors of shell, and several slightly different flavors of regular expressions. That is simply too high a price for someone who is already running as fast as she can to stay on th e leading edge of fluid mechanics research. Advocating it is about as sensible as suggesting that online help should be written in whatever mix of English, Esperanto, and Klingon appeals to individual developers, and betrays a self-centeredness that may g o a long way toward explaining why so much of today's software is so hard to use.

So Python it is. If you haven't looked at the language already, it is to Perl or Visual Basic what Java is to C++ (but without any marketing hype).

Curi ous George

From A Second Look at the Cathedral and Bazaar by Nikolai Bezroukov, First Monday, volume 4, number 12 (December 1999) http://firstmonday.org/issues/issue4_12/bezroukov/ index.html

Brooks' Law does not apply to Internet-based distributed development.

"The most common lie is that with which one lies to oneself; lying to others is relatively an exception."
- Fredrich Nietzsche

One of the most indefensible ideas of CatB is that Brooks' Law is non-applicable in the Internet-based distributed development environment as exemplified by Linux. From CatB (Italics in quotes are mine; original italics, if any, are bold italics):

"In The Mythical Man-Month, Fred Brooks observed that programmer time is not fungible; adding developers to a late software project makes it later. He argued that the complexity and communication costs of a project rise with the square of the number of developers, while work done only rises linearly. This claim has since become known as "Brooks's Law" and is widely regarded as a truism. But if Brooks's Law were the whole picture, Linux would be impossible."

This belief that programmer time scales differently as soon as programmers are connected to the Internet and are working on open source projects is repeated elsewhere in a different form:

"Perhaps in the end the open-source culture will triumph not because cooperation is morally right or software "hoarding" is morally wrong (assuming you believe the latter, which neither Linus nor I do), but simply because the closed-source world cannot win an evolutionary arms race with open-source communities that can put orders of magnitude more skilled time into a problem."

First I would like to stress that the famous book The Mythical Man-Month has acquired the status of a classic in the software engineering field. The book is definitely, by several orders of magnitude, more important than CatB; this critique will not harm the book. Many other concepts, phrases and even chapter titles from that famous book have become part of software engineering terminology. I can mention "the second-system effect", "ten pounds in a five-pound sack", "plan to throw one away", "How does a project get to be a year late?...one day at a time". In the early 60s while working as a project manager of Operating System/360 (OS/360), Frederick Brooks observed the diminishing output of multiple developers and that the man-month concept is but a myth. It is as true in 1999 as it was in 1975 when the book was first published.

The real problem with the CatB statement is that due to the popularity of CatB this statement could discourage OSS community from reading and studying The Mythical Man-Month, one of the few computer science books that has remained current decades after its initial publication. Actually the term "Brooks' Law" is usually formulated as "Adding manpower to a late software project makes it later". The term "mythical man-month" (or "mythical man-month concept") is usually used to identify the concept of diminishing output of multiple developers even if all work on a given project from the very start. One of the best explanations of this concept was given by Ray Duncan in his Dr. Dobbs review of The Mythical Man-Month:

"What is a mythical man-month anyway? Consider a moderately complex software application from the early microcomputer era, such as the primordial version of Lotus 1-2-3, Ashton-Tate dBASE, or Wordstar. Assume that such a program might take one very smart, highly-motivated, expert programmer approximately a year to design, code, debug, and document. In other words, 12 man-months. Imagine that market pressures are such that we want to get the program finished in a month, rather than a year. What is the solution? You might say, "get 12 experienced coders, divide up the work, let them all flog away for one month, and the problem will be solved. It's still 12 man-months, right?

Alas, time cannot be warped so easily. Dr. Brooks observed that man-months are not - so to speak - factorable, associative, or commutative. 1 programmer * 12 months does not equal 12 programmers * 1 month. The performance of programming teams, in other words, does not "scale" in a linear fashion any more than the performance of multi-processor computer systems. He found, in fact, that when you throw additional programmers at a project that is late, you are only likely to make it more late. The way to get a project back on schedule is to remove promised-but-not-yet-completed features, rather than multiplying worker bees.

When you stop to think about it, this phenomenon is easy to understand. There is inescapable overhead to yoking up programmers in parallel. The members of the team must "waste time" attending meetings, drafting project plans, exchanging EMAIL, negotiating interfaces, enduring performance reviews, and so on. In any team of more than a few people, at least one member will be dedicated to "supervising" the others, while another member will be devoted to housekeeping functions such as managing builds, updating Gantt charts, and coordinating everyone's calendar. At Microsoft, there's at least one team member that just designs T-shirts for the rest of the team to wear. And as the team grows, there is a combinatorial explosion such that the percentage of effort devoted to communication and administration becomes larger and larger."

Most top-level software professionals are more like artists, in spite of the technical nature of their specialty. It is not a coincidence that another classic book on programming is entitled The Art of Computer Programming. Communication, personality and political problems definitely creep into any project, as any manager of a sizable programming project can attest. These problems certainly drag productivity down.

It's simply naive to assume that for the same team Internet connectivity can improve performance in comparison with, say, LAN connectivity or using the same mainframe. Moreover, if we are assume the same level of developers, geographically compact teams will always have an edge over distributed Internet-connected teams. Open source uses the Internet to connect a geographically distributed pool of talent. In turn, it potentially raises the quality of that pool in the absence of geographical barriers. Reducing the effects of distance does not eliminate other constraints under which such projects operate, but can dramatically increase the quality of the pool of developers. That's the only advantage that I see.

I believe that the illusion of the non-applicability of "mythical man-month postulate" and Brooks' law is limited only to projects for which a fully functional prototype already exists and most or all architectural problems are solved. This may have been the case for Linux, which is essentially an open source re-implementation of Unix. With some reservations, it is probably applicable for all systems for which both the specification (Posix in case of Linux) and reference implementation (say FreeBSD or Solaris) already exist and are available to all developers. As was pointed out in the Halloween-I document:

"The easiest way to get coordinated behavior from a large, semi-organized mob is to point them at a known target. Having the taillights provides concreteness to a fuzzy vision. In such situations, having a taillight to follow is a proxy for having strong central leadership. Of course, once this implicit organizing principle is no longer available (once a project has achieved "parity" with the state-of-the-art), the level of management necessary to push towards new frontiers becomes massive. This is possibly the single most interesting hurdle to face the Linux community now that they've achieved parity with the state of the art in UNIX in any respects."

Some of my favorites:
TabTheTextOutForWimps
WinOldAppHackOMatic

Can you demonstrate without a doubt that all the API's are open? Many other's have demonstrated undisclosed API's (see this link for example). On the other hand, I have not seen a shred of proof that their API's are open as you claim.