Slashdot Mirror

The flag icon for Slashdot's 'United States' section is missing its first stripe - the stripe that represents Delaware, the first state admitted to the Union. While a simple oversight could be forgiven, it should be known from here on out that Slashdot is in fact aware of the missing stripe, and even worse, refuses to do anything about it!

This vulgar flag desecration and rabid anti-Delawarism must be put to a stop. Let the Slashdot crew know that we will not accept a knowingly mutilated flag or the insinuation that Delawarians deserve to be cut out of the union. I ask you, what has Delaware done to deserve this insolence, this wanton disregard, this bigotry?

This intentional disregard of a vital national symbol is unpatriotic. Why, the flippant remarks CmdrTaco made about our flag border on terrorism! I urge you to join the protest in each 'United States' story. Sacrifice your karma for your country by pointing out this injustice. Let's all work together to get our flag back. Can you give your country any less?

The Stanford Checker is great. I was blown away when I read their papers last year. Their checker is not released yet, so I wrote a similar checker (smatch.sf.net) based on their publications.

The poster mentions Lint, but I did not have any success using Lint on the kernel sources. The source is too unusual.

Also Lint does not look for application specific bugs. For example, in the Linux kernel you are not supposed to call copy_to_user() with spinlocks held. It took me about 10 minutes to modify one my existing scripts to check for that in the Linux kernel last Monday. It found 16 errors. (It should have found more but I was being lazy.)

A lot of the time, you can't tell what will be a common error until you try looking for it. One funny thing was that there were many places where people had code after a return statement. On the other hand, I didn't find even one place where '=' and '==' were backwards.

It's fascinating stuff playing around with this stuff. I have been learning a lot about the kernel through playing around with Smatch.

We submitted an OpenEXR plugin to the Film Gimp team, and I understand it'll show up in the next release.

Also, Idruna Software is working on OpenEXR support for their Photogenics package. It already supports creation of and painting on HDR formats.

I have been using Qt for the last 1.5 years to develop an application for post-processing of segmented (medical) image data as part of my master thesis. The application is available under the GPL at sourceforge

During development one major disadvantage of Qt has surfaced, and I think it shows that the Trolltech has choosen a terribly wrong solution to a complex problem.

In order to support their signals-and-slots mechanism (which is an elegant concept, and allows for easy implementation of both the model-observer pattern and the mediator pattern) they have added two new keywords to the language, namely signals and slots. In order to support these you _HAVE_ to run a preprocessor called moc (Meta Object Compiler) for your program to link. But moc does not support templates.

Mostly we have managed to work around this limitation by having a non-template superclass which declares the signals and slots (luckily slots can be virtual) and then have the template parts in a subclass, but this leads to unnatural class hierarchies.

Other libraries have managed to support a signals-and-slots mechanism without such an ugly hack. Both Boost.signals and libsic++ implement them. However their syntax is not as nice as Qt's. If C++ really need even more syntax is of course another question :-)

While not all applications rely upon templates, they have some interesting uses, and if an applications first starts to use them, most classes easily ends up as template classes. See the book Modern C++ Design for "new-school" uses of templates. This could easily be the direction C++ development is headed, and it's a shame Qt will not be able to be a part of it.

Specifically, Mono is working on Gtk#, which provides .NET bindings for Gtk+. Gtk# This effectively provides an elegant OO interface to Gtk+. There's also work being done to make Gtk+ fit into the Windows environment, using native Windows and Windows XP widgets.

With Mono, it's already possible to run the same binary on Windows, FreeBSD and Linux on multiple architectures (x86 and ppc are well-supported now, with others in the pipeline). Mono seems to slowly be achieving the write-once-run-anywhere mantra that Java never succeeded with on the desktop.

• http://use.perl.org/~babbage/journal/10069:

  Chrysflame posted detailed minutes for the proceedings, as pasted from Oliver Schmelzle's TechBlog.Readers may find it useful to cross-check my notes against his times when looking for talks they would like to listen to.

  Matt Sergeant politely replied as well, noting that the impressive claims about CRM114's accuracy were yet to be thoroughly tested, that in other tests CRM114 had not been significantly more accurate than other Bayesian strategies, and that the current performance of CRM114 is so much slower than many of the alternatives that any gains it may have to offer are more than offset by the low volume it can currently handle. Grain of salt taken :)

• http://slashdot.org/~babbage/journal/21771/:

  No comments as of this writing.

• http://slashdot.org/comments.pl?sid=51208&cid=5112 383:

  An anonymous coward added a couple of corrections which are worth noting:

  • Jon Praed was questioning IP spoofing, not message header spoofing. It is relatively easy to fake at least some of the headers on an email, but when tracked down & brought before a judge, no spammer has ever been able to explain a credible technique for spoofing IP data in any trial Praed was aware of. When this comment was made to the audience, ESR spoke up saying that he could show Praed how to do it, but I don't know what if anything came of any conversation they had after the talk.

  • The AC also expanded on Michael Salib's talk & how much mileage Salib was seeing out of a comically non-buzzword compliant filtering strategy, but came back to the point that his results were "probably unrepeatable and it would probably be best if we all just treated them as outright lies." As the AC noted, Salib seems to have played a big role in organizing the conference -- I think I read somewhere that when the attendee list swelled to 500+ people, he helped to find a last minute venue big enough to accomodate everyone. So not only do we have to thank Salib for an entertaining spiel of quackery, but also for bringing everyone together in the first place. :)

  I never said my notes were perfect :)

• Emails sent to me directly:
  • Brad Spencer wrote to me asking if anyone had mentioned relay spam honeypots, citing http://jackpot.uk.net/ as an example, and claiming that they are "100% accurate and can be devastating.". Respectfully Brad, I'm not sure that the speakers gathered together last week would agree that any approach is "100% accurate" unless you have a very generous definition of "accurate" (as in, "delete everything as spam" is 100% accurate, but 100% useless :). More fairly though, Brad claims that "if you deal with spam at the relay level you can be dumb -- it is the spammers who are forced to be smart. If they make an incremental move towards being smart you move beyond them." I won't argue with that, it sounds like a fine idea. I suggest taking ideas like this to Barry Shein et al, who would probably love to discuss these ideas & implement anything that works well.

    In his email, Spencer went on to expand on the value of honeypots, and how they seem like a very promising tactic for handling the spam problem. I agree, and maybe my writeup didn't give this enough attention, but I think many or all of the conference speakers would have agreed as well. Ken Schneider made it clear that Brightmail in particular seems to make heavy use of honeypot addresses: it sounded like when they set up service for an organization, they plant one or more dummy addresses at that organization as data points for spam collection efforts, and have mechanisms in place to gather & analyze this data in real time. Spencer suggests that honeypot addresses would be very hard for spammers to detect if they resemble legit MTAs as much as possible, and I have the impression that this is exactly what Brightmail is doing. I'm sure that others are using tactics like this as well, but Schneider was the most vocal user of the tactic that I noticed.

  • John Hanna wrote to me saying that he runs an anti-spam project at http://assp.sf.net, and noticed a surge in traffic after the conference. To answer John's question, I did not notice anyone mentioning ASSP [caps?] during any of the talks, but it could well be that people were discussing it amongst themselves off stage. *shrug*

  • Ashley Pomeroy wrote to a mailing list where I posted my notes, asking:It may have been raised before, but does the specific use of 'ham' to mean 'good' and 'spam' to mean 'bad' leave all these good people open to abuse from the people who make Spam, the nutritious meat-based food?

    I assume that Spam(r) is cool about the use of the term 'spam' to mean junk e-mail, but adding a converse makes it explicitly clear that 'spam=bad'.

    And what do the pigs think about all this? Its their flesh we're talking about. The ultimate expression of love is to consume the flesh of another being; we are sending out a mixed message as to whether we love pigs or not, which will surely effect the quality of the eggs they lay.

    By this token eating one's fingernails/bogies/earwax is a form of self-love, which is perfectly natural.

    To which I have no comment :)

If I get any other material relevant to the conference, I may add it to the Slashdot or use.perl journals, but in any case I wanted to get this up while the pages are still getting traffic, so readers of one variation of the page are not missing out on what may be added to other variations. Thanks all for the feedback! :)

Tiki (http://tikiwki.sf.net/) has an extremely flexible permissions system, the most flexible that I've found and I've tested most of the open-source content management systems out there. Tiki also has a shipload of cool features - image galleries, file galleries, weblogs, wiki, etc, etc.

Quoting from Tim Peters (the real TimBot, but I digress <wink>) spambayes has a more effective classifier:

We have three
categories: Ham, Unsure, and Spam, and I haven't seen anything to make me
believe that a finer distinction than that can be quantitatively justified
(but my primary test data makes 2 mistakes out of 34,000 msgs now -- that's
what I mean by "can't measure an improvement anymore", and a finer-grained
scheme isn't going to touch those 2 mistakes; one of them is formally ham
because it was sent by a real person, but consists of a one-line comment
followed by a quote of an entire Nigerian scam spam -- nothing useful is
ever going to *call* that one ham, and it scores as spam *almost* as solidly
as an original Nigerian spam).

It is a statistical filter, and you do need to train it with your personal collection of spam and ham. However, most of the work in the last month or two on the spambayes list has revolved around building user interfaces, and finding appropriate places to inject the filter into your mail processing, not on improving the classifier.

"Spambayes. Try it. You'll like it!" (But be warned, it's still pre-alpha...)

While they started out with the bayesian algorithm described by Paul Graham they quickly discovered that the effectiveness of his algorithm tends to depend on the values of some quite sensitive tuning parameters and that diffrent people can get wildly differing degrees of success depending on their configuration and the types of spam/ham that they receive. Gary Robinson wrote an interesting critique of Paul's algorithm and helped the spambayes team incorporate his so-called chi-squared combining scheme (which apparently isn't bayesian at all) which doesn't seem to depend so much on 'magic' numbers and their testing framework showed that it works surprisingly well for both small and large sets of messages.

It's still under active development although most of the ongoing work is centered around the user interface components (POP proxies, Outlook plugins, etc...) whereas the actual spam classifier hasn't changed much in a while.

Well worth looking into if you're getting too much spam. Who isn't?

I think SVG is the technology for the future.
Already open source project such as sodipodi is using SVG to store vector graphic format.

Here are some more information about SVG and comparsion with SWF:

Mozilla SVG Project
Comparing .SWF (Shockwave Flash) and .SVG (Scalable Vector Graphics) file format specifications
Flash and SVG

I thought for sure, with as much spam as you get, you'd be the first one to try out the bayesian mail filters that Paul Graham wrote about. One of the ones he suggested was CRM114 With a reputed catch rate of 99.8%, do you really not want to try it that much?

FWIW, FLTK provides the same advantages as Qt but is provided under the LGPL and is a lot smaller and faster.

The 2.0 release (currently in development) will take us beyond what most of the current toolkits can do, and is the basis of the Equinox Desktop Environment. At the same time, 2.0 retains the same goal of small size, high speed, and portability/cross-platform programming.

I wonder if the Scrolling Game Development Kit will ever make it on to one of these CDs. Do they regularly scour SourceForge for highly active windows projects?

D'oh... you now see me unsuccessfully scrambling for any way to convince you that this post was anything but an invitation or "ad" to visit the site -- and shameless self-promotion. But really -- it's on topic! ... see? unsuccessful ;) ... perhaps because that's exactly what it is. Oh well.

And http://pciids.sf.net is still going strong.

Will those lawyers be going against that next? Because I assure you those IDs appear in compiled binaries of Linux.

for all the ones who asked for an iso solution : movix

Does your project by any chance resemble this CueCat decoder?

Judging by your post, you already know about the following, but this is for those who have old nubus powermacs and don't like being stuck with macos < X.
http://nubus-pmac.sf.net/
Unfortunately the last update of the news on there was January 2002 and the last patch was against 2.4.5. Ignoring that, my experience was that it worked quite well on a 6100/60 (although my iBook kicks it's arse)

Python Zope - minimum memory foortprint is about 11 megabytes

Er, yes? If one group of volunteers can make a well integrated and fast browser based on Gecko, what stumped Apple so bad? The Mozilla codebase is large, but that's becuase it's a hell of a lot more than a rendering engine. In fact, the rendering engine part of it isn't so bad at all, I've seen it and understood most of it and I'm hardly an ace coder.

There has been an enormous effort gone into Mozilla and it shows, but I think it still has a way to go.

Well, like where? Gecko is the most standards compliant, the most powerful and supports the most technology. It's also very fast, the FUD about it being slow here simply is not true. I've been blown away by the speed of Galeon. I think part of the problem is that the default front end "feels" slow because of the default theme to some extent. Oh, while I'm thinking about it, try adding this line:

user_pref("nglayout.initialpaint.delay", 0);

to your prefs.js file (shutdown moz first). You'll find it feels a lot snappier if you're on a decent machine.

Yes, and of course KHTML is not used in the "real" world.

Well of course KHTML is used a bit, but on my Linux specific site about 60% of the hits are from Mozilla, about 25-30% are from IE and about 5% are from Konq. So really KHTML is not used much at all in the real web, although it's used plenty inside KDE for their help system etc.

In fact, I only know of one implementation that "only" has a bytecode compiler, CLISP. Last I heard, there are about 15 Lisp systems altogether.

So you need a better excuse for not writing a Ruby compiler right now. :-) Go look at the source code of CMU CL, it has one of the fastest Lisp compilers around, and most of it is in the public domain. (The compiler is called "Python" btw., that may be concern for Ruby people ;-))

The flag icon for Slashdot's 'United States' section is missing its first stripe - the stripe that represents Delaware, the first state admitted to the Union. While a simple oversight could be forgiven, it should be known from here on out that Slashdot is in fact aware of the missing stripe, and even worse, refuses to do anything about it!

This vulgar flag desecration and rabid anti-Delawarism must be put to a stop. Let the Slashdot crew know that we will not accept a knowingly mutilated flag or the insinuation that Delawarians deserve to be cut out of the union. I ask you, what has Delaware done to deserve this insolence, this wanton disregard, this bigotry?

This intentional disregard of a vital national symbol is unpatriotic. Why, the flippant remarks CmdrTaco made about our flag border on terrorism! I urge you to join the protest in each 'United States' story. Sacrifice your karma for your country by pointing out this injustice. Let's all work together to get our flag back. Can you give your country any less?

The technology is called S.M.A.R.T. That stands for Some Stupid Cutesy Ancronym.

Fow UNIX, you want to use smartd, which is part of smartmontools

S.M.A.R.T. is pretty good at detecting normal failures. It is no help for when Windows decides to chkdsk your > 137GB partition and scribbles garbage all over the disk.

For GNU/Linux there is a solution now: xine does pnm and rtsp real streaming. however, most codecs are available on x86 only. See the xine faq for details.

I wonder how this will be affected if their drm crap really catches on among content providers :-/

If you liked the Stanford Checker, but you want something that is a little bit crappier then you should try out Smatch.

As far as I can tell, it's the functional equivelent of the Stanford Checker, but it not as elegant or complete.

Also I wrote it.

When i started working as a developer at ILM, there wasn't really any bug-tracking system in use. So i threw together a quick hack, on a weekend when i finally couldn't stand it any more (isn't that how so many software projects get started?).

Over the two years i was there, it grew, but it stuck to three core ideals:

1. Don't force the person entering the bug to enter anything other than a description. Just allow people to go back later and add details, change categories or priority settings if they want to.
2. Make it really easy for other developers to enter the conversation around the bug, so the discussion and activity surrounding the bug can be recorded with the bug.
3. Optimize the user interface to display the most useful information in the available screen space.

To meet the first two goals, the system was based on e-mail: anyone could just send a free-form e-mail message to the roundup address, and a new bug would be created; then anyone who replied to messages about the bug would be automatically added to a mini-mailing-list. Every bug got its own automatically managed mini-mailing-list.

Most other bug trackers are really bad at the third goal: they take up all kinds of space with management details that people don't really care about. What a developer really wants to see is the descriptions of the bugs, so Roundup maximizes the screen space for that.

It grew far beyond my original plans, in terms of the number of users and bugs logged. The back-end implementation was terrible (no database, just lots of little text files; performance was awful but it did have the redeeming factor that you could just use "tar" to archive them).

As far as i know, ILM R&D is still using it today, and they're running multiple instances of it to support different applications and teams.

You can get the source code and see some screenshots on a page about Roundup, though i'm not developing it any more. A new group of people has picked up the torch and carried it on in a Sourceforge project that is alive and well. Their project is a complete rewrite of Roundup, originally based on a design document I wrote, but now much extended. I encourage you to check it out.

Ever heard of the LiRC project? Myth fully supports all liRC remotes.

Yo my name is filsa and I wrote an outliner and if you wear eyeliner then I'll call you a fag.
I don't mean to brag but my pants sag and I'm a true gangsta killin' Windows fags.

Yo my name is filsa and I wrote an outliner and if you wear eyeliner then I'll call you a fag.
I don't mean to brag but my pants sag and I'm a true gangsta killin' Windows fags.

You don't seem to like XUL. In your original post you praised this new thing for ditching XUL. Yet in the article you linked to, we find the following:

Communicator utilizes the Gecko engine and XUL user interface language found in Mozilla, but it was developed entirely in-house and is not open source, according to AOL.

I prefer doing my own research instead of just believing what's written in some article.

1. copyright-notice.txt mentions wxWindows. Why should AOL mention wxWindows, when the Communicator uses XUL for the interface?
   
2. Have a look into the file ''AOL Communicator\locale\cat\wxweb.mo''. You can find the following strings:

   wxGeckoWebEditor.createLink wxGeckoWebEditor.editLink wxGeckoWebEditor.linkPrompt wxGeckoWebEditor.selectedLinkPrompt

   The strings indicate that AOL ported Gecko to wxWindows.

Yes, there are also XUL files in ''AOL Communicator\chrome\embed.jar'', but K-Meleon (a Windows browser using MFC for GUI stuff and Gecko for rendering) does also have XUL files in ''K-Meleon\chrome\embed.jar''. I don't know Galeon, but I'm sure, it does also have a file called ''chrome/embed.jar'' that contains XUL files.

Do I dislike XUL? - No. I don't care about the toolkit. I don't like the current state of XUL... it became better - as I said, but it's not what it should be to the user (performace as most important point).

To make one thing clear: I'm not a Mozilla basher. I use Mozilla (and Mozilla based browsers) under every OS I use (Phoenix under Windows, Mozilla under BeOS, and Netscape 7 under Solaris8/SPARC in my university).
I want that is that a good product (Mozilla) becomes better. Gecko is a very good rendering engine, but IMHO XUL is (in it's current form) not that good for GUI stuff (from a user's perspective).

The funny thing is, there is a nice-looking gui, available here. It's called GUIPod, and is actually based on gnupod (the software this tutorial discusses). I haven't tried it myself, but I assume its at least half-decent, being based on gnupod.

First off, I probably shouldn't have even brought up Tapestry, I'm generating a bad reputation for trying to monopolize discussions and steer them towards Tapestry.

Struts rounds off the rough edges of servlet/JSP development. It does a little streamlining, such as creating an abstraction between actions and JSPs. Actions are subclasses of a struts-provided class and are very, very similar to servlets ... in fact, they must be stateless, just like a servlet.

JSPs are called "forwards" and, in fact, the plumbing doesn't require that the output be JSPs, you can plug in other templating systems such as Velocity.

There's standard taglibs that help with creating URLs that reference actions, help with building forms, and there's a system, called form beans, where query parameters are picked up and dumped in as properties of a bean, which is then passed to an action for processing.

That's really about it.

Tapestry is simply a different kind of beast. It's goals are different ... it doesn't round out the edges of the servlet API ... it makes the servlet API irrlevant to the developer. You create Tapestry applications without thinking about URLs, query parameters or any of that jazz. It's all "objects, methods and properties".

Let's take a simple form example. In Struts you would have to

• Create a JSP
• Register the JSP in the struts_config.xml
• Create a html:form tag and identify the action it submits into
• Create html:textfield and etc. tags. These pull properties from domain objects and create HTML form elements from them.
• Define a form bean class to receive the submitted values
• Register the form bean in struts_config.xml
• Create an action to receive the form submission (and register it in struts_config.xml)
• Put code in your action to extract properties from the form bean and apply them to your business objects

Struts doesn't have any kind of namespace management, so if you are on a a big team, you have to be careful to name things uniquely.

In Tapestry, you would

• Create a new page template
• Create a page specification for that template
• Add a Form component to the template
• Add various form components to the template
• Define a listener method for the Form component
• Create a page subclass
• Create the listener method for the form

Although this looks similar, its much easier in Tapestry. Everything you need to do is localized in the three resources of the page (the specification, the template or the class). You write very, very little code ... instead, you declare what you want the framework to do inside the page specification (an XML document), or even inside the HTML template (more like taglibs, and a 2.4 feature in progress right now).

These page specification entries are pretty short, for example:

<component id="inputName" type="TextField">
<binding name="value" expression="employee.name"/>
</component>

This says "use a TextField component, bind its value parameter to the name property of the employee property of the page". This assumes that your page class provides a JavaBeans property, "employee". The accessor method knows how to obtain this object from a backend database or EJB.

You and the other developers aren't conflicting on access to struts_config.xml. No change that another developer makes to thier page will break yours. Name conflicts simply can't happen ... each page is like a little application unto itself.

In both frameworks you have to provide the business object to the form. In Struts, an action has to store a bean as a HttpServletRequest. In Tapestry, the page provides an accessor method that exposes the business objects to the components on the page.

Tapestry does much more work for you when the form is submitted. Notice that you don't specify a URL, action, page or anything with a Form component, you simply tell the Form component what method to invoke when the form is submitted.

The form components will pull request parameters, convert the parameters to correct Java types, and apply changes to the properties of the business object. If you are using the validating text field component, then more conversions and validations occur, automatically (and properties are only updated if the input is valid).

Once all the properties have been set, the Form will invoke the listener method which carries things forward from there, including selecting which page will render the response.

On something like a login page (i.e., user name and password), you don't need a seperate business object; your form components can simply update corresponding properties of the page object itself.

Right there is one of the big differences; the objects Tapestry users work on are stateful, not stateless. You don't have to deal with that problematic indirection (storing everything as request or session attributes). Tapestry does the shuffling of data to and from the session for you, invisibly. It uses object pooling so that you code naturally (objects with methods and properties) without worrying about multi-threading issues.

Now, that's just off the top of my head and doesn't scratch the surface of what Tapestry can do. The important thing is that its all about components, and creating new components (and even packaging them into libraries of components) is a snap, in fact its often a necessary and natural part of creating an application.

Unlike taglibs, Tapestry components can (and usually do), have their own templates and often are constructed from other components. Very natural, much more like a Swing GUI in terms of composition.

Because all of the request dispatching is performed by the framework (both during render, when the framework creates URLs, and in subsequent requests, when the framework interprets those same URLs), components can have thier own private listeners and behaviors.

Thus you can have things like MindBridge's Table component, that has sortable column headings. The links for the headings are components embedded within the Table component, and the Table component provides the listeners for those links. You can have ten Table components on ten different pages, or ten on the same page and everything just works, no questions asked.

Everything in Tapestry is designed to assist the developer ... wringing more functionality out of less effort. When things go wrong, it has incredible exception reporting.

Right now we're working on release 2.4 which includes significant improvements that will make Tapestry the easiest (and still, most powerful) web app framework available.

There's reams of documentation at the Tapestry Home Page and you might just want to check it out (if you want something more coherent).

For programmers, there's an ongoing open source project codenamed Calliope to provide free online community forums with strong privacy, content and participant list protection, and without commercial advertising. See http://calliope.sf.net/

Other OPG volunteer opportunities at https://www.onlinepolicy.org/services/opg-voluntee r-apply.shtml

More general info at http://www.onlinepolicy.org/

Tapestry has a great plugin for Eclipse called "Spindle".

The learning curve can be a bit steep, but not as steep as Struts in many ways (I use Struts at my current job, and it was a massive pain for me to shift gears and work within the limitations of Struts).

Meanwhile we're changing the framework and improving the documentation to make Tapestry the easiest to use web framework out there.

better to use something like spambayes that learns from your actions and doesn't depend on external decisions, corruption and mistakes.

I don't trust any serivce that requires lists like this - they're open to corruption and mistakes.

Use something like spambayes an open-source bayesian spam filter that allows you to define what is and isn't spam.

For all you people complaining about not being able to "get into consoles", may I humbly suggest a Dreamcast?

You can find a fully free SDK here, a thriving homebrew community here, and there are already hundreds of homebrew games out there, many of them with source code.

A top of the line dev station will run you about $200 -- $50 for a used DC console, ~$15 for a serial cable, ~$135 for a BBA (100mbps ethernet), and a Cygwin install if you use Windows.

We're also working on opening up a market again with various others which, if not as large as the PS2 or GameCube, would certainly qualify as one of Garage Games' "niche markets". There are millions of DCs out there, about 90% of which can run games burned on CDR or pressed on a CD with no modifications.

So what are you waiting for? :)

Python is a decent language. But it has a number of problems

Python is a great language. It has problems, but not those you mention.

It does not have a clear cross-platform GUI (Tkinter doesn't work on OS X, wxPython isn't a standard part of the platform binary distributions).

Those that actually care about client GUI libs can install their own. In this respect, Python is no different from C, and in fact, has more GUI bindings than C!

Many packages rely on native code in shared libraries.

And your point is...? That's like saying "many parts of my house rely on the shared frame".

Python byte code is orders of magnitude slower than Java or C# code.

For real-world tasks, Python execution speed is more than fast enough. When it's not, the bottlenecks can be easily identified and moved to C, or optimized away by the machine using Psyco. Using Psyco, my neural net code ran 5x faster. But the real thing you're missing here is this: developer time is more valuable than machine time, as machine time can be saved using other methods.

Python does not have optional static type checking.

And I thank God it does not! Static type checking solves a very narrow programming problem and requires a tremendous amount of coding for the developer.

It is hard to make standalone, self-contained applications out of it.

No, it's not hard to make stand-alone, or to embed it in other applications. There are multiple proven techniques to bundle the interpreter with a parts of the standard library and third-party code. That you don't know this makes me believe you don't really know python, either.

Python does not have a well-defined language standard, nor does it have multiple independent implementations.

Oh, my! The language definition is quite well-defined and very consistent. And there are two open-source implementations on separate platforms: python in C and python on Java

Python could be more of a contender if someone built a good native code compiler for it. None of the current attempts are very good or result in much speedup.

Psyco speeds up python by optimizing chunks of code at run time. The neat thing is that it does this against python code, so python becomes faster by more of it being written in python.

The way it is, Python is good for many scripting and prototyping applications. But for a general-purpose, high-quality programming language, we still have to look elsewhere.

NASA. ILM. Google. Please.

Hi, Vadim.

As an avid wx user (and casual contributor) for three years, let me say that wx is remarkably bug-free for a library that size. I use wx daily, both at work (designing GUIs for scientists at JPL) and on the side (Audacity) and I haven't seen a wx memory leak in a year. Nor have I seen a crash: the worst problems I've seen recently are occasional cosmetic errors that are easy to work around (i.e. a window redraws itself unnecessarily when you modify a certain attribute).

Mod parent up. Mldonkey is a client for the eDonkey network, which is really good. There are also compiled OS X binaries available. It's not as good as the windows client eMule, though (hoping for a Mac OS port soon!).

Neither SDL or PyGame actually have built-in user interface libraries. You could look at PyUI which is a user interface library written in python. It was specifically written to draw on hardware accelerated 3D surfaces - primarily for video games.

Pyui is a user interface library written entirely in the high-level language python. It is targeted primarily as a user interface for games and has a modular rendering interface that can use multiple backends such as OpenGL, SDL or Direct3D
From the PyUI homepage. If you are using python or could switch to python, PyUI is light-weight, easy to use and has a surprisingly large amount of functionality.

OGRE is an OpenGL (and alternatively DirectX) scenegraph library that's still in development, but may already provide useful functionality. Think of this as a next generation SGI Open Inventor. I've used Open Inventor and have recently switched to OGRE since OI shows it's pre-ISO C++ standard roots. (And pre-Scott Meyers. And pre-Gang of Four Design Patterns.)

There are many Open Source alternatives around. Big Brother, MRTG, Zabbix comes to mind.
What makes Nagios unique? Thanks.

Nagios is well-made software. However it's difficult to set up. I'm using Zabbix for network and system monitoring at work. The software keeps under control more than 400 Unix servers, mostly Linux boxes. It has very clean design and works perfectly. What functionality do you plan to introduce in future versions of Nagios to make it more attractive for those who currently uses other Open Source alternatives?

it is structured around the file system rather than hiding the file system like windows.

rox.sf.net

First of all, if this is "open" (free) versus "closed" (commercial), WHERE is the Gnutella 2 specification? "It's coming". I mean that's one of the oldest notions in the free software community, it is NOT open source (or protocol) until the source (or protocol) is actually open! When (if) the specs come out, I'll believe it.

Currently the Gnutella "1" (aka v0.6) specs are published, and functioning in many clients, and the Gnutella 2 protocol is not to be found anywhere. It's true that Shareaza does not (yet) have ads and Limewire and Bearshare do, but Shareaza's source is closed, unlike Limewire's. Calling Shareaza open and free and Limewire closed and commercial is kind of silly, especially since Shareaza source is closed and Shareaza G2 protocol is (currently) closed.

Second of all, Gnutella is a coalition of the most popular Gnutella developers - Limewire, Bearshare, Gnucleus, Xolox, GTK-Gnutella, Morpheus (sort of) and so forth. Currently, they call the Gnutella version they have version 0.6. Along comes a new client Shareaza, and they try to hijack the Gnutella name and call it "Gnutella 2".

I hope Mike comes to his senses. Shareaza is a decent p2p client, and has been a positive thing for Gnutella, and he can do what he wants, but I am uninterested in any new protocol until protocol specifications are published, and trying to seize the Gnutella name is kind of silly as well, especially since the protocol he wrote (and has yet to share specifications of) is so radically different than Gnutella. He can switch to his new protocol if he wants, but he should stop calling it an open protocol until he publishes the specifications, and he should consider a name aside from "Gnutella 2".

This is a no-brainer. OpenBeOS's new name! It's been over a month since the vote has closed, how long does it take to log in to the MySQL server and do a query to see how many votes each got? I mean, come on!

try spambayes. works great.

Gnu darwin packages some GNU software around the APSL licenced darwin OS from Apple. So really the benefits of GNU darwin is helping software mainainers to have their code compile straight out of the box on darwin and thus MacOSX.
OTOH you need to be aware of fink which brings the same kind of software to macosX and thus darwin.
Then you also have darwinports bringing to darwin the same has gnu darwin.
Gnu darwin will now only port x86 making the port "just" a little easier then the PPC one which involves endianess issue and other tricky stuff.
If developers are interested in darwin they should stick with the main developers of the OS (Apple), hence with PPC so interested party should join darwinports instead of Gnu darwin.

sound of the 1541 disk drive gronk, grind, and click?

God, I remember that fondly. That drive made most Jet Liners seem quiet. I used to (litterally) pile pillows around the thing to keep it kinda quiet when I was loading paradroid or something late at night and I didn't want to have my parents come down and tell me to turn it off and go to bed.

These days, I can just quick compile something else and grab a pair of headphones. My wife doen't complain much whilst I'm yelling at a 999 that is kicking my ass.

I have fond, fond memmories of my old C=64s (yea plural, I killed the first one...)