Slashdot Mirror

This will get you an IP address every 15 mins in your apache log so you can login or trace it.

      */15 * * * * /usr/bin/curl https://mywebserver.org/checkin

Also, if you don't want to run a full apache stack, boa is a nice light webserver which will do the same. Also, many options for perl/python servers which could be lighter yet but you would need to implement your own logging. Another cool option is have your laptop open a reverse ssh tunnel right to your server when it boots.

      @reboot /usr/bin/ssh -R 43811:localhost:22 mywebserver.org

The webserver I wrote in 1995 still powers http://images.slashdot.org/

Ok,

Weighing in with my two cents worth, for what it's worth, I'd like to brain dump what I would consider worth while options for your needs. All of these are solutions I either have used in the past successfully, or am currently using for various purposes. So bear in mind that this is not just the causal musings of a thread cruiser, but actual tried and proven solutions ;-)

First some basic assumptions:

1) You want to run some form of Unix or Unix like system ( i.e. Linux ) - you've noted you currently use your Apple PowerBook laptop, so one has to assume you're running Mac OS X 10.x.x natively ( more power to you ).

2) You want complete control over the system including "root" access 24/7 - this is of course the whole point of having your own system, you can beat it up, break it, rebuild it, and all that jazz.

3) The system should be able to be run remotely, even if just headless on your LAN, or perhaps more ideally remotely from some external 3rd party in a hosted solution so you don't end up having to host it behind your link at home ( also making it easier for you to provide access to other parties should you want to either share it with friends and family or if you just want to make it world visible for whatever reason - i.e. your own mail and web server et al ).

4) You want an "always on" solution, so this should be something that, as you state, should not suck too much juice power wise, is able to be built with a "standard build" style hardened platform, which in the case of power loss would ideally recover nicely, quickly, and be back on line ( I'll touch on this later as standard builds are going to make your life so much simpler and fun ).

5) The performance of the system ideally should be such that it will cope with the key elements you've noted in your post, such as:

a) remote access such as remote sessions via SSH won't kill the system

b) able to run a web server such as:

thttpd: http://www.acme.com/software/thttpd/
Apache: http://www.apache.org/
mathopd: http://mathop.diva.nl/
Roxen: http://www.roxen.com/
Boa: http://www.boa.org/
Jigsaw: http://www.w3.org/Jigsaw/ ( written in Java )
Acme.Serve: http://www.acme.com/java/software/Acme.Serve.Serve .html ( written in Java )
CERN: http://www.w3.org/hypertext/WWW/Daemon/Status.html
NCSA: http://hoohoo.ncsa.uiuc.edu/
Netscape FastTrack: http://home.netscape.com/ ( not sure if it's still available )
Netscape Enterprise: http://home.netscape.com/ ( not sure if it's still available )
Zeus: http://www.zeus.co.uk/

source: http://www.acme.com

I can see why where I come from the linux heads are called 'green screeners'.

And the Windows heads are called 'blue screeners'.

Or again- more with simpler hardware.

Better yet, make a business case out of it: more with less expensive hardware.

y'all just cant hack the real projects- the real complex problems- the things that would make your OS kick real ass

Some projects call for complicated solutions; others call for simple solutions. For example, a highly efficient HTTP server for static files does kick serious behind when a company with a very popular web site needs several redundant servers for the site's images. If your product can saturate the site's outbound connection with a lower total cost that the wincompetition, then the better return on investment can boost your customers' bottom line, which is the only thing that matters to shareholders.

Or- The worst software implementation for the latest hardware.

A lot of residential users and businesses can't always afford the latest hardware, you insensitive clod!

they want to make sure everyone is nice and compliant about upgrading when they decide to take httpd over to java like all the other java kool-aid they are selling --- Maven is Jonestown, lets all program in XML because its standard! Cultures breakdown when there is too little disent and questioning of authority, the apache foundtion is headed in that direction.

Lets move on, SOA and all that, most people don't need any of this mod_* crap and could use:
thttpd he has other servers there, too and http_load.
lighttpd I'm moving to this sweet little server for most apps and the home site runs ea php and ruby on rails
AOLServer like OpenACS runs on
Boa
fnord from our boy who did the (in)famous benchmarks
Cherokee I root for this one for some reason.
gatling
cthulhu
yaws in erlang, should support more simul. connections than the unlying OS can support.
dhttpd
Litespeed check out their php benchmarks
thy
roxen
mini-httpd never tried this one
xitami I have a intranet server running for 5 yrs (without upgrading xitami) on xitami Solaris, simple, small, easy to admin, never dies max uptime was 1000 days+.
eddiefor complex load bal and geographic distribution
hiawatha

And for the love of god, please at least design your sites to get their images from images.mysite.com if possible so that you can use a non-bloatware web server to server the images, reserving horsepower on your apache server for stuff that actually _requires_ some features of apache.

http://www.hcsw.org/awhttpd/ updated on 12-06-2004
http://www.norz.org/zawhttpd.html
http://cr.yp.to/publicfile.html

I've had to struggle with this also, but after all is said and done, I'm moving our whole embedded platform to linux.

This has had a few repercussion; namely, we're also doing away with the whole Windows client side of the application and replacing it with a web-app. It turns out that when you have a highly evolved embedded web server, scripting language, and database, an active client becomes unnecessary and can be replaced with a web browser.

By the way, just in case anyone else is doing this, in the embedded space I've found that LAMP (Linux-Apache-MySQL-PHP) can be successfully replaced with LBSL (Linux-BOA-SQLite-LUA).

BOA is a little web server (less than 70KB). It uses the GPL license.

SQLite is a very efficient SQL database (about 200KB if you replace math library functions with an inline function). It is public domain.

LUA is a tiny (about 100-200KB, depending on modules compiled in) scripting language with a very elegant design. The math module can be rewritten to not use the math library. It uses the MIT license.

Each of these pieces of software has a different licenses, with SQLite and LUA basically allowing you to do what you please. BOA improvements must be opened up, however you can add functionality through CGI-like modules, and that will not need to be opened.

There, there dasmegabyte. Your assertions seem to make the notes/calendar/contacts functions 'bloating' the Apple firmware equally retarded ideas (and playlist manipulation like ratings is obviously "putting data into it"), so none of that is for you I take it ;).

However, the "what-can-be-done?" factor is certainly there for quite a few people. Perhaps not a 'necessity-itch' to scratch for most, but some people want to have general flashcard reader support (photographers), high-quality sound recording (sound engineers), OGG Vorbis/FLAC support (geeks), etc. - ipodlinux might provide solutions where Apple has not.

Having an open, free platform on the toy is intriguing for them/us, not to mention fun to play around with. (A shell on an mp3 player - fun!, an XML parser [e.g. picoXML] - fun!, a webserver [e.g. boa] - fun!, etc.).

If for nothing else, just to see what can be done that Apple didn't think of, didn't want to do, or didn't know how to do (for the current price).

Personally, the existance of the ipodlinux project was the deciding factor for getting an ipod and not some other HD music player (well, that and I got a sweet deal from an Apple employee).

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.

Check out boa:

Boa currently seems to be the favorite web server in the embedded crowd, and embedded Linux, despite all the marketing hype, really is a big deal. Supposedly, an older version of Boa, v0.92q, runs in 32K address space on m68k, like used in uCLinux

• 
  AOL ServerThe Sophisticated One.
  ApacheThe One We All Know and Love.
  BoaThe Fastest One.
  WNThe Indexed One.
  

The 'httpd.conf' file is a long and critical one.

For this reason, and for several more, whenever I don't need any of the multitude of Apache features, I install one of "mini servers" - for quite a while I was going on Boa, later switched to Mathopd, but I consider THTTPD or any of several other "tiny" webservers. Small, smart, fast and easy to configure. WAY easier than Apache.
(yeah, you may think you configured Apache right because it works... but what if you just opened several security holes you didn't understand? It's much better to have a tiny config file you can use for 8 things out of which you need 6, and understand all thoroughly, than one with 400 things out of which you need 12 and understand thoroughly less than 50.)

...so many even tiny sites - home PCs, private tiny hosts and such, run Apache.
It's big. It's slow. (okay, it can stand a big load without much slowdown, but overall latency is high) It's a system hog. These computers are often older Pentiums, sometimes 486s, sometimes used as clients/terminals, sometimes serving several other tasks.

Why people so rarely use tiny HTTP servers like Boa, Mathopd, thttpd... especially, that those tiny thingies are extremely fast under light load, light on system resources, have most of features every "amateur webmaster" wants, and because of small code base, usually completely bug-free.

Field for "Evangelism"?

The box already runs the Boa webserver. Follow my directions in the article, and you can add static HTML pages (and even your own CGI's if you get a cross compilation environment going) onto the box. If we got a kernel with NFS support onto the box, it would trivial to mount your Webpages off of a remote NFS server.

The Actiontec already runs Boa as a webserver. Provided you have simple, static HTML pages, it would be simple to modify the Actiontec to serve your content. I'm not sure how SMART this would be, but it is certainly possible. The entire configuration interface is Web based. If you wanted to try this out you can follow the directions in my article for modifying the filesystem, add your pages and re-upload the new image to the router.

To a purely static server, like thttpd [acme.com]. Then you can focus the dynamic servers on serving purely dynamic stuff, and optimize accordingly.

Also, MySQL 4's query cache is a great thing, so if you're not using it yet, look into it.

...with an especially nice screen shot... :-)

Great. So the Apache group has once again proven that they can deliver both a slow and insecure web server. How many more security holes will Apache have before it is "secure"? And when will Apache deliver truly high performance by having a non blocking I/O model?

What are our choices for web servers on UNIX platforms? Unfortunately, not many good ones. It looks like if you want speed, fast dynamic content and lots of configurability then Zeus Web Server is the only real option. The downside is that it's not open source and has a hefty price tag (although it is well worth it).

Boa is a nice, simple, fast web server that supports dynamic content through CGI's (so not much performance). publicfile's httpd is about the ultimate small, simple, fast and secure web server that supports only static content. If you must have a secure web server, this it (for example, defcon.org uses it). While it is a blocking server, it's small size (two data pages) should lead to performance comparable to that of larger, non blocking servers.

I love the screenshot for boa.

Apache is doing a thing or two besides just calling "Passenger index.html, please contact gate 80". There are other, faster httpds around that focus on this simple task, for example Boa. (the joke works much better in Finnish)

Apache would be MUCH faster if the Apache developers would give up on the outdated and innefficient method of using a separate process per connection, and went with a non blocking I/O model like Boa, thttpd or Zeus. A non blocking I/O model is much better, from many standpoints. It places the I/O handling back in the kernel where it belongs, reduces memory usage and drastically increases speed.

I've talked to a lot of people about this issue, and spent a lot of time reading through the Apache developer mailing list. The main reasons that come up is that Apache is meant to be correct first, fast second, and that it is harder for people to extend Apache because it makes the code more complicated. The first reason is invalid, because it's quite possible to make a web server correct and fast at the same time. The three web servers I mentioned prove this. And there are several more non blocking web servers out there. The I/O is a very small part. Given a proper design, everything else can easily work with that model. Extending it is not made any more difficult, because one would very rarely, if ever, modify the base I/O model. You have normal HTTP and HTTPS, and that's it. Anyone who would be extending that critical portition of the web server should be able to understand the conceptually simple concept of non blocking I/O, especially as it is explained very well in a variety of sources.

Strangely, right now I am in the middle of modifying one of these for a portable wireless application (The 2100, not the 2120). I was in the middle of debugging a C cgi program for the camera when this slashdot story appeared. :)

Sounds a lot like Boa.

--

It looks like all the main HotMail servers are running on Windows/IIS. However the image servers are not - http://216.32.182.251/ is running Boa. Now as far as i'm aware Boa only run on Unix-like operating systems...

Is it:

• A "hack" designed to make IIS look as stupidly slow on carefully "hacked-at" benchmarks as the IIS benchmarks make Apache look?

  No particular flaming intended here; in either direction, this represents "benchmarketing" as opposed to anything realistic.

  It may be as unrealistic to "real world" situations to use a highly tuned combo of TUX and Apache and make IIS "look sick" as it was for Mindcraft to use a heavily tuned IIS to make a poorly-tuned Apache look bad.

• Something that would be embedded into a sophisticated web application framework to make certain cases of page accesses run ravingly fast ?

  In which case someone building the next Slashdot might care, as they need to write finely-tuned code, whereas I, when running a lightly loaded web server at home, will have a hard time detecting differences between Roxen, Apache, Boa, and WN.

• Something that I could run in lieu of Boa as a tiny, fast web server?

This isn't quite a flame; it truly is important for a piece of software that you want people to use to be described in an economical manner that makes it easy for people to determine its relevance.

Is it:

• A "hack" designed to make IIS look as stupidly slow on carefully "hacked-at" benchmarks as the IIS benchmarks make Apache look?

  No particular flaming intended here; in either direction, this represents "benchmarketing" as opposed to anything realistic.

  It may be as unrealistic to "real world" situations to use a highly tuned combo of TUX and Apache and make IIS "look sick" as it was for Mindcraft to use a heavily tuned IIS to make a poorly-tuned Apache look bad.

• Something that would be embedded into a sophisticated web application framework to make certain cases of page accesses run ravingly fast ?

  In which case someone building the next Slashdot might care, as they need to write finely-tuned code, whereas I, when running a lightly loaded web server at home, will have a hard time detecting differences between Roxen, Apache, Boa, and WN.

• Something that I could run in lieu of Boa as a tiny, fast web server?

This isn't quite a flame; it truly is important for a piece of software that you want people to use to be described in an economical manner that makes it easy for people to determine its relevance.

Guesstimating some values (though stemming from real values, and rounded down on the conservative side), it seem that using boa, hftpd and standard NFS and Samba, you should be able to serve up at least 200 requests per second on a 486 DX4/100. So it shouldn't be useless, assuming you're just serving up static content (or very simple and/or cacheable dynamic content).

Anaconda kicks much tail.

Does anyone else notice a pattern here?

• Anaconda
• Asp and Asp 2
• Boa
• Bushmaster
• Caiman
• Cobra (Mk I and Mk III)
• Copperhead
• Coriolis
• Gecko
• Krait
• Mamba
• Python
• Sidewinder
• Viper 1 and 2
• Worm 1 and 2

Nominating companies or applications to match Hognose, Dodo, and Thargoid is left as an exercise to the reader.