Slashdot Mirror

http://lucene.apache.org/java/docs/

Who places what types of meta tags in the documents? I don't understand the requirements.

Generally, Lucene does a good job. It's easy to learn and performance was fine for me and my data (~ 2 GB of textual documents).

Check out Apache's free Lucene engine, found at lucene.apache.org/. Lucene is a powerful indexing engine that handles all kinds of docs, and you can easily mod it to handle whatever it doesn't. It also allows custom scoring and a very powerful query language.

Given that the software was free to begin with, I am not sure that its a good idea to pursue additional penalties (especially monetarily)

"But at every step, it seemed our needs clashed with Rails' preferences. (Like trying to turn a train into a boat. It's do-able with a lot of glue. But it's damn hard. And certainly makes you ask why you're really doing this.)"

#2 - OUR ENTIRE COMPANY'S STUFF WAS IN PHP: DON'T UNDERESTIMATE INTEGRATION
By the old plan (ditching all PHP and doing it all in Rails), there was going to be this One Big Day, where our entire Intranet, Storefront, Members' Login Area, and dozens of cron shell scripts were ALL going to have to change..

Speaking of tastes: tiny but important thing : I love SQL. I dream in queries. I think in tables. I was always fighting against Rails and its migrations hiding my beloved SQL from me.

"Technology mapping can have a significant impact on the ability to actually implement the architecture. The wrong mapping can make adhering the architectural guidelines very cumbersome and sometimes nearly impossible."

copied from my blog

Rails is to Ruby as Symfony is to PHP. I've tried Symfony myself and real had a hard time getting my head around it, likewise I'd probably have the same problem with RoR only worse because I'm more attuned to PHP or Perl, I do find that by using the Smarty templateing engine and MDB2 Database API that what I'm working on has shrunk dramatically and is much easier to understand. There are several Perl equivalents on CPAN, that are probably more reliable and mature than the PEAR equivalents in PHP, I assume that the only reason they aren't used more is because embperl is more arcane to use than PHP.

and CGI programs running on a system with highly optimized forking win on this, in my opinion. And apparently in the Slashdot maintainers' opinions, since this website is coded in PERL

The important phrase is ... your patent license from such contributor... (emphasis mine). Compare that to Apache 2 License, which says in S3 ... any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed (again, emphasis mine).

Apache License v2.0 and GPL Compatibility

The Free Software Foundation considers the Apache License, Version 2.0 to be a free software license, compatible with version 3 of the GPL.

Despite our best efforts, the FSF has never considered the Apache License to be compatible with GPL version 2, citing the patent termination and indemnification provisions as restrictions not present in the older GPL license. The Apache Software Foundation believes that you should always try to obey the constraints expressed by the copyright holder when redistributing their work.

Apache License v2.0 and GPL Compatibility

The Free Software Foundation considers the Apache License, Version 2.0 to be a free software license, compatible with version 3 of the GPL.

Despite our best efforts, the FSF has never considered the Apache License to be compatible with GPL version 2, citing the patent termination and indemnification provisions as restrictions not present in the older GPL license. The Apache Software Foundation believes that you should always try to obey the constraints expressed by the copyright holder when redistributing their work.

IMHO the future direction taken with Kerberos should be merging the protocol into LDAP (e.g. for the future LDAPv4 revision of LDAP protocol).

Here's my rationale behind this: The problem with Kerberos being a distinct protocol from LDAP is that the distinction causes lots of confusion among the implementors, system architects, developers and administrators. This results in lots of cases where the two protocols are misused.

The correct distinction should be that you use Kerberos for authentication (that is, proving that a user is someone he claims to be) and LDAP for authorization (that is, given an authenticated user, determining information related to granting access to some resources - such as group memberships, possibly some application-specific ACLs etc) and for other data for which a directory is useful (hard to list all possible uses of LDAP, but e.g. mail aliases are a fine example).

But because the protocols are separate and very hard to setup together on a single authentication/authorization/directory server (or a group of servers!), people go along with only one of them, usually using LDAP for authentication instead of Kerberos (see mod_auth_ldap for Apache), effectively prohibiting themselves from implementing usable single sign-on

For an example, let's have a look at available OSS solutions. Apache Directory has Kerberos and LDAP integrated from the start, but it's painfully slow as a server at its current state. A mail server using LDAP for aliases can perform quite a bit of hammering on the LDAP server. MIT Kerberos cannot use LDAP databases. So doesn't Shishi Kerberos, although they plan implementing this in the future. That leaves us with Heimdal Kerberos. Heimdal requires the LDAP server to be on the same machine and support LDAPI connections. So that rules out Fedora Directory Server, whose stable version 1.0.4 doesn't support LDAPI yet (although the CVS development version recently got LDAPI support, finally).

I've tried setting up a Heimdal Kerberos server with OpenLDAP (with SASL2 daemon in the middle), and succeeded, but it was a royal pain in the *ss.

All HOWTOs I've found on the web described a brain-dead design where Kerberos maintains a classic file-based database on its own, separate from OpenLDAP database, and one has to make sure they both are in sync (because it's possible that one can have a user that the other doesn't). In such a setup replication is really troublesome and has to be done using 2 different channels and mechanisms (e.g. LDAP syncrepl + Kerberos' own redundant servers).

I wanted an integrated design, where Heimdal stores its data directly in OpenLDAP.
This way, I couldn't possibly create a Kerberos account without an LDAP account (well, I could if I omitted Kerberos objectclass and attributes, but it would be harder to do and easier to detect). Also, I could use only LDAP's replication mechanisms and easily provide fault-tolerant cluster of LDAP and Kerberos servers.

Unfortunately, the diagram for this setup looks quite daunting for a beginner implementor, as you can see for yourself.

There were also lots of gotchas:

• Heimdal can connect to LDAP as its database only using LDAPI - a networkless LDAP connection over UNIX domain socket. So you have to configure OpenLDAP in a quite non-standard way, and latest

Hopefully those of us at Yahoo! working on Hadoop (and its related project Pig) can help change this perception.

If you wanted all that stuff, minus rails, plus PHP it'd be the same difficulty to get set up, though, so I fail to see how this is relevant to the topic at hand. That's my only confusion with this, I guess.

Anyway, as for a setup script, I don't have one. I just compile and configure each individual piece of software by itself. It only needs to be done once, so a script doesn't seem necessary. Maybe I'm misunderstanding what you mean.

I am using WebDAV and SSL with apache. To compile those two in you need enable-dav and enable-ssl as configure flags. This is all in the Apache configure docs. Those plus the ones I mentioned previously for proxy balancer and you should be good to go. SSH is easily set up on debian-like machines with apt-get (apt-get install ssh). Mongrel is installed as a rubygem, and is actually far better than webrick as a testing server.

Xslt takes all the need to program & process display logic out of the server-side code

XSLT should only be used to transform backend XML into different XML or HTML. It should not be used for any kind of logic, processing, etc, because it doesn't perform nearly as well as a real programming language, and becomes very unreadable as soon as you deviate from simply applying templates and doing straightforward transformations.

I program in XSLT every single day, and I use a framework (Apache Cocoon) that is basically designed around XSLT transformations, and the most common problems I see, are caused by people trying to do complex stuff in XSLT. XSLT is really great. Really. But it's no substitute for Java.

Ant is not used at runtime, of course

Even better, Maven. Like CPAN/GEM/ANT and much much more all rolled into one.

Why should I have to mess with a classpath when I can just include references in a build file

I'm fond of the log4j library.

The fact that code released under the GPL can not be closed is a lack of freedom which BSD doesn't have.

Communistic in this case refers to the "community" and the high value that the GPL places upon keeping code available to the community as a whole - this is the principle of communism that I refer to: a higher value is placed on the rights of the community than the individual. GPL simply places higher values upon the rights of the community. BSD places high value on freedom to choose by the individual and the community.

The GPL's sad devotion to it's community (aka communistic) principle creates a lack of freedom and a number of serious adoption problems for many considering using, extending and modifying GPL'd software.

For example, lets say you take a BSD copyrighted program such as Apache, OpenBSD, FreeBSD, or any other large program and make some minor changes.

As someone who has published software licensed the same software under the GPL and the BSD it's clear that BSD trumps GPL rules at anytime - allowing software published in this manner to override any GPL'd rule, phrase, sentence, paragraph or concept

My understanding is that MS doesn't really care whether other people will implement the standard or not. Those 6000 pages they shat out and called a standard read like someone grepped the Office source tree for comments, removed all of the profanity and made the format serializable to xml.

In effect, the format seems to be horribly convoluted, since it evolved over the past 15 years (makes you admire the motivation of people working on OO.o or poi), and requires a large amount of reverse engineering. MS knows the standard is completely useless.

So why bother? This way they can tell governments like Massachusetts that their software won't create vendor lock-in - why, it's based off a standard approved by the ISO - and totally neuter a large body of arguments for switching away from Microsoft.

Why would you? No vendor lock-in (supposedly), already established (so switching has an inherent cost), etc etc. It's the best of both worlds. No politician - or major decision maker - will ever page through the standard themselves.

And if bad publicity on how shitty the standard is worked, we wouldn't be a few countries away from having the thing successfully fast tracked through the ISO in the first place.

While not disagreeing that product documentation could be better, have you seen the Wiki, and particularly http://cwiki.apache.org/WICKET/documentation-index .html ?

Its funny but I happen to think that Wicket is one of the better web frameworks available in the Java world today. Having used GWT I was really put off by the Javascript as 'bytecode' approach. Different strokes for different folks I guess.

While I agree that complex configuration files are a bane to development, I disagree with the assertion that J2EE requires them. ORM technologies like JPA are utilizing Java 5 annotations to declare configuration inline with code instead of XML. Frameworks like Wicket and GWT are providing developers with Java solutions to UI that are devoid of XML configuration, JSP, and markup-heavy implementations. IMHO, Wicket deserves to be called a breath of fresh air.

I do think it's a mistake for J2EE to include a particular view framework in its specification. JSF, while an innovation in the 90's, is simply a pig wearing lipstick compared to some of the new frameworks out there. Frameworks that, for example, are built on AJAX instead of including it as an afterthought.

I suppose the bewildering set of choices may be the root of the problem here. But if you make the effort to do your research, you'll find that many of your assumptions are incorrect.

try wicket. no xml, no navigation rules, not a single piece of code in your markup files (it's simply not possible), ALL logic is in the java files. no stupid bean mapping to forms, a component concept (oh, there i can download a tabbed panel component, let's do this) that actually works. it really is what i think MVC should be like.

and a very good api design, KISS, no overhead and all that core servlet stuff is hidden from you.

iBATIS

I find it like a halfway house between PreparedStatements and Hibernate. Works fine with existing schemas.

This module uses a rule-based rewriting engine (based on a regular-expression parser) to rewrite requested URLs on the fly. It supports an unlimited number of rules and an unlimited number of attached rule conditions for each rule to provide a really flexible and powerful URL manipulation mechanism. The URL manipulations can depend on various tests, for instance server variables, environment variables, HTTP headers, time stamps and even external database lookups in various formats can be used to achieve a really granular URL matching.

There's also an elephant in the room: The Apache config file.

In other words, IIS Gaining on Apache cost Americans $7 billion over the past two years.

Do your patriotic duty: Install Apache.

Perl.

Still, the administrator of a server running PHP 5 can get scripts to run without having .php in the URL by using various forms of content negotiation:

• With Options MultiViews, the client requests /download?foo=bar. Apache HTTP Server will look for a file called download, not find it, and then search for download.* and run the first thing it finds.
• Type-mapped negotiation in Apache works much the same way, except it uses .var files (similar to Windows shortcuts) that point to your script. For instance, /download?foo=bar would reference /download.var, which points to /download.php. It's useful if you have a lot of small requests, for which the repeated directory scans performed by MultiViews might become CPU-bound.
• Rename download.php to download/index.php, and Apache will find it when it scans index.* to display a default page for a directory.
• Last but not least, mod_rewrite.

Anyone have any experience with fake MX records?

I find the idea sort of intriguing, but I have doubts that it'll work for long in the ever-escalating arms race of spam...

here's a TLS extension, Server Name Identification (http://www.ietf.org/rfc/rfc4366.txt), and an HTTP Upgrade: header approach (http://www.ietf.org/rfc/rfc2817.txt).

I'd say there's a clear winner there. I don't think anyone thought RFC 2817 through. It suggests (though does not require) sending the initial request in plaintext (ugh), and there's no good mechanism to advertise the server support without penalty on first hit to a https URL (i.e., advertise in the URL or DNS records). Since no existing servers support it, this means for browsers to take advantage of it, they'd have to connect to existing servers on the http port, discover the lack of support, then fall back to normal https. So all sessions to existing https sites would be slowed down by at least two round trips (c->s SYN, s->c SYN/ACK, c->s request, s->c failure), or say 150 ms. I'll pass.

RFC 4366 is much better. No speed penalty - there's no need to advertise server support - the client can always send the option. The server ignores it if it doesn't understand, so without server support the status quo is maintained - the server admins shouldn't put more than one vhost on the same IP until they upgrade. When the client and server both support it, everything works fine. When the client doesn't support it, there's a security warning - about as good a failure mode as you're going to get with a protocol upgrade like this. And the client support is already there in the latest versions of Internet Explorer, Firefox, Safari, and Opera.

I think consensus is moving towards SNI, and a reasonable chunk of the browsers seem to support it (though OpenSSL does not yet until 0.9.9 comes around). The Apache project is also dragging its feet, waiting for a clear consensus towards one or the other, AFAICT.

I think the Apache people are waiting on OpenSSL 0.9.9. bug 34607 (copy'n'paste the URL; don't follow the referral from slashdot) has a patch with support, but it is not effective without OpenSSL 0.9.9. I'm looking forward to it myself...tempted to install a development build just to have this feature, but probably not a good idea to use untested security software.

I've killed some time on this since it's a pretty interesting idea. It turns out there are plenty outside the D and F range. It does seem to like pages with a single Flash object and not much else, so that's bad. It also makes some pretty arbitrary decisions which don't mean squat to many sites. There are some sites that get enough traffic that speed is a factor but not so much that a content delivery network is really necessary, for example.

I skipped the actual link and score on sites that are pretty much just representative of the sites around them. I wanted to include them by name, though, to show where they fall. I've stuck mostly to main index pages, and I've noted where I've gone deeper.

A: Google (99%), Altavista main page (98%), Altavista Babelfish (90%) (including upon doing a translation from English to French), Craigslist (96%), Pricewatch (93%), Slackware Linux, OpenBSD, Led Zeppelin site at Atlantic (100%), supremecommander.com, w3m web browser site (96%)

B: Apache.org (87%), the lighttpd web server (84%), Google Maps, which also got a C once (84% in most cases), Perlmonks (84%), Dragonfly BSD (85%), Butthole Surfers band page (81%), 37 Signals

C: One Laptop Per Child,, ESR's homepage, the Open Source Initiative (78%), Google News (73%), Lucid CMS (74%), Perl.org (75%), lucasfilm.com, Charred Dirt game

D: gnu.org, The Register, A9 (66%), kernel.org, Akamai (64%), kuro5hin.org, freshmeat.net, linuxcd.org, Movable Type (61%), Postnuke, blogster.com, Joel on Software (67%), Fog Creek Software, metallica.com, gaspowered.com, Scorched 3D (68%), id software (64%), ISBN.nu book search

F: MS IIS (49%), microsoft.com, msn.com, linux.com, fsf.org, discovery.com, newegg.com, rackspace.com, the Simtel archive (26%), CNet Download (29%), Adobe (58%), savvis.com, mtv.com, sun.com, pclinuxos.com, freebsd.org, phpnuke.org, use.perl.org, ruby-lang.org, python.org, java.com, Rolling Stones band page (56%), powellsbooks.com, amazon.com, barnesandnoble.com, getfirefox.com

My site for my company (96%) gets an A (no, I'm not going to get it slashdotted) which is pretty simple but has a pic and some Javascript on it. Several sites I have done or have helped design with someone else get C or D ratings.

DirectoryIndex directive handles default file to default to in a particular set of listed files, and will ONLY show all files in directory if there is no file found in the list AND Indexes directive is also present. DirectoryIndex

IANAL, but modifying URL's is not against the law as far as I know. But it's what is done with the found information in the modified URL(s) that could land you in crowbar hotel.

Given that the claimed vulnerability is in mDNSResponder, whose source is available under the Apache-2 license, and that we have a hint of what the vulnerability is ("proof-of-concept worm was able to reliably deliver root and was based on a variation of mDNSResponder vulnerabilities that Apple had previously patched" - the only one that I could think of was CVE-2007-2386) someone far smarter than I could find and patch the vulnerability before InfoSec Sellout's work is complete. Isn't F(and/or)OSS great?

Ooops, I almost forgot:
/*
      Hello World
      Copyright 2002 MillionthMonkey

      Licensed under the Apache License, Version 2.0 (the "License");
      you may not use this file except in compliance with the License.
      You may obtain a copy of the License at

              http://www.apache.org/licenses/LICENSE-2.0

      Unless required by applicable law or agreed to in writing, software
      distributed under the License is distributed on an "AS IS" BASIS,
      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
      See the License for the specific language governing permissions and
      limitations under the License.
*/


You're welcome, "World"!

"We would still be thankful for RMS though. "

Thank you, Richard!

Thank you, Richard!

Thank you, Richard!

Thank you, Richard!

Thank you, Richard!

Thank you, Richard!

Thank you, Richard!

Thank you, Richard! And happy birthday!

OK, that's three. We've only got 197 to go. If the point of this exercise is trying to determine how many applications are being used, then from that perspective they're all instances of Firefox.

Your approach answers one particular question, how many different versions of how many different applications are we using? That obviously matters in some cases like license management, but if the question is more along the lines of "how many open-sourced applications are we running," then I don't think versioning is all that relevant.

I'm not trying to argue about what's "fair," I'm just wondering how we get to 200. Let's suppose that your company has three or four different versions of every open-sourced application running. That still works out to something like 50-70 different applications which seems to me to be pretty high number. Particularly when most anecdotal evidence suggests that open-sourced applications are a rarity in many companies. It's taken me quite a while to convince my (small business/nonprofit) clients to adopt one or two of the most commonly-used open-sourced applications like Firefox, Thunderbird, and OpenOffice.

The only way I see getting to a number like 200 is if you count *nix servers. And, then, 200 is probably too small a number especially in Linux shops.

BTW, their list of discoverable software (XLS) doesn't include any versions of Firefox before 2.0.0 and doesn't list Thunderbird at all. On the other hand, they do list a number of different versions of server software like Apache (8 versions) and MySQL (17). This tends to confirm my original conjecture that a lot of the software counted toward this 200 figure is running on servers, and yes, they're probably counting different versions as different instances. There are also a lot of packages that are likely to be relevant only to development shops. Just going through the A's and B's required me to look up some things like activemq (about 80 versions), berkano (about 100 versions), and bouncycastle (about a dozen).

So I guess I'd conclude that this product might be highly relevant to development shops and server managers, but much less relevant for determining what's running on the desktops of firms outside the IT industry.

It wouldn't surprise me if this is a direct result of the work on open-source optical character recognition being done specifically to prevent the increased prevalence of captcha-style image spam. It would be rather ironic if the open source model meant the spammers are now turning our own anti-spam tools around and using them against us.

Apache is a bad example, as Apache isn't under the GPL. It's under the Apache license, version 2.

Oops! You said "quick" and ".htaccess" in the same sentence. From Apache's own documentation, .htaccess files are a last-ditch solution for when you don't control the server and can't edit its config files directly. Really, if you can help it, don't ever use them.

Oh, if you use some web application that comes with a bunch of .htaccess files that you don't want to manually merge into your httpd.conf (or included files), you can use the Include directive to pull them into you config file once rather than forcing httpd to look for them each time a page loads. For example, replace:

<Directory "/usr/local/www/myapp/files">
AllowOverride All
</Directory>

with:

<Directory "/usr/local/www/myapp/files">
AllowOverride None
Include /usr/local/www/myapp/files/.htaccess
</Directory>

Once you've done that everywhere, set "AllowOverride None" in your main httpd.conf file and make sure it's not overridden anywhere else.

Oops! You said "quick" and ".htaccess" in the same sentence. From Apache's own documentation, .htaccess files are a last-ditch solution for when you don't control the server and can't edit its config files directly. Really, if you can help it, don't ever use them.

Oh, if you use some web application that comes with a bunch of .htaccess files that you don't want to manually merge into your httpd.conf (or included files), you can use the Include directive to pull them into you config file once rather than forcing httpd to look for them each time a page loads. For example, replace:

<Directory "/usr/local/www/myapp/files">
AllowOverride All
</Directory>

with:

<Directory "/usr/local/www/myapp/files">
AllowOverride None
Include /usr/local/www/myapp/files/.htaccess
</Directory>

Once you've done that everywhere, set "AllowOverride None" in your main httpd.conf file and make sure it's not overridden anywhere else.

Most open source offerings are tools (ie. databases, operating systems, etc.) and there is room for only so many tools, but there is a need for as many specialized business applications as there are types of business and it is possible to make money on those because businesses will pay for solutions, not tools. The Apache Open for Business Project (http://ofbiz.apache.org/) is truly disruptive technology in this regard. It is a brilliantly designed framework for developing apps and it comes out-of-the-box with working enterprise level software. It takes a while to learn the environment, but it is so rich that it makes knocking off vertical apps a breeze once you know it. It is Java based, but also has a strong XML-based scripting environment that makes it possible for domain experts, not just Java gurus, to develop apps. Developing an application for a small business and making money on it helps both you and the small business. I think this model has the potential for delivering much more on the promise of open source than anything that is out there.

Writing a voting app for the Java platform does not make the platform irrelevant. It makes the platform Java. If your JVM implementation is closed-source, you're left with the exact same problem, just abstracted a little more.

Of course, there are open-source JVMs and SDKs, with Sun's own not far behind. But you still have to make sure that the source of every layer between the JVM and the hardware is also open, or else there's nothing stopping it from waylaying data on its way to the filesystem or something. If it's GNU/Linux, then you're probably okay. But just to be safe, better make sure the firmware/BIOS is also open source, because sneaky changes to data at that level would be awfully hard to track down.

Oh, and while you're at it, don't just compile all of this fresh. Make sure you recompile the compiler first, using a trusted compiler that you compiled from a trusted compiler, etc., so that there's no chance of a hack like the one Ken Thompson put into UNIX. The moral of his story bears repeating here: "You can't trust code that you did not totally create yourself. (Especially code from companies that employ people like me.)"

Sorry. I like Java and the notion of write once, run anywhere. But don't think that adding an extra layer between OS and application makes the platform irrelevant in such a mission-critical sense. There's no substitute for full transparency, and even the definition of "full transparency" is not always as simple as it should be.

Openbravo is a fork of Compiere, so I'm not sure why they would appeal to different market segments. Also, Opentaps is a fork of Ofbiz, which is an Apache Foundation project. Thanks for the list though, some of those look pretty interesting.

And this one suggests it still was as recently as late '05, so it seems to really be a recent change.