Slashdot Mirror

Very very interesting. At first glance I would say you are talking about the old days of macintosh, with MacOS 8 and 9.
But that can't be true, I can't find the links, but over the years people have put up MacOS 8 Servers on the web to try to have somebody crack them, couldn't be done.
In fact, the U.S. Army switched it's web site(s) over to MacOS 8 Servers just for that purpose. (not sure if they still run them though)
They're so secure because of the lack of a command line interface. So you can't exactly telnet in.

But now onto MacOS X. You should do your reading on this one. MacOS X is based on FreeBSD (to a point), the same FreeBSD which runs many HIGH traffic web sites, Apache, Yahoo!, and (shameless plug) Tiger Site Development. I realize you're talking about the hardware, but come on, you're whining about how the FSB is too slow, and the motorola PPC, blah blah blah. You're missing the big picture, this server is in 1U That's dual CPUs, 4GB of RAM, up to 720GB of drive space, Gigabit ethernet, etc. In 1U! And don't forget Server Software included, finely tuned to the Server hardware.
If anyone wants to try to fit two Athlon MP's, or two Xeons in 1U, you can have fun frying eggs on that machine.

And since you are whining about the CPU being "too underpowered" it sounds like you're just looking at the Ghz. Ghz means something, but not everything, chip architecture is more important, that's why AMD, and Motorola's chips have a lower Ghz, they have better chip design, meaning they don'T have to jack up the frequencies (ahem Intel) to get performance.

These folks are already using it.

Try, uhm, torsion! Yea, that's not taken!

File size depends upon images and image sizes. For small images, such as bullets and file icons, the PNG images do typically end up bigger. This can be seen on most modern Apache installations. On the other hand, we are talking about a handful of bytes.

On larger images, PNG will typically do a better job. Unfortunately, I have found that not all applications default to maximum compression (such as GIMP). I have also found that not all applications provide significant options for using the format (such as Microsoft PowerPoint). I was able to get beyond such limitations by using pngcrush as a post processing step.

I particularly like to drop the text chunks because that removes the "created by application" and other comments imbedded into the image. My revision control system can handle differences, I do not need to add space to the image to record such information.

DHTML sucks to do stable and responsive UIs in. And even if you manage stable and responsive, you'll still end up with code like
if (netscape4) { ... }
all over the place.

DHTML sucks to do stable and responsive UIs in. And even if you manage stable and responsive, you'll still end up with code like
if (netscape4) { ... }
all over the place.

Oh dear, are you sure you were concentrating before?

What we are referring to here is the Dotnet Framework. Not just C#, not just the CLR or CLI, but the whole platform - the APIs that people write real applications on. Nobody is disputing that for Mono to be useful, it has to go beyond what has been made public and clone those parts that are private and patented.

The word "liable" is well chosen regarding Mono's position with MS - and those using it will be in just the same position legally as those creating it.

The situation with the Java Platform (to include J2SE, and J2EE if you like) is quite different. Not only are there already multiple vendors and dozens of separate implementations, but the legal position has been set forth in the JSPA (that link again, for the hard of memorizing). No equivalent exists for Dotnet whatsoever.

Thanks for the link regarding Mono's rationale. I encourage everyone to visit this page and evaluate the reasons stated. I'm afraid that when I looked I could only find the following rather contradicatory statements:

There is not really a lot of innovation in this platform: we have seen all of these concepts before, and we are all familiar with how these things work.

What makes the Common Language Infrastructure development platform interesting is that it is a good mix of technologies that have been nicely integrated.

The .NET development platform is essentially a new foundation for program development that gives Microsoft a room to grow for the coming years.

Now, regardless of whether the Mono people think that Dotnet is or is not an innovation, I think we are obliged to observe the rationale for their enthusiasm is less than one sentence long and rather vague. Given that Perl and Java could equally well be described as an interesting mix of technologies, that they were around a long time before Dotnet, and that the Mono proponents themselves admit that there is not a lot of real innovation in it, it is very hard to see how this aspirational fragment can add up to a convincing manifesto.

Regarding your analysis of other open source VM efforts, I again find myself unable to discern nuch of a coherent argument in your statements, despite your earnest entreaties. You appear to be against a multiplicity of similar efforts where Perl and Python are concerned, but apparently for multiplicity where Java, Mono and Dotnet are concerned.

I'm not particularly disappointed that you are unaware of original, innovative and preexisting OSS work in this area - the problem is that the Mono developers are unaware of them too, and prefer to subject themselves to Microsoft's leadership rather than work with those that share more compatible goals and methods.

Unfortunately, the casual reader might gain the impression from your post that Microsoft have made the whole of Dotnet public (around 1200 C# classes) rather than just C# and the CLR (around 150 classes).

I'm sure you will be as anxious as I am to clarify the true position, perhaps by mentioning Steve Ballmer's comments from March last year where he states that MS holds patents on Dotnet technologies and that free implementations will not be allowed, or by comparing the MS position with that of Sun and Java, which, under the JSPA explicitly permits free implementations.

I also remember that problem with Apache. Here's the report and the code change involved for that particular bug.

• huge developer base
• almost all universities teach it
• It works equally good (if not better) on linux and OS X
• JDBC - works equally well on all databases
• JBoss Hey it's free, and it's good.
• IntelliJ IDEA not free, but worth every euro!
• Jakarta community is unrivalled.
• ANT simply the best build tool.
• Options, options, options. No single vendor lock in.

• huge developer base
• almost all universities teach it
• It works equally good (if not better) on linux and OS X
• JDBC - works equally well on all databases
• JBoss Hey it's free, and it's good.
• IntelliJ IDEA not free, but worth every euro!
• Jakarta community is unrivalled.
• ANT simply the best build tool.
• Options, options, options. No single vendor lock in.

It does, but IE is lazy, and just says */* without assigning a quality value.

Here are some examples of the HTTP Accept header...

IE:
image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, application/x-shockwave-flash, */*

Mozilla:
text/xml,application/xml,application/xhtml+xml,tex t/html;q=0.9,text/plain;q=0.8,video/x-mng,image/pn g,image/jpeg,image/gif;q=0.2,*/*;q=0.1

Opera:
text/html, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1

You can use content negotiation. You leave the file extension off and let the browser choose which file format it wants. (W3C does this with some graphics) To get it work right with IE (And choose GIF over PNG), I had to assign a slightly lower quality level to PNG on the server. It ended up being more hassle than it was worth. It's been a while since I did it, but if I remember correctly, IE wouldn't cache anything using this either. So now I just use 8-bit PNG and pray for the day IE catches up.

better yet, use the Ant1.5 wrapper to wsdl.exe,

<wsdltodotnet> so that you can automate all this as part of your ant based build process.

Go read about mod_alias and redirect them to where ever you choose.

I've heard of people redirecting code red attacks to servers setup to cleanse them. Perhaps this is only an urban legend, but a damn clever/funny one at that!

The last sentence on the right of the main PHP page says:

PHP is a project of the Apache Software Foundation.

You're confusing one Apache propject (namely, the webserver) with the entire suite of Apache software.

So it make some sense putting it under the Apache section, though putting it under the Developers section as well as Apache, and PHP would have been a better choice.

What's next is waka. Really.

But HTTP 1.1 has been out a while, and there isn't anything really new on the horizon. This book will probably have a longer life than many.

perl.apache.org. This is the mod_perl site, nice docs, faqs, mailing lists and so.

masonhq.com This is the mason web site. Very well documented. There are also Mason Books

In addition mod_perl won't work well with apache2, it's still beta, so you better try with apache-1.3

Good idea. I am forced to use 1.3 for a project, and would love to be able to steal classes from later versions. We moved to 1.3 to get HTTP 1.1 support, but our production environment would have been greatly simplified if we had stayed with 1.2.

When we were faced with the same problem, we just went and used HTTPClient. Similarly, when we needed regexps in 1.3, we just went for the Jakarta ORO library. (And even in our java 1.4 environment, we're still using log4j)

Sure, it would be nice if Sun split the standard library from the runtime engine, but third-party java libraries are plentiful and can often cover the gaps. Also, if there's some new feature in a higher java revision that you can't live without, you might want to first check whether Sun also released a version of this feature that's compatible with the java version you're stuck with. (e.g. JSSE for java 1.2)

Good idea. I am forced to use 1.3 for a project, and would love to be able to steal classes from later versions. We moved to 1.3 to get HTTP 1.1 support, but our production environment would have been greatly simplified if we had stayed with 1.2.

When we were faced with the same problem, we just went and used HTTPClient. Similarly, when we needed regexps in 1.3, we just went for the Jakarta ORO library. (And even in our java 1.4 environment, we're still using log4j)

Sure, it would be nice if Sun split the standard library from the runtime engine, but third-party java libraries are plentiful and can often cover the gaps. Also, if there's some new feature in a higher java revision that you can't live without, you might want to first check whether Sun also released a version of this feature that's compatible with the java version you're stuck with. (e.g. JSSE for java 1.2)

Is it really possible to spend five days talking about an image format no one has ever used?

BuddyZoo has a nice use for SVG, you may have heard of it somewhere. I don't like the Adobe SVG Viewer but the Apache Software Foundation's Batik project is good for turning SVG into a nice (albiet big) PNG.

java -jar batik-rasterizer.jar FILE.svg

Although you might have to futz around with the svg code generated by to get it to work with Batik. Run it through an XML validator to see what I mean. (There is top level <svg> but two closing </svg> so delete the one that isn't at the end.)

But, in all seriousness. What settings/configuration am I missing by using IIS instead of Apache? I'm not asking "why is Apache better to set up" but "What can Apache do that IIS is missing".

For starters, have a look at the examples in the URL Rewriting Guide.

There are legions of other things. Have a look at the sample httpd.conf file that comes with the Apache distribution for lots of examples.

Apache's org.apache.jakarta.commons.lang package contains an abstract base class for typesafe enumerations (Enum), which contains a toString method and a readResolve method (to allow safe serialization of enumeration constants). The only disadvantage is that it also implements the Comparable interface, which sucks if you have an enumeration that doesn't really have a natural order.

Apache's org.apache.jakarta.commons.lang package contains an abstract base class for typesafe enumerations (Enum), which contains a toString method and a readResolve method (to allow safe serialization of enumeration constants). The only disadvantage is that it also implements the Comparable interface, which sucks if you have an enumeration that doesn't really have a natural order.

Sounds to me like they just slurped in XDoclet, just like they slurped in Log4J in the 1.4 release.

It's good to see enumerators formally supported, but you were not really _forced_ to use plain ints up to now. It is just some sort of an anti-pattern, which everybody seems to be using happily.

The type-safe enum pattern shows the correct way of handling enumerations. And you can the Jakarta Commons Lang library to make it a bit easier.

That's for sure. Everybody knows that Apache is the worst web server in the world, after all.</sarcasm>

Search enterprise linux.com has a four part series on open source support that might help.

For well known software just call it "industry standard software". This would include things like EMACS, CVS, GNUmake, gcc, Apache. Tell the management you would suggest using the Industry Standard Apache web server, or the Industry standard revision control tool CVS.

You could list examples of companies that use these tools already. You can get some examples of current corporate users at the home pages, or by e-mailing the support team. Concentrate on listing Fortune 500 companies, your company's competitors, and well regarded high tech companies.

Good Luck in your effort!

An Apache server with mod_proxy, HTTP basic authentication and mod_ssl should do the trick.

An Apache server with mod_proxy, HTTP basic authentication and mod_ssl should do the trick.

I spent the last year working on a project that used Torque as its persistence layer. It's OK when you've got a basic one object = one table model. (You can also map an object to a view.) It's fairly easy and fairly flexible, within a paradigm that assumes one table per class.

The mechanics of using Torque are that you define your objects using an XML schema from which it generates both code and SQL CREATE TABLE statements using ant tasks. It uses another Jakarta project (the Velocity template engine) for code generation.

Torque generates five classes. Three are basically internal and shouldn't be messed with. Of these, one is a helper class, one is a base class for the object, and one is a base for the table. (If you will, one class represents rows of the table and one represents the table itself.) The classes you actually use are subclasses of this, and are basically empty stubs to which you can add code. Torque is smart about not overwriting these if they already exist.

You can alter the base classes by changing the Velocity templates or by providing a class that the generated code extends. (This class must extend Torque's BaseObject class.) ISTR that it also supports tables that extend other tables, but we never needed to explore that.

Oh, it also provides its own connection pooling. This could be a problem if you're wanting to make use of application-server supplied transaction management (e.g. for managing distributed transactions.) We did prototype an interface to make it use XA transactions acquired from JBOSS, which worked in unit testing, but was never used in production because we didn't need the functionality.

My only serious caveats with Torque are that (a) it doesn't support SQL aggregate functions (min, max, sum, etc.), (b) it feels like it's designed for a fairly simplistic model where one web page equals one screen, and (c) the documention is a bit skimpy in places. Good for getting started but less helpful on the meaty problems. Not supporting aggregates is a nuisance; we had to drop down to JDBC for those (which Torque allows; just make sure you return the connection to the pool instead of closing it!) The one page = one screen paradigm was less of an issue, more just a sense of what it was originally designed for.

It also relies on a number of other Jakarta projects, which may be a problem in initially configuring it. We were using Turbine and some others, so I'm not sure just what would be involved in using it outside that context.

The other major caveat is that it has no caching, so if you fetch the same object twice you'll end up with two copies which is potentially a problem in a multi-threaded environment. However, this something you might expect to pay big bucks for. As a free product that provides a good and easily-maintained alternative to hand-rolling your JDBC interfaces, Torque is a pretty good solution.

See http://db.apache.org/torque

And this one is free for non-commercial use: Libelis

Also, there are a number of open source implementations that are "in-progress" -- Apache's Object Relational Bridge, etc.

This is one thing about Java that OSS advocates should appreciate -- open specs, multiple implementations. Standardising less than 10% of your APIs without commitment to allow competing implementations to the rest of the platform is simply showmanship.

JDO is a massive step up from EJB entity beans, giving you inheritance, sophisticated state behavior, fairly low overhead (especially at the object layer) and several advantages besides.

But JDO's goal, of insulating you from the database, means that you can't get to the database even if you need to. In my opinion, this limits JDO apps to the same "toy" class of applications that entity EJB's are limited to.

For instance, the way JDO stores a polymorphic reference is to store the object id and the object type (as a text string with the fully qualified class name) as two separate columns in the referrer's table. That's horrible in several ways (including db bloat and the fact that you've lost most of the ability to report against the database), but because the JDO spec refuses to let you give it any hints, it has very few other options. This particular problem made JDO infeasable for the last app I worked on (a security manager that pulled in 30-50 million snort events per day). JDO would have doubled the database size, on a database that grew at 2-3GB/day!

Other solutions, like Hibernate or OJB give you the ability to ignore the database if you so wish (by providing schema generating tools) but also give you the option of writing a great object model, writing a performant database schema, and then describing the best possible mapping between them. And believe me, when it comes time to make your application scalable to hundreds of simultaneous users and hundreds of millions of rows, you'll appreciate the ability to design the database yourself.

JDO's real problem is that it pretends that there's no need for relational programming now that we've got object oriented programming and it's another restatement of the object-oriented database. Relational programming has several distinct advantages over OO programming in several problem areas, the most obvious being arbitrary search (which the OO model intentionally prevents with encapsulation). True object relational mapping tools don't make this mistake. They let the object model do what it's good at, the data model do what it's good at, and then help them talk to each other.

One thing that JDO did do a good job of was the application interface. The query is nice and the rest of the semantics are clean. And luckily for the rest of the world, there's no reason why an ORM tool can't provide a JDO interface but do the mapping more intelligently. In all actuality, this is what will happen to JDO very shortly (if it already hasn't). The vendors will provide systems that comply with the spec and then customers will demand that they have more control over the db and mapping and each vendor will extend their implementation in some nonstandard way to give them that power.

Regards,
Ross

While JDO is interesting, the Apache OJB (Object Relational Bridge) project is even better. It provides a JDO implementation as well as an ODMG impelemtation and a low level PersistenceBroker API. Lots of choice. More than one way to do things, allowing the developer to trade-off make trade-off when they are appropriate. It is fully transactional and supports the latest JDO as well as ODMG specs.

And it can be used to persist objects transparently...you can set it up to persist objects you already have and completely control how the object relation mapping takes place in a few config files.

We've used it on projects since November, and I don't think we'll ever go back to Entity Beans. This project allows you to choose when you would like to use byte code enhancment techniques (JDO) or reflection techniques(ODMG) or even combine the two.

Best of both worlds.

Before you commit to JDO or entity beans, do yourself a favor and also look at OJB and Hibernate. Both of these object-relational mapping (ORM) tools offer unintrusive presistence to your existing beans (unlike Toplink and Cocobase which require you use their collection types) and don't require you to run a byte-code mangler like JDO.

Well guess what, some of the codebase is in apache. Probally not much at this point, but apache was derivied from a series of httpd patches. A-patch-e was a play on words to that fact.

Actually this is a myth.

I worked an an ISP where we had to make a couple of code tweaks to Apache. Worked great. Yeah Open Source. But then we all got into a debate about whether we had to go through the effort of making the whole thing available online since we were hosting some web sites for some local businesses.

Certainly not with Apache. It has its own license, not the GPL. The Apache License is very similar to the original (advertizing clause) BSD license. You're permitted to redistribute in binary only form if you want. The only restrictions are that you have to include the original copyright notice and disclaimer, can't call it Apache or claim endorsement by the Apache Foundation, and have to acknowledge the Apache Foundation in advertizing material.

Also, Torque from the Apache project is another good project to help with database design. You can genereate database from a custom XML schema.

You're right. It's just shameful that marketing thugs from huge software houses such as Apache and LTSP have strong-armed legislators in states such as Oregon and Texas to kill bills mandating consideration of proprietary alternatives where they exist. Let's not forget the evil licensing schemes that say "You must give this software to a friend or you cannot use it."

....using Maven's xdocs, you can generate both HTML and PDF docs from the same XML source file.

We use this on GForge and it works pretty well....

Tom

make does such, use ant

Like grepping a text delimited file and piping its output into awk or sed from a simple command prompt? Or storing that information in a simple system variable to be used by a C program compiled on gcc for whatever reason you need? How dumb is you!

Vs Windows 2000:

Right click on folder. Select search. Type text. Click "Search Now".

I already know which one is harder. Now which one is better?

It's Open Source bigshot college educated programmer, weren't you bright enough to FIX the problems or just whine because thats what you can do?

Someone already did. It is called OS X.

Riiiiiiiiiight, everything should work perfectly the first time with only minutes invested regardless of the complexity of the code and how many source/header files you are trying to link up with that makefile.

Or maybe someone could do it right.

Your attitude is the biggest weakness of Unix. Instead of trying to make Unix better, you blame the messenger for being "too stupid" to get it.

I think you want it to be harder because it makes you feel superior.

Personally, I could give a crap what about computer "religious wars". I've programmed in C, C++, Java, PL/SQL, Delphi, and more scripting languages than I can think of. I've programmed on UNIX boxes, Linux boxes, and Windows boxes. The only thing I care about is getting the job done in the best way possible.

Brian Ellenberger

As a matter of fact, I would argue the opposite. Any experienced programmer who is not using a "framework" or thinking about design patterns is a hack who is shortchanging his management and/or customers. Without the "meta-coders" you so malign, the software industry would be in a much worse state than it already is.

Oh, and I am a committer on the Apache XML-RPC project, which is written in Java.

Check out the Avalon project. If is a framework encompassing the ideas of Component Oriented Programming and Separation of Concerns.

Also, read about Aspect oriented Programming, which "modularize[s] crosscutting aspects of a system" by allowing a programmer to specify "aspects" of a class or component such as logging, security, remotability, and more.

Check out the Avalon project. If is a framework encompassing the ideas of Component Oriented Programming and Separation of Concerns.

Also, read about Aspect oriented Programming, which "modularize[s] crosscutting aspects of a system" by allowing a programmer to specify "aspects" of a class or component such as logging, security, remotability, and more.

Check out the Avalon project. If is a framework encompassing the ideas of Component Oriented Programming and Separation of Concerns.

Also, read about Aspect oriented Programming, which "modularize[s] crosscutting aspects of a system" by allowing a programmer to specify "aspects" of a class or component such as logging, security, remotability, and more.

mod_perl is supposed to be unstable, but this may be as much a myth as with PHP.

However, we do have one complaint and have filed bug reports which so far have been unresolved. (btw, prior to apache-2.0.39 we did not experience this problem)

A number of uses of SUN servers (we use ULTRAS and V100's) have noted that apache httpd children processes hang ocassionally. With prior than .45 releases we were seeing a hang a few times a week. With the .45 release we are seeing on average 3 to 5 hangs a day, so the problem has gotten worse.

This is not just our boxes - other people have confirmed the problem and the orginal bug report referenced above was actually opened not by me. I asked the original poster if they had problem too with the .45 version and they just upgraded last week and reported back that it also appeared to them to have the problem worse.

Specifically, a child will hang. If you connect via port 80 (e.g., telnet) to the child it answers, but when you type your line (e.g., GET /) it hangs upon carriage return and ALL the children then are hung in the same manner. There is no load associated with the hang, but the server stops responding FOR A PERIOD OF TIME to port 80 requests (e.g., they all hang). The server does seem to eventually recover - but not fast enough for our clients ;)

Both the original poster and myself have written watchdog programs which ping (mine pings every 5 seconds) the server and if the server doesn't respond it sends a KILL -USR1 signal (bascially a form of HUP) to the parent process. In 99.9999% of the cases this unsticks the parent and life returns to normal (note, there is no load associated with the hung children - e.g., load does not go up when the child hangs). In the .0001% of the cases where at least two consecutive KILL's don't unstick the parent we do a forced kill of all apache and restart it (again, automated by the watchdog).

THe other reporter is also using SUNS, so this might be particular with their 2.8 OS. Also, ALL of our suns exhibit it, regardless of apache config, etc.

Besides that, also note there are a few changes to the config so using your old config will PROBABLY result in apache bitch'n the first time you startup, but the changes are pretty minor (mostly things you don't need anymore).

XP home edition cannot be used as a webserver or fileserver.

What problem does Apache HTTP Server have when run on Windows XP Home Edition? Have you reported the bug?

You're missing something that just about everyone who talks about "the limitations of SMTP" misses: SMTP isn't limited. SMTP has a standard mechanism for introducing extensions such as cryptographically certifying mail servers, and mechanisms already exist to allow for fast, distributed key recovery and verification.

Reading the RFCs is a very good start to understanding how to solve this sort of problem. Giving everyone on the Internet (or at least all of the SMTP-sources) an Identity and then actually attaching a record of trust to those identities would be a wonderful idea, and does NOT require replacing SMTP. In fact, if you do it very, very carefully, it probably doesn't even require writing any (or at least very little) new code.