Slashdot Mirror

It greatly depends on how you 'use' it.

Lets say you have a Java app that, in whatever way, uses the standard jdbc classes. One of your users chooses to use the MYSQL jdbc drivers to connect to a MySQL server. Your app doesn't need to be GPL, imo, because the only code YOU used was sun's JDBC code. Your user chose to link it to the GPL'd drivers and it's their responsability to adhere to the license. Since they can't distribute your code (they don't have it) as long as they don't distribute the binaries to the app, they are not in violation (since the code bit only applies to distribution).

HOWEVER, if you either specifically tell the user to use MySQL or expect the GPL mysql driver in your code (ie, specifically referencing the driver in the connect setup) then you are in GPL territory.

Now lets say you have a C/C++ app and you link in the mysql library (either statically or dynamically). The mysql client lib is under gpl and you, if you distribute your application, would be required to release it under the gpl - after all, you are using gpl'd code. The only way around this would be to find or develop and use a non-gpl driver.

The real answer, anyway, is that it depends on what you are linking to and how you link to it. Yes, simply connecting to a MySQL server does not implictly bind you to the GPL - just like Microsoft isn't required to GPL internet explorer because it can talk to a GPL'd webserver. However, if you are using the GPL'd drivers to connect, you are in GPL territory (not because you are connecting, but because you are using the GPL'd code to do it).

Oh, and IANAL and IMHO and YMMV and TANSTAAFL. :)

Caudium rocks my world. Faster, easier to configure, GPL (or MPL2 if you prefer), built-in support for dynamic content, and more.

1. Try this. Config file is XML, and it has a web-based configuration interface for those who don't like XML.
2. Try this. Modules are Pike (similar to C++) objects. They can be reloaded on the fly, don't need to be compiled before they're used, and do not require a restart of the server.
3. Try this. It supports threads just fine.
4. Try this. Support for PHO (for those who want it) as well as a built-in dynamic page generating language (RXML) - as well as pike scripts (if you want more power.)
5. Try this. Memory management is not an issue.

Caudium is a wonderful web server platform - it's faster, more powerful, and easier to use than Apache. Once you try it you won't go back.

1. Try this. Config file is XML, and it has a web-based configuration interface for those who don't like XML.
2. Try this. Modules are Pike (similar to C++) objects. They can be reloaded on the fly, don't need to be compiled before they're used, and do not require a restart of the server.
3. Try this. It supports threads just fine.
4. Try this. Support for PHO (for those who want it) as well as a built-in dynamic page generating language (RXML) - as well as pike scripts (if you want more power.)
5. Try this. Memory management is not an issue.

Caudium is a wonderful web server platform - it's faster, more powerful, and easier to use than Apache. Once you try it you won't go back.

1. Try this. Config file is XML, and it has a web-based configuration interface for those who don't like XML.
2. Try this. Modules are Pike (similar to C++) objects. They can be reloaded on the fly, don't need to be compiled before they're used, and do not require a restart of the server.
3. Try this. It supports threads just fine.
4. Try this. Support for PHO (for those who want it) as well as a built-in dynamic page generating language (RXML) - as well as pike scripts (if you want more power.)
5. Try this. Memory management is not an issue.

Caudium is a wonderful web server platform - it's faster, more powerful, and easier to use than Apache. Once you try it you won't go back.

1. Try this. Config file is XML, and it has a web-based configuration interface for those who don't like XML.
2. Try this. Modules are Pike (similar to C++) objects. They can be reloaded on the fly, don't need to be compiled before they're used, and do not require a restart of the server.
3. Try this. It supports threads just fine.
4. Try this. Support for PHO (for those who want it) as well as a built-in dynamic page generating language (RXML) - as well as pike scripts (if you want more power.)
5. Try this. Memory management is not an issue.

Caudium is a wonderful web server platform - it's faster, more powerful, and easier to use than Apache. Once you try it you won't go back.

1. Try this. Config file is XML, and it has a web-based configuration interface for those who don't like XML.
2. Try this. Modules are Pike (similar to C++) objects. They can be reloaded on the fly, don't need to be compiled before they're used, and do not require a restart of the server.
3. Try this. It supports threads just fine.
4. Try this. Support for PHO (for those who want it) as well as a built-in dynamic page generating language (RXML) - as well as pike scripts (if you want more power.)
5. Try this. Memory management is not an issue.

Caudium is a wonderful web server platform - it's faster, more powerful, and easier to use than Apache. Once you try it you won't go back.

There are much more advanced webservers than Apache, that are faster, more powerful, and are much simpler to configure.

And no, IIS isn't one of them.

Here's one that's that does way more than Apache, is faster, more configurable, has an XML syntax for its config file, but can be fully administered with a web browser.

It pretty much addresses all of the issues in the presentation, and is neither limited nor difficult to use.

.. that they're making it more like Caudium.

Modular. Check (Caudium is *way* more modular than Apache.)
Web-based admin via SSL. Check
Integrated language for dynamic pages. Check.

Caudium has an awesome business graphics module; it can graph data from flat files, SQL, or pretty much anything else you can think of.

How about Caudium?

Purification of incoming data is essential

Then why doesn't the language do it by default?

If you need the unfiltered data, you should be forced to jump though at least one hoop to get it.

Take RXML for example. By default, all user-supplied data is encoded, unless you explicitly say that you want the raw format. That way, novice script writers don't get bitten by it.

Caudium

Fast, secure, extensible, modular, easy to admin (for newbies) without sacrificing power (you can still edit the config files if you wish). With the sole exception of installed user base, it beats Apache in every category.

How many of those operating systems use Apache?

You mean including Windows, all of them can, but there are fare more webservers available for Unix like systems than there are for Windows. Thttpd, wn, Thy, Roxen, Fnord, Dhttpd, Caudium, Bozotic, Boa, and AOLserver are all available in Debian in addition to Apache. Most of these are IPv6, ssl/tls, and cgi capable. They all have their strengths, and they all are being actively maintained. Most of these will operate as a drop-in replacement for Apache for most sites.

You are correct that most of the web servers on the net are Apache installations of one type or another. Most sites do not need or use all of the features that Apache offers, but install Apache anyway. Sound familiar? They are still thinking in traditional market terms, instead of looking at what is available to them. They treating Unix as if it were Windows, but if an cross-platform Apache-specific worm were to affect them adversely, there will be alternatives available to them that they would not have on Windows.

The point is that Unix like operating systems offer greater variety of more services in more implementations than Windows does or ever will. There is more room for fault tolerance, more methods available, and more capability to find new solutions to new and old problems (including security) in Free Software than any company or group of companies is capable of providing.

The only forks I've seen in major projects have been when a new version has been released but the old version has continued to have occasional maintenance patches released.

Depends what you mean by "major" (are you talking popularity, or size?)

The web server I use forked a few years ago - it's not as popular as Apache, but is just as much a "major" project (as far as lines of code.) I use it over Apache for a number of reasons (including speed, flexibility, and ease of development.)

The fork happened for a number of reasons, but the straw that broke the camel's back was a major release which broke backwards-compatability.

If the fork had not happened, I would have been stuck either with a dead project (no upgrades, not even bug fixes) or having to waste hundreds of hours re-learning the software and re-writing sites.

The fork gave me an upgrade path, as well as better support.

simpler code and a more straight-forward config syntax (the only two real failings of sendmail).

OK, maybe I'm a masochist, but I actually like sendmail's config file :o)

No - seriously - yes, it can be a pain to understand, but it allows me to add functionality without patching the sendmail binary.. (yes, I really do edit sendmail.cf by hand..)

If anyone ever does write a better mailer, I hope they include a decent plugin system (maybe similar to Caudium's - simple, easy, does not require compilation..)

Oh, and as long as I'm dreaming, I'd like a pony. :o)

There's also Caudium which is a fork of the Roxen 1.3 code base. Version 1.3 runs with Pike 7.4.

Anyone who likes AOLserver but not Tcl should look at Roxen (and/or Caudium) as they are both single process multi-threaded web servers with built-in scripting.

What I mean is that if you want to run an open source web server, you use Apache

Not necessarily. In the case of X, this is (probably) true, but there are alternatives to Apache. Take Caudium, for example. It's a fully-featured GPL web server, that has pretty much every feature Apache has, and then some. It's easier to administer (especially for people familiar with point-and-click interfaces), faster, and scales better than Apache.

Apache is much more well known, and I wouldn't recommend changing if you already use it, but if you were starting from scratch, I'd highly recommend Caudium.

It sounds to me that either Roxen or Caudium might meet your needs.

Both are multithreaded web servers, which are very good at producing dynamic content.
They have a very nice macro language built in (RXML) and support scripts written in the language Pike (which both servers are written in as well). Both also support embedded perl scripts, as well as java servlets, and fastcgi scripts. It also has very good database support, and support for dynamic image generation.

I haven't used Caudium myself - it is a fork of the Roxen 1.3 codebase, and I had already started using the new 2.x features before the fork happened. It is GPLed, and is available here

Roxen is available in two forms, a free GPLed version (available here) and a commercial version which includes content management features (Demo available here).

The new versions of Roxen are bundled with a MySQL install which the server uses for storing configuration data, caching generated images and pike/rxml pcode, and for storing internally managed user databases. It also works well with PostgreSQL as an external database.

Php support in roxen is a little tricky. Recent versions of PHP can be compiled into a module that can be merged into pike, allowing both Roxen and Caudium to execute PHP scripts inside of the multithreaded main process. This is still buggy under Roxen, but I understand that it works well under Caudium. Personally, I compiled php as a fastcgi, and used Roxen's fastcgi module.

It sounds to me that either Roxen or Caudium might meet your needs.

Both are multithreaded web servers, which are very good at producing dynamic content.
They have a very nice macro language built in (RXML) and support scripts written in the language Pike (which both servers are written in as well). Both also support embedded perl scripts, as well as java servlets, and fastcgi scripts. It also has very good database support, and support for dynamic image generation.

I haven't used Caudium myself - it is a fork of the Roxen 1.3 codebase, and I had already started using the new 2.x features before the fork happened. It is GPLed, and is available here

Roxen is available in two forms, a free GPLed version (available here) and a commercial version which includes content management features (Demo available here).

The new versions of Roxen are bundled with a MySQL install which the server uses for storing configuration data, caching generated images and pike/rxml pcode, and for storing internally managed user databases. It also works well with PostgreSQL as an external database.

Php support in roxen is a little tricky. Recent versions of PHP can be compiled into a module that can be merged into pike, allowing both Roxen and Caudium to execute PHP scripts inside of the multithreaded main process. This is still buggy under Roxen, but I understand that it works well under Caudium. Personally, I compiled php as a fastcgi, and used Roxen's fastcgi module.

It sounds to me that either Roxen or Caudium might meet your needs.

Both are multithreaded web servers, which are very good at producing dynamic content.
They have a very nice macro language built in (RXML) and support scripts written in the language Pike (which both servers are written in as well). Both also support embedded perl scripts, as well as java servlets, and fastcgi scripts. It also has very good database support, and support for dynamic image generation.

I haven't used Caudium myself - it is a fork of the Roxen 1.3 codebase, and I had already started using the new 2.x features before the fork happened. It is GPLed, and is available here

Roxen is available in two forms, a free GPLed version (available here) and a commercial version which includes content management features (Demo available here).

The new versions of Roxen are bundled with a MySQL install which the server uses for storing configuration data, caching generated images and pike/rxml pcode, and for storing internally managed user databases. It also works well with PostgreSQL as an external database.

Php support in roxen is a little tricky. Recent versions of PHP can be compiled into a module that can be merged into pike, allowing both Roxen and Caudium to execute PHP scripts inside of the multithreaded main process. This is still buggy under Roxen, but I understand that it works well under Caudium. Personally, I compiled php as a fastcgi, and used Roxen's fastcgi module.

In my opinion, an open-source ColdFusion would be a hell of a lot more interesting than an open source Flash.

Take a look at the Caudium web server. It supports A CF-like interface called RXML, that makes web apps a snap.

it defaults to 'nobody' but if the web server is running as root, you can specify any username in this box.

Actually, you don't need to run as root, you just have to start as root (which you have to do anyway to bind to ports <1024).

It is dificult to get PHP running on Roxen, but for everything else it works great.

For PHP, I recommend Caudium.. actually, I'd recommend Caudium over Roxen anyway :o) http://www.caudium.net Caudium is a fork of the Roxen 1.3 codebase.. basically the Caudium maintainers didn't like the direction that Roxen 2.x was heading (backwards-compatability with 1.3 was horribly lacking.) In addition to PHP support, they made great strides in performance.