Slashdot Mirror

NCSA.

http://www.apache.org/history/timeline.html

The Apache HTTP server was an evolution, not a revolution.

Goddammit.

Apache, which had started off life as a series of patches to NCSA httpd. Hence the name: it was a-patchy-server.

Why does everyone seem to want to perpetuate this myth? It's not true.

See here.

I'll quote it for the lazy:
The name 'Apache' was chosen from respect for the Native American Indian tribe of Apache (Indé), well-known for their superior skills in warfare strategy and their inexhaustible endurance. For more information on the Apache Nation, we suggest searching Google, Northernlight, or AllTheWeb.

Secondarily, and more popularly (though incorrectly) accepted, it's a considered cute name which stuck. Apache is "A PAtCHy server". It was based on some existing code and a series of "patch files".

You of all people...one who worked with the GrandPaPa of web servers, NCSA httpd 1.3, should know this.

the closest analog in OSS would be Tomcat

The closest open source analog would be JBoss. Tomcat isn't really an application server, either, at least not the way the term is used conventionally in the industry. (It is kind of fuzzy, though.) Tomcat is a servlet container. A servlet container is a necessary (but not sufficient) part of a J2EE application server, but Tomcat by itself is not a J2EE application server. See my other posting for better things to compare WebSphere to.

First, I don't see why it is important that a web application or web site be developed on a cross platform backend. The whole idea behind HTTP is that the web browser doesn't care whether the server at the other end is Windows or OpenBSD or Contiki. And I will say that, yes, if you program in PHP or Perl or use Zope, you can probably move back and forth between BSD and Linux and Solaris with impunity. Are you really going to be changing your server OS every few months? Even every few years? Universal portability of those things is a solution to a problem that hardly anyone has.

Second, If ASP.NET is supposed to be easy and has no depth, they forgot to tell me. And apparently, you've never used it, and don't know anything about it for a few different reasons:

1: It isn't actually locked to the Windows/IIS platform. System.Web is fully functional in Mono, and there is both a small reference web server (XSP) and an Apache module (mod_mono) that can be used to serve pages that are identical to those served under IIS. So ASP.NET pages are portable even though it isn't gravely important. (Of course, Mono itself doesn't run properly under BSD yet AFAIK; it runs under Linux, Windows and OS X.)

2: ASP.NET is not a 'lego bricks' platform with no depth. Despite the gripes I do have about it, it is remarkably cool in certain ways. Once you grok the event driven programming and OO model behind it, master databinding and figure out how to get it to do what you want, it is a great tool to have.

And your entire last paragraph is hogwash. You seem to be saying that the best programmers do it the hardest way on purpose. The opposite is true; only an idiot would intentionally do it the hardest, longest way. Are you seriously saying that companies should pay more for development firms to do it the longest and hardest way, on purpose because that means the programmers are smarter? Absolute bullshit.

Allow me to illustrate. This is like saying that you should have your portrait painted by a man who cut his own fingers off and paints with his feet, because it means he is more dedicated to painting. No, he is more dedicated to painting with his feet. If he really wanted to paint portraits, he would have kept his fingers, because that is what the damn fingers are for.

Lastly, I couldn't tell you about Tomcat specifically, but I just saw Jakarta Struts For Dummies at Borders the other day, so apparently the J2EE learning curve is not as steep as you would have us believe.

I see they are using Lucene as their search engine. Lucene a powerful open source indexing system from the Apache Jakarta project written in Java. It's nice to see this, rather than MS indexing service or some other proprietary search solution. Lucene, with the appropriate open source plugins, can index a wide range of content, including MS Office and PDF files.

Apache is inclubating a new unified directory service that promises to be the cat's meow.

CLI sub-project of the Apache HTTP Server is focused on developing interfaces to the various Common Language Runtime (CLR) alternatives for .NET integration into the Apache HTTP Server.

mod_aspdotnet module is an ASP.NET host interface to Microsoft's ASP.NET engine. It is implemented with an Apache.Web.dll assembly that provides ASP.NET with the necessary System.Web.Host and System.Web.Request interfaces to converse with mod_aspdotnet and the Apache HTTP Server.

mod_aspdotnet works only with the .NET Framework version 1.1 at this time. Flexibility for 1.0 or 2.0 .NET Frameworks is being considered.

This module is not compatible with other .NET CLR interfaces, such as Rotor or Mono, and therefore it is only compatible with the Win32 port of Apache 2.0.

Users on non-Win32 platforms may wish to explore the mono project's implementation of mod_mono, also for Apache HTTP Server, and compatible with some non-Win32 platforms. The mono project is not affiliated with the Apache Software Foundation.

On Linux, you can use the Apache module mod_mono .

It is available on the Mono project's download page.

It allows Apache to serve ASP.NET pages by proxying the requests to a slightly modified version of our XSP called mod-mono-server that is installed along with XSP.

It doesn't work on the Windows version of Apache yet, but work is in progress to make that work, too.

Apache's Ant may be worth a look. It handles dependancies very well. It may not be so great with timing of jobs (cron + ant?) or handling jobs running in parallel (ant plus a custom 'run task in the background'?).

--
Linux Server + Persistence => Solution

They aren't using Access, as you probably know.

The real problem is that they ARE using Tomcat, which is well known for its stability and robustness.

We know this thanks to stack traces the account server has, at times, given. You can also tell by going to www.worldofwarcraft.com and seeing it try to set a cookie named JSESSIONID. JSESSIONID? Hmm, that sounds suspiciously like what Tomcat uses for session management...

Extra processes running are extra processes running. In a windows environment, you cannot separate out certain processes that are unnecessary and they will always be running in the background.

Apaches threads can be modded. The entire conf can be changed. If you think a default install is all there is to maintaining a server, I'll send you a ticket to reality so you can visit us sometime.

ThreadsPerChild: This directive is new. It tells the server how many threads it should use. This is the maximum number of connections the server can handle at once, so be sure to set this number high enough for your site if you get a lot of hits. The recommended default is ThreadsPerChild 50.

...it will be a huge test for the OSS community, to see if they can really handle these problems as well as they always say they can.

I guess you've never heard of Apache. 68.8% market share ought to be a good test of the OSS development model. Of course that's not to say that all OSS will fare as well as the carefully developed Apache project, but saying the whole model is untested... is simply uninformed.

With the danger of being modded way down by the zealotist crowd: If you are going to complain about Microsoft patents, could you instead point at the real problems:

• Microsoft are seeking a patent for URI rewriting
• United States Patent Application 20040260722

That particular patent, if granted, will in effect make mod_rewrite infringe. Not that Microsoft would stand a chance in court with this patent, since mod_rewrite predates both the application, and referenced patents.

And if you want a laugh from the MS' patent portfoliom you should know that Microsoft holds a patent for an apple tree named Burchinal Red Delicious. (US Patent PP14,757

"Additionally, the open source development approach encourages the creation of many permutations of the same type of software application, which could add implementation and testing overhead to interoperability efforts."

Uhm, yes. Interoperability takes adherences to standards and a lot of testing and work. If we all use the same software, that's not interoperability, that's software hegemony. Silly.

I'll tell you about Microsoft's interoperability. It's Apache Axis having to add an API just because the MS libraries don't send information about a SOAP call's return type. That's the true meaning of interoperability.

Check here for the real story.

lost worker productivity among end users is just one important factor in the total cost of spam.

there are a number of other important factors, including:

• more time spent administering e-mail servers: keeping MTA current (e.g. sendmail or postfix upgrades) and keeping anti-spam software up-to-date (e.g. spamassassin upgrades, some occasional score tweaking, etc)
• occasionally upgrading server hardware to keep pace with increasing spam bombardment
• time spent investigating major spam incidents and/or abuse complaints (e.g. resulting from spam sent with headers forged to look like they come from your domain)
• bandwidth and disk space used by spam

One solution is SURBLs (Spam URI Real-time Block List, I think). This is a list of web addresses contained in spam. An anti-spam filter parses an email, then checks any URIs against various SURBLs. They are pretty damned effective. Any URI in spam gets blocklisted pretty soon, and filters can act accordingly and block spam.

These are up and working, and have been for at least a year. The latest SpamAssassin has support for them out of the box, I haven't checked but it may use around 5 different lists.

There is a small network delay and very little processing overhead on the spam filter. So email may be delayed for 15 seconds, but spam will be filtered to a far greater extent.

Visit www.surbl.org for more info, and don't forget to check out SpamAssassin as well. Anyone running a modern Linux can filter their own email, even if they pick email up from a pop3 server. I'd recommend a fetchmail, postfix, procmail and spamassassin combination, but there are many, many ways to do this.

• Vipul's Razor: http://razor.sourceforge.net/
• Pyzor: http://pyzor.sourceforge.net/
• Spamassassin: http://spamassassin.apache.org/

Does anyone know much about Apache James? Apache's new Java-based mail server? I've been playing around with it and it seems pretty smooth. But how does it compare to, for example, postfix?

One nice feature is that you can extend James using "Mailets" (like applets/servlets but for mail) written in java, which would be great for a java-head like myself :).

Anyway, I was just wondering if anyone knew much about it/actually used it for anything. It would be nice to have a single mail server who's configuration could be used on any platform. lq

Does anyone know much about Apache James? Apache's new Java-based mail server? I've been playing around with it and it seems pretty smooth. But how does it compare to, for example, postfix?

One nice feature is that you can extend James using "Mailets" (like applets/servlets but for mail) written in java, which would be great for a java-head like myself :).

Anyway, I was just wondering if anyone knew much about it/actually used it for anything. It would be nice to have a single mail server who's configuration could be used on any platform. uo

This is in some ways similar to how Apache Software Foundation projects work:

http://www.apache.org/foundation/how-it-works.html #meritocracy

I think it's a pretty sensible way of doing things.

Compare this with the rather more beaurocratic Debian procedure for adding new maintainers:

http://www.debian.org/devel/join/newmaint

All three are certainly different projects, that require different kinds of talent and abilities, so it's likely that what works for one may not work for the others, but I think it's instructive to compare and contrast.

As far as openness, the 'meritocracy' system works fairly well if those on the inside are inclined to add others. Nothing prevents J Random Hacker from making patches or writing code. Do that successfully for a time, and you will be invited to participate.

There's a *lot* of open source in Java, and basically all of them use ant.

I'm sorry, what was this article about?

Beeing in the incubator does not yet mean it is a full blown ASF project - but that the ASF is in the process of ensuring that there is a healthy community around it, that all the legal paperwork, trademakrs, grants, copyrights and other interlectual rights are sorted out, that commiter license agreements are on file for each developer, etc, etc..

Once that is all in place (and getting a healthy long term community is hardest - the rest is just endless grunt work and digging through code and legal paperwork dotting i's and crossing t's) it'll leave the incubator and be a full blown process.

Feel invited to join and make this happen ;-)

Dw.

sure it is.

reasonably full SQL92 syntax;

Actually, I think the biggest limitation is the 18 character names for constraints (et. al).

As it happens I've already written a review of cloudscape; the google cache of it is here.

Brief summary: get the Apache version; reasonably full SQL92 syntax; performance OK; a bit lacking on security.

Ever try Maven?

build.xml files tend to get crufty. Maven builds are sleek, particularly if you write your own plugins to handle the odd bits. And the mevenide integration with both Eclipse and Netbeans is almost flawless.

Look at http://brutus.apache.org/gump/kaffe/

This is a nightly check out and build of all OSS projects in Gump. It is slowly coming together, as now the projects are putting in tweaks to work better with the kaffe toolchain, pulling out any naughty use of sun.* code, etc, etc. The goal is simple: all the Apache and other main OSS projects, built with OSS libraries, on an OSS JVM. One day, we shall be truly free...

It would be a great way to distribute any commonly accessed data if set up properly,

Apache should look into doing this for all of their projects. For example, the Cocoon zip file download comes in at 35MB -- most of it is jars that you already have.

The bandwidth saving with just that one distribution would be enormous.

Ideally, this is the place where your server-side library like Tapestry that already generates html widgets that link back up to server calls come in handy. You DON'T have to write out this stuff by hand, it's generated by the server according to your parameters.

Then all the worries about ANOTHER programming language and ANOTHER place to introduce un-maintainable code just go out the window. Someone who knows what s/he is doing writes a widget that is well documented and tested. You employ it according to it's API and POOF! your web-based UI just got XMLHttpRequest-ified(TM).

As far as web app development is concerned, XML is more and more present in the two domains, either natively or via open source projects.

On the Java side, the struts framework provides logic to the front end so developers can use an XML style language to go through lists, create variables, set objects, etc. You can also make all your build scripts using ANT, which allows for function calls, variable assignments, and other simple tasks.

On the .NET side, ASP.NET pages are in the form of controls, which similarly to the struts framework allow server side logic to be defined through an XML language. You can use NANT also to make builds. Similar to ANT, it allows for many simple programming language tasks including listeners.

I have yet to see exception handling and OO but I'm sure it's not far away.

As far as web app development is concerned, XML is more and more present in the two domains, either natively or via open source projects.

On the Java side, the struts framework provides logic to the front end so developers can use an XML style language to go through lists, create variables, set objects, etc. You can also make all your build scripts using ANT, which allows for function calls, variable assignments, and other simple tasks.

On the .NET side, ASP.NET pages are in the form of controls, which similarly to the struts framework allow server side logic to be defined through an XML language. You can use NANT also to make builds. Similar to ANT, it allows for many simple programming language tasks including listeners.

I have yet to see exception handling and OO but I'm sure it's not far away.

What is needed to make Linux more widespread on the desktop is to find a niche where Linux is cleqrly superior to Windows and to push into that niche

Gcc for example spits out the dependency information if you ask it to, and then you can suck that into a makefile automatically.

Gcc does that but it is a kludge to me because you are expected to maintain it by yourself or include it on the makefile. This is the kind of thing that should be automatic, without you having to setup the dependency data.

Java's compiling technique seems to me to be quite broken

I don't agree with you. First, this is not a problem with Java but a limitation of some tools, notably the javac compiler from Sun. In some cases it may not possible to detect all dependencies if you use dynamic loading of classes, but that is a feature and one should be aware of its limitations before using it.
Ant has a depend task that deletes older classes. It uses the dependency information stored in the class file : "The depend task works by determining which classes are out of date with respect to their source and then removing the class files of any other classes which depend on the out-of-date classes.

To determine the class dependencies, the depend task analyses the class files of all class files passed to it. Depend does not parse your source code in any way but relies upon the class references encoded into the class files by the compiler. This is generally faster than parsing the Java source."
Then a pass from the compiler will generate all missing class files. You can find the details at the Ant manual, search for javac and depend tasks.
Just watching the files opened is dangerous because Java can generate multiple .class file per source because of inner classe (example: a.java can generate a.class, a$1.class, a$2.class, etc). The tool may miss something.

>> Option to initiate persistant connection
>
> HTTP/1.1 already supports that.

Some HTTP/1.1 web servers, like Apache, support KeepAlive, which creates a persistant connection, until a certain amount of time has passed. Right now that information is not available in the browser, and I've seen no way to exploit it to create applications (and a good persistant connection would also perhaps allow thing like push, not just pull). It seems to exist solely for performance reasons, not as a way to eliminate or reduce using cookies.

I'll be glad when the Mozilla SVG Project is complete and integrated into Mozilla. I hate having to revert to using IE when I'm working on an SVG project. (Yes, I also use Batik Squiggle...but the average end user isn't going to be using Batik...)

I think Apache Maven (http://maven.apache.org/) does many of those things. It seems to be focused on Java projects, but it might work with other languages also.

I haven't used it, although I plan to look at it a bit someday.

Well, maybe I don't understand what it is that is so special about Dream Weaver's templating engine, but it sure doesn't sound like anything too special. It would be fairly easy to do the same thing with WebMacro (site down at the moment), or it's spinoff Velocity. Although both are intended as "Templating Engines" that run on the server, it's easy enough to set them up to generate static content the way that the article describes. Similarly, more extensive content management systems like Apache Forrest, which is based on Cocoon are available. I don't see what the big deal is.

Well, maybe I don't understand what it is that is so special about Dream Weaver's templating engine, but it sure doesn't sound like anything too special. It would be fairly easy to do the same thing with WebMacro (site down at the moment), or it's spinoff Velocity. Although both are intended as "Templating Engines" that run on the server, it's easy enough to set them up to generate static content the way that the article describes. Similarly, more extensive content management systems like Apache Forrest, which is based on Cocoon are available. I don't see what the big deal is.

Well, maybe I don't understand what it is that is so special about Dream Weaver's templating engine, but it sure doesn't sound like anything too special. It would be fairly easy to do the same thing with WebMacro (site down at the moment), or it's spinoff Velocity. Although both are intended as "Templating Engines" that run on the server, it's easy enough to set them up to generate static content the way that the article describes. Similarly, more extensive content management systems like Apache Forrest, which is based on Cocoon are available. I don't see what the big deal is.

Actually, Apache Cocoon provides a framework based on XSLT that allows pregeneration of pages. I might be wrong, I never used it, but that's what it looks like.

Things like form validate is WRONG - the backend should do that, not the client.
No, client form validation is definitely GOOD. With proper client side form validation in normal cases you can prevent unnecessary requests (those with invalid input) to the server. This saves both user's time and your bandwidth bill. Of course, validation MUST also performed also on the server side (client may not support JavaScript for a reason or another or client may maliciously by-pass the JavaScript validation). You can't assume anything about client's input but if client's playing nice, JavaScript form validation is a win-win situation. Of course you shouldn't be coding client-side and server-side checks by hand but instead use framework such as Struts Validator, which generates the client side JavaScript and performs server side validation from the common validation rule set.

In my capacity as a web developer, here are the software packages that I feel you should have a firm understanding of:

1. XHTML - not just 'HTML', XHTML has a few changes that you should get used to (such as closing all tags, even <img src="..."/> and <br/> tags, and all tags being lowercase). For the upcoming specifications, such as XHTML 2.0, which will be very different (you can apply an href="..." property to ANY object, instead of having to wrap it in an <a href=..."> tag), it never hurts to be prepared.
2. CSS3 - May as well read up now, it's going to be relevant in not too long.
3. Photoshop - Use The GIMP if you must, but I find Photoshop generally does what I need it to with less hassle.
4. PHP, ASP, Coldfusion, and J2EE - You don't have to learn how to program in each one, but learn about these solutions, if for no other reason than to make compelling arguments against them if the bosses ever ask you about them (or worse, fail to ask you about them)
5. Apache and IIS - for the same reasons as listed above; also, a lot of things in Apache (mod_rewrite, for example) can help you solve problems down the road. Good things to know.
6. A good editor. I use ViM myself, but what you use is up to you. What you'll want is syntax highlighting, auto-indenting, and a powerful (preferably regex) search/replace. Learn to use your editor and you will save hours of work with seconds of typing.

And now for some soft skills. First, you'll need to learn to give effective presentations. You could use Powerpoint for this, or Keynote or Impress or just print them on transparencies and put them on an overhead projector. How you do it is up to you. Will you ever need to give presentations? Not really, but effective presentations require a lot of soft skills - eye contact, graphic design, pacing, speech tones, body language - that to be skilled in presentations in general means to be skilled in a lot of other areas.

You should also familiarize yourself with colour. Learn about Pantone, just so that you know about it. Learn how colours play off each other, which colors look good on which backgrounds. Learn about bordering, whitespace, balance, and form. Consider the Pantone Guide to Communicating with Color - out of 61 reader reviews, it got 4.5/5 stars, and is a good place to start.

Learn about logos. How companies make logos, and why. What goes into making a logo, subconscious suggestions from logos (there's a reason Playboy picked a bunny for their logo, and it's not obvious). This will help in your graphic design and page layout.

Learn about accessibility and colour-blindness.

I'm probably missing a ton of important stuff, but if you do it right and are willing to learn (and posting on slashdot seems to imply that), you'll probably learn what you need to know as you go. If not, just come back and post another Ask Slashdot.

• Use the same code for the start-up sequence of your program as you do for crash recovery - treat them the same. Fewer lines of code leads to less chance of an error. That's all.

Not just that -- accept that crashing is a valid way of shutting down your program. In other words, be kill -9-safe. Also, include crash recovery in the first place; an orphaned pid file (hello, Jabberd!) or an orphaned lock file (yo, Lucene!) should not prevent a program from starting up. It's incredible how prevalent these little rough edges are.

Yep. Just use unzip and you'll get several XML files, among them: content.xml is the document itself, meta.xml is the property sheet info, styles.xml is the stylesheet(s) in use when the document was saved.

After that, you can your favorite XML widget, such as the XML::Parser Perl module, to turn it into HTML or other things of your choosing.

Or create an XSLT file and use something like Xalan to
format it on the fly.

Gotta love OOo and those open formats!

Nothing has been debunked as far as MAC vulnerabilities is concerned. Thats just wishful thinking. There have been holes exposed in Apple software before and there will be holes found later.

As for apache, yes it has less security holes than IIS, BUT it does have security issues, and isn't as perfect as you like to think.

mod_perl, and to a certain extent Java servlets, gives you a huge amount of power over the web serving process, and are suitable for developing web applications that can do almost anything with HTTP. (emph. mine)

even as you attempt to broaden the sense that mod_perl is more than just some content generating script, you undermind the essence of what you talk about.

mod_perl is capable of being used to write entirely different protocol handlers: you can make apache serve FTP or ssh with mod_perl, if you're insane enough to do so. it can completely alter the flow of information at any step in the proces, thanks to apache's beautiful filtering & module structuing.

as you state, mod_perl uses the apachi api to tie itself deeply into the apache server engine itself, performing all sorts of reconfiguration of apache. `tis truly divine.

There are several frameworks for Perl.

BSPlayer for movies, its fast and fairly lightweight. theres free, and non-free versions on the BSPlayer site

SmartFTP - n00b friendly FTP client - free for home/non-commercial use

pretty obvious what the following 3 are:
Apache
MySQL
PHP

PostCast SMTP server

CrapCleaner! cleans crap from your PC! temp files, MRUs, deletes invalid registry stuff. Whenever I use it, it usually free's up ~1GB on my hard drive! quite amazing how much crap there is on XP

Firefox and Thunderbird

Does anyone know much about Apache James [apache.org]? Apache's new Java-based mail server? I've been playing around with it and it seems pretty smooth. But how does it compare to, for example, postfix?

One nice feature is that you can extend James using "Mailets" (like applets/servlets but for mail) written in java, which would be great for a java-head like myself :).

Anyway, I was just wondering if anyone knew much about it/actually used it for anything. It would be nice to have a single mail server who's configuration could be used on any platform. bcd

Well I did a port from mod_perl 1 to mod_perl 2 many months ago, and it wasn't too bad except for the lack of completed version 2 documentation and I wished I had more examples available to me. Most of the docs then were about 50 to 80 percent completed.

The porting itself was painless when I wasn't trying to set up a build environment across multiple Apache and perl versions and using libapreq2 (lib ApacheRequest) and mod_perl2 (well 1.99).