I tried loading KDE packages from Debian, but they look awful and I don't know enough about the font issues to fix them without considerable effort. I also ran into problems with the X config. The auto-detection stuff at install time worked, but I couldn't find a way to run it again when I got a new monitor. FC3 has more obvious config tools.
On my FC3 system, KDE and Gnome both look great. The mp3 stuff had to be chased down, but it was a bit more obvious than with Ubuntu. Working mplayer (and kplayer) packages are available. However, hardware detection has problems. Besides the iPod and wifi issues, it also gives me annoying screens about hardware detection if I configure it to work with a USB printer and then turn that printer off sometimes, or configure a laptop to use a keyboard and then use it without the keyboard. Ubuntu doesn't have those issues.
So, I guess I just have to keep updating these things until one or the other gets it all right. I'm not inclined to do something crazy like go back to Slackware at this point, and Suse seems determined to make free versions of their distro impossible to find on their site. Any other suggestions?
In a similar vein, people are still recommending Cache::Cache or things based on IPC::ShareLite, when BerkeleyDB or Cache::FastMmap would be about ten times as fast. Hopefully my upcoming article based on my talk at ApacheCon will help point people in the right direction on that.
The most recent and most surprising was a big performance bug in Maypole that I discovered while helping Jesse Sheidlower with some performance tuning. People who have used Template Toolkit with mod_perl in a high-performance environment should know that you have to keep the TT object around between requests so that you don't blow the cache and recompile the templates on every hit. Maypole was throwing away the TT object. I gave Jesse a very small patch to fix this and he reported speedups of 250-500% on his application.
What's the lesson in all of this? Probably that being engaged on mailing lists like mod_perl and TT and sites like perlmonks.org has a tangible payoff in terms of knowing what the best practices are. Maybe also that we need to repeat them more often.
I'm all for busting on bloated J2EE app servers, but it's a pretty silly article. Scaling a web app across multiple machines is basically a solved problem, at least at the load-balancing and failover level. The hard part is dealing with shared data, which this "grid" thing seems to ignore completely. You need to scale your app across a hundred cheap servers? Buy a LocalDirector off eBay for $100 and call it a day.
J2EE should be an easy target. It solves a problem almost no one has: the need to coordinate transactions across multiple databases or other data sources. This is why the ultimate defense that J2EE boosters usually cling to is "Oh yeah? Can your thing do two-phase commit?" In reality, the number of applications that truly need two-phase commit is so small that BEA would likely be out of business if only those people were buying their server.
It's too bad, because I actually like Java when it isn't mixed up in this stuff. I saw some really nice stuff at ApacheCon last week, where people were talking about Java web frameworks that actually contain useful ideas. None of them, however, are J2EE.
Last week, I attended the Fourth Open Source Content Management Conference in Zurich, Switzerland. Perl was well-represented there.
The keynote was given by Roy Fielding, REST champion and author of the original libwww-perl (in Perl 4!).
I gave my talk about Krang, a new Perl CMS developed by a large magazine publisher.
Michael Kröll presented XIMS, a CMS developed by the University of Innsbruck. It is very XML-oriented and built on top of AxKit.
Harry Fuecks gave a talk about using PHP to publish a variety of document formats to the web, including POD, by post-processing the output of pod2html to get a standard appearance.
JSR-170, presented by David Nüscheler, is an attempt to create a standard API for CMS repositories. It's a Java project, but part of the project is defining a standard XML interchange format, which could be an interesting thing for Perl CMS projects to support if it catches on.
Shimon Rura and Josh Ain talked about Frassle, a system they developed (in Perl) for sharing and cross-referencing blog content.
Christian Jäger showed a project called LifeCMS. It includes a virtual filesystem written in Perl, which enables it to do automatic versioning and present the CMS repository as a standard filesystem.
There is more information available on the wiki."
There are still people out there using ePerl too. We get a mail now and then on the mod_perl list asking for help because it won't even compile on newer Perl releases. I wonder if some of the others that seem like leaders today will fall by the wayside in a few years as their maintainers lose interest and their user-communities look elsewhere.
Then he goes on to say that perl 5.8.3 gives a different result from perl 5.6.1 and that this is somehow a strike against Perl's suitability for "enterprise" work. This sounds like a result of the many bugfixes in unicode and regex stuff that happened between those versions to me, but he appears to be saying that the inability to fix bugs in Java is a positive thing, since it means you can get the wrong answer consistently. He also doesn't say whether or not he was using the same versions of Java in each test.
The problem with blog postings like this isn't so much that they are exist as that many people who read them will not have any context for evaluating the validity of the benchmark, and will just start spouting nonsense about Java's regex speed. Very frustrating.
The depressing thing about discussions like this is how much misinformation gets spread around. Here are a few examples:
There is one thing about Java which can be a problem for scalability, and that is the proprietary nature of many of the server environments people run it on. If you buy a commercial J2EE server, the vendor will promise you incredibly scalable session data storage and database caching, but they will typically not tell you how they do it. When you run into trouble, you have no knobs to twiddle and no alternate options because the whole thing is closed to you. This is why I would recommend that people wanting to use a Java solution should look at the open source tools instead, especially the new lightweight ones.
The most unfortunate thing about this PHP/Java discussion is that people still aren't talking about the things that actually do make a system scalable, like ways of limiting the resources that each active user on the site takes up, and ways of handling overload gracefully.
Okay, I guess I had a little more to say about this than I thought. I'm going to stop here for now. Maybe some of this will filter into my OSCON talk.
We're a consulting company, doing a lot of work based on mod_perl. Our clients include the Democratic National Committee, Democratic GAIN, the United Federation of Teachers, and John Kerry for President. Here's some more info from our listing:
We need a senior Perl programmer to lead development in our Washington, D.C. office. We are building complex, high-traffic web sites using open source software, including GNU/Linux, Apache, MySQL, PostgreSQL and XML::Comma.
You can send your resume to firstname.lastname@example.org. Thanks!