The main problem with this is that then ALL your pages have to be JSPs, because any static HTML will not have the right sessionId parameter. If the user goes to any static page, then follows links back to a JSP page, the session will be lost.
Ok, so MP3 streams CDs. That is equivalent to "repackage it in a different case (or copy it to tape, etc.)". Then MP3 gives it to someone else. So, they *are* doing exactly what he said, which is wrong. ----------
Just because it can be done doesn't mean it should be done.:)
I've done web sites in Perl. Any language can be abused, but for large systems, it is much, much easier to write hideous spaghetti code in Perl than it is in Java. And I hardly call Perl's object oriented "features" (i.e. hacks) appropriate for larger systems, especially when compared to Java, which may not be perfect, but it's certainly a big improvement.
I love Perl, and think it's the greatest thing since sliced bread. But right before a big marathon, I'm going to need a heck of a lot more than sliced bread... ----------
Since when do you need to have multiple server architectures run the same code?
Ever since there was more than one server architecture to choose from. Solaris, Linux, AIX, Windows...
PHP does that. Perl does that (I think.) Cold Fusion does that.
I doubt PHP has the CORBA and Microsoft COM support Java has. (E.g. does Microsoft provide tools to wrap COM/Java around Java/COM? Didn't think so.) ColdFusion is in a different class of solution altogether, it doesn't compete with Java on the large application scale, and coming to think of it, neither do Perl or PHP.
Java IS slow.
I never said otherwise.
I'm on a AMD K6-2 350 and a Java Hello World took about 3 seconds to respond to a "destroy" request. Most programs take around 1 second. A slightly larger program is slow enough to be unusable.
Java JVM startup time is completely irrelevant to this discussion. We are talking server side, where you startup the JVM once. Java still has problems there, but you are speaking of startup time as a big deal, and it is simply not an issue on the server. ----------
This is slightly off-topic. Can PHP put code outside the HTML page, and then the HTML page only has PHP tags that make function calls to the PHP code outside it? This can be done in JSP (JavaServer Pages), so you don't have to put all your logic on the same file as your HTML. ----------
Cross platform. Yes, on the server, the cross platform promise of Java works.
Integration with other languages and platforms, such as CORBA, Microsoft COM, etc.
The Java performance problem is usually not such a big deal on the server, and is addressed by throwing more hardware at it. For well-funded companies racing against Internet time, the above advantages make the extra money thrown at hardware a no-brainer decision.
Note that I'm not comparing Java to PHP or Perl, because the category of problems each is suited for is different. For large enterprise systems, C, C++, and Java are your choices. For smaller, script-driven type sites, PHP and Perl are more appropriate. ----------
A lot of Internet companies don't focus on making their code as super efficient as possible because it is far more important for their code to be completed as quickly as possible. To deal with performance, it is easier to throw hardware at it.
Yes, it is more expensive. But, many companies are racing to be the first for survival, and they have been blessed with enough VC money, so that it is irrelevant that it takes hundreds of thousands of dollars to pick up the performance. Time to market is much more important, and having programmers spend time performance tuning takes away from that.
One clear example here is Java vs. C++. Sure, Java is much slower than C++; but developing something in Java takes orders of magnitude less time than in C++. So, it is better to throw money at hardware to cure the performance problem, but will get you to market sooner, than code in C++, which results in faster code, but takes much longer.
Of course it's not quite this simple. You can't just throw hardware and money at every problem. Obviously your application can't be so slow that no one will use it. And key performance problems are first at the high architecture level, which are mostly language and platform independent. You will always have to spend time performance tuning at some point. But initially---even long term---time to market is more important. ----------
Re:Stability and reliability
on
GUADEC Reports
·
· Score: 2
The latest, stable release of GNOME, the October release, is very stable. I haven't had it crash on me once. I've been using GNOME since the 0.33 days, when it used to crash every couple days, if not every day... ----------
The Open Source/Free Software movement definitely needs more political clout. RMS has created movements like the Leage for Programming Freedom and the Free Software Foundation, but these entities lack legal power.
There are a few problems with making this happen:
Need for strong, politically savvy leaders. This is hard; most current open source leaders are not very politically savvy, at least not in the traditional sense. Note that I'm making a distinction between being political in the sense of being able to make things happen in Washington, vs. being political in terms of being an effective open source advocate.
Money. This is needed to fund a political movement. There is no way around this. This is one of the weakest links.
Coordination of causes and remedies. There are a few things most of us will probably agree with, but with the variety of opinions/religions within Open Source, fragmentation would be a very big problem. Also, right now there are many avenues for common causes, which splinters common efforts, even if everyone agrees.
I think what it will really take is some top people in the community to create some sort of global, formal organization to create a political voice, where there is membership, with associated dues, and all other associated items like voting, etc. However, due to the splintering issues I mention above, I see this as unlikely.
I'd love to hear what ESR and RMS, two top candidates for forming something like this, would have to say... ----------
Though I have a hard time agreeing with a decision that allows low lifes to outright lie, cheat, and steal others resources, the real solution to this is clear: this law needs to be passed at the federal level, so that it affects all 50 states. Then, there is no restriction on commerce, and there is only a law prohibiting lying and cheating while sending commercial email.
Of course, this is easier said than done... but that's what really needs to happen. There are too many holes with anti-spam laws being passed on a state by state basis, and this case brings out potentially the biggest one. Hopefully it will result in a positive result (i.e. moving such a law to the national level). ----------
Symantec doesn't own the copyright on each individual URL, as individual URLs. It owns the copyright to an encoded list of URLs which is part of their program. This is what was published. ----------
Ok folks, this entire episode stinks of sensationalism. As far as I can tell,
This is is a copyright violation issue. The list of encrypted URLs was posted. This is copyright material. Period. To its credit, Peacefire has removed the link, which satisfies this complaint. But Symantec still was in the right here.
This is definitely also a reverse engineering issue. Symantec clearly stated in the letter that Peacefire had not been given "permission" to decode the list. In this regard, this does become a sticky legal issue that Peacefire is correct in raising.
Privacy: Symantec is violating its privacy policy. However, as Peacefire states, the software was manufactured by URLabs, which may have had a different policy than Symantec, so we must be careful in claiming malice on their part. The violation must still be corrected though.
However, Peacefire, and everyone here on Slashdot, is immediately jumping on the "Symantec is evil" bandwagon, where in reality Symantec in the letter did not mention, at all, the claims of failure rate. Symantec clearly stated concerns over a valid copyright violation, and a legally debatable claim to prohibiting reverse engineering.
Yes, you can extrapolate that Symantec is not happy with this disclosure. But just blindly posting parts of their code was stupid. To say in this article that Peacefire clearly did not post copyright material is WRONG and muddles discussion of the real issue, which is simply reverse engineering. A valid, important issue, worthy of discussion, no doubt. But as with so many other things on Slashdot, people are quick to jump to conclusions without thoroughly reading what has actually happened. ----------
Slashdot is the most unreliable site I visit on a regular basis. Throughout the day, page loads can take several seconds; sometimes not, sometimes longer, sometimes not accessible at all. This has been the case both in the East Coast and the West Coast (I just moved from one to the other). Note that in the East Coast, I had an extremely fast cable modem that was faster than most T1 connections I've had at actual companies, and in the West Coast, it's been through actual T1s. Also, I compare to other sites at the same time that Slashdot is slow.
No, I'm not flaming Slashdot; I love everything else about the site. But its accessibility unfortunately didn't improve with the Andover.net takeover, nor through any of the other changes that have been happening in the last two years.
I'm sure other people's mileage will vary, I'm interested in hearing other people's experience. ----------
You didn't finish reading the article. The very next paragraph says:
Corel also complained it couldn't provide conversion costs because the department wasn't supplying enough information.
That implies the problem isn't really the requirement to provide upgrade estimates, but that the department was slack in providing enough information to make the estimates. ----------
I'm guessing Miguel won over Knuth because Knuth has already been recognized a million times over for his contributions, and his contributions are not as recent as Miguel's. In other words, these awards aren't life time achievement awards; they are more for recent events. In recent times, Miguel has had much more of a direct impact than Knuth has.
Though I agree, it does seem weird to pass over Knuth in favor of Miguel. (No offense, Miguel, you and your contributions to GNOME and free software rock.:) ----------
I'm not sure who the original author of this is... there's a link to it here.
There it is again. Some fool ranting about the information superhighway. It's nothing like a superhighway. That's a rotten metaphor. But suppose the metaphor ran the other way. Suppose highways were like the Net...
A highway hundreds of lanes wide, most with pitfalls for potholes. Privately-operated bridges and overpasses. No highway patrol. A couple of rent-a-cops with broken whistles on bicycles. Five hundred-member vigilante posses with nuclear weapons. A minimum of 237 ramps on every intersection. No signs. Wanna get to Ensenada? Holler out the window at a passing truck to ask directions. Ad hoc traffic laws. Some lanes would vote to make use by a single-occupant-vehicle a capital offence on Monday through Friday between 7:00 and 9:00. Other lanes would just shoot you without a trial for talking on a car phone.
AOL would be a giant diesel-smoking bus with hundreds on board throwing dead wombats and rotten cabbage at other cars, most of which have been assembled at home from kits. Some are built around 2.5 horsepower lawnmower engines with a top speed of 9mph. Others burn nitro-glycerine and idle at 120.
No registration plates. World War II nose art instead. Terrifying paintings of huge teeth or vampire eagles. Bumper-mounted machine guns. Flip somebody the finger on this highway and get a white phosphorus grenade up your exhaust. Flatbed trucks cruise around with anti-aircraft missile batteries to shoot down the traffic helicopter. Little kids on tricycles with squirtguns filled with hydrochloric acid switch lanes without warning.
No off ramps. None.
Now that's the way to run an interstate highway system.
I much prefer this analogy to all these fancy shmansy theories.:) Either that, or the old "How the Internet is Like a Penis"... ----------
But can they seriously boost Mozilla? One of the tenets I've always had rehearsed at me (and reinforced by personal experience) is that it's hard to speed up a project just by throwing more developers & cash at it.... isn't everybody who's going to work on Mozilla for the right reasons already working on it?
From the article:
"We were at a certain phase [early this year] where more people working on the project wouldn't have meant more progress," said Mitchell Baker, chief lizard wrangler for Mozilla, in Mountain View, Calif. "Now... we're at a place where the number of developers who can effectively participate" can grow, Baker said.
So it seems like the time is ripe for some extra help, especially dedicated (i.e. full-time) help like the kind RedHat can hopefully provide. ----------
Hear hear! We don't need another desktop. It should be optional, ideally not there at all. I also am pretty annoyed by the MDI interface. StarOffice also needs to be a bit leaner and faster...
Anyone have any technical info on StarOffice, like what language it is written in, and more importantly, does it use some sort of porting kit to make it cross platform (this might explain its bloat)? ----------
I understand what you're saying. However, those examples are not contrived. Those are pretty close to real variables from real code I had to work with. Actually, they were part of the 2100+ line function that I referred to in my first point. By the way, I replaced the 2100 line function, with its obfuscated naming conventions, which wasn't completed and didn't work at all, with 12 functions over 718 lines of code---over 20% comments---that the project manager, a non-coder, looked at and said "Hey! I can understand this! And it should work!" And it did.:)
In any case, your point is well taken, that Hungarian notation is not as obfuscated as my not-so-contrived example makes out. My only experience with it however was on this one project which did have such convoluted examples. Hopefully my example speaks to the broader issue of useful variable naming, not just Hungarian notation. ----------
That "rule" is actually a good one. Except it should be more of a guideline, than a strict rule. The idea is a good one, which is to keep code in logical, relatively small and coherent modules. Going overboard to forcing it to exactly 25 lines (or any exact number), for all code, is bad. ----------
WARNING: 20 years of looking at, fixing and replacing bad code about to be vented...
Put all your code into a single function. (I've seen functions over 2000 lines in length.) After all, those nasty functions generate overhead on each call, and you want your code to be efficient right?
Use hungarian notation for variables. Then instead of the overly verbose
int numLinePayments; char *maxTypeCode;
you have the nice and compact
int iNmPt; char *szTyC;
BONUS: With compact hungarian notation, you can become even more descriptive! So really the above becomes:
int iLnNmMtCsByPt; char *szMxQtBlTyAcC;
So much more descriptive information, all in the same amount of space. I've been on projects using this, and the sheer of joy of it cannot be accurately described in words.
Don't indent your code uniformly. (This is a variation on #11 from the article.) Use Windoze or vi editors, with non-standard tab widths, for tabbing and indenting, which means that no one can see your code indented properly unless they use the same tools you use, with your same editing configuration.
BONUS: Write extremely long lines of code, well over 80 characters per line.
If using C or C++, don't use memory analysis tools like Purify, or its open source equivalents. After all, if you find your bugs too quickly, you might lose your job.
On large projects with several programmers, make sure you change global header files that cause everybody else's code to break but yours. Do this late in the afternoon, so all hell breaks loose breaks right before people are going home, or late at night, so that everybody comes in fresh the next morning and wonders what the hell happened to the code that compiled perfectly when they left the day before. Either way, make sure you are not around when they find out! Otherwise you spare them the joy of figuring out what you changed, and why.
BONUS: Do this right before a major deadline.
Do really stupid stuff that you were taught from day 1 not to do, but everyone seems to do anyway: don't check for NULL, fix array sizes where you hardcode the max size everywhere, don't check for invalid or oversized input, etc.
Use preprocessor macros. Lots of them. (I was actually on a project where someone suggested using cpp to define macros. For Java. Absolutely brilliant!) The key is to use a single macro for multiple statements, in effect using macros as function calls. Example:
#define DO_STUFF(x,y,z) if (x else more_stuff(z); \ mystery(a*2, z-1); \ for (int n = x; x != foo; x--) \ more_stuff(n - x);
Notice the "hidden" use of external variables and functions. Remember, you want to avoid those expensive subroutine calls! And think of the joys of setting breakpoints and stepping through a debugger on that code!
BONUS: Don't use the all uppercase convention in macro names; use the same naming convention as function calls. It's even more fun to debug when you have to spend time actually figuring out do_stuff() isn't even a function call!
MORE BONUS: Nest macro calls. Use the naming convention above.
EVEN MORE BONUS: Use macro calls as variables. Make sure the expanded macro makes function calls. Or uses other macros.
Don't use source code control. Or, use it, but never unlock or checkin your files. Feel free to steal locks on others, though.
And finally, one of my favorites, for all the young and aspiring hacker types out there:
Write code only for yourself. Assume no one will ever need to figure out how to use your code without poring through it in painstaking detail. Do not make it easy to use, interface with other code, or even compile. Include 30 caveats that would take you only a few minutes to fix, but you're just too lazy to. In other words, write as if no one will every look at or use your code, yet release it to everyone to look at and use. Defend your laziness, which is causing thousands of lost hours of work to others, by uttering useless and stupid "cool hacker" mantras like "Real Programmers don't write documentation" and "If it was hard to write, it should be hard to understand."
Phew. That little tirade made me feel good.:) ----------
Strictly based on the domain purdueonline.com, you are not on good legal ground. The University has a good case for trademark infringement.
However, if other sites exist with the "Purdue" name in them, and Purdue University has not threatened or sued them, their stance is shaky. I am not a lawyer, but my understanding is that if you have a trademark, and don't defend it uniformly, then to some degree you lose rights to it.
Another thing to consider, which potentially weakens their stance, is other businesses which have the Purdue name, but are unrelated to Purdue University. (I'm not talking domain names, but business names outside of the Internet.) The Purdue brand for chicken comes to mind. In other words, if Purdue is associated with several well-known businesses then the University's claim to anything with "Purdue" in it is greatly weakened. Since your site deals directly with the Purdue University, I'm not sure how much this counts.
In any case, the best advice is what's been stated by others: communicate with them and try to find an alternative. You're not on great legal ground to fight them. ----------
RedHat has always provided options to buy commercial software packaged with RedHat Linux. RedHat has been providing Motif for years, also CDE, in addition to the non-free examples mentioned in the previous post.
I think that it's perfectly legit (i.e. non-hypocritical) for RedHat to sell their basic RedHat Linux system, which comprises all free software, and then to additionally sell more commercialized versions which include non-free software.
Note that RedHat has in the past included non-free software on their CDs, but it's only on the CD that you buy (i.e. it's not available via FTP), and it has been non-core parts of the OS. (The flak over KDE was because KDE was a core OS component, and therefore it was dangerous to support it.) ----------
Slashdot Mirror
Anyone know any way around this?
----------
Ok, so MP3 streams CDs. That is equivalent to "repackage it in a different case (or copy it to tape, etc.)". Then MP3 gives it to someone else. So, they *are* doing exactly what he said, which is wrong.
----------
People use Java with servlets and/or JSP, which starts up the JVM once, so the JVM startup time argument is irrelevant.
----------
Where does Sun say this?
----------
I've done web sites in Perl. Any language can be abused, but for large systems, it is much, much easier to write hideous spaghetti code in Perl than it is in Java. And I hardly call Perl's object oriented "features" (i.e. hacks) appropriate for larger systems, especially when compared to Java, which may not be perfect, but it's certainly a big improvement.
I love Perl, and think it's the greatest thing since sliced bread. But right before a big marathon, I'm going to need a heck of a lot more than sliced bread...
----------
----------
This is slightly off-topic. Can PHP put code outside the HTML page, and then the HTML page only has PHP tags that make function calls to the PHP code outside it? This can be done in JSP (JavaServer Pages), so you don't have to put all your logic on the same file as your HTML.
----------
- Much, much easier and robust than C or C++.
- Cross platform. Yes, on the server, the cross platform promise of Java works.
- Integration with other languages and platforms, such as CORBA, Microsoft COM, etc.
The Java performance problem is usually not such a big deal on the server, and is addressed by throwing more hardware at it. For well-funded companies racing against Internet time, the above advantages make the extra money thrown at hardware a no-brainer decision.Note that I'm not comparing Java to PHP or Perl, because the category of problems each is suited for is different. For large enterprise systems, C, C++, and Java are your choices. For smaller, script-driven type sites, PHP and Perl are more appropriate.
----------
Yes, it is more expensive. But, many companies are racing to be the first for survival, and they have been blessed with enough VC money, so that it is irrelevant that it takes hundreds of thousands of dollars to pick up the performance. Time to market is much more important, and having programmers spend time performance tuning takes away from that.
One clear example here is Java vs. C++. Sure, Java is much slower than C++; but developing something in Java takes orders of magnitude less time than in C++. So, it is better to throw money at hardware to cure the performance problem, but will get you to market sooner, than code in C++, which results in faster code, but takes much longer.
Of course it's not quite this simple. You can't just throw hardware and money at every problem. Obviously your application can't be so slow that no one will use it. And key performance problems are first at the high architecture level, which are mostly language and platform independent. You will always have to spend time performance tuning at some point. But initially---even long term---time to market is more important.
----------
The latest, stable release of GNOME, the October release, is very stable. I haven't had it crash on me once. I've been using GNOME since the 0.33 days, when it used to crash every couple days, if not every day...
----------
There are a few problems with making this happen:
I think what it will really take is some top people in the community to create some sort of global, formal organization to create a political voice, where there is membership, with associated dues, and all other associated items like voting, etc. However, due to the splintering issues I mention above, I see this as unlikely.
I'd love to hear what ESR and RMS, two top candidates for forming something like this, would have to say...
----------
Of course, this is easier said than done... but that's what really needs to happen. There are too many holes with anti-spam laws being passed on a state by state basis, and this case brings out potentially the biggest one. Hopefully it will result in a positive result (i.e. moving such a law to the national level).
----------
Symantec doesn't own the copyright on each individual URL, as individual URLs. It owns the copyright to an encoded list of URLs which is part of their program. This is what was published.
----------
- This is is a copyright violation issue. The list of encrypted URLs was posted. This is copyright material. Period. To its credit, Peacefire has removed the link, which satisfies this complaint. But Symantec still was in the right here.
- This is definitely also a reverse engineering issue. Symantec clearly stated in the letter that Peacefire had not been given "permission" to decode the list. In this regard, this does become a sticky legal issue that Peacefire is correct in raising.
- Privacy: Symantec is violating its privacy policy. However, as Peacefire states, the software was manufactured by URLabs, which may have had a different policy than Symantec, so we must be careful in claiming malice on their part. The violation must still be corrected though.
However, Peacefire, and everyone here on Slashdot, is immediately jumping on the "Symantec is evil" bandwagon, where in reality Symantec in the letter did not mention, at all, the claims of failure rate. Symantec clearly stated concerns over a valid copyright violation, and a legally debatable claim to prohibiting reverse engineering.Yes, you can extrapolate that Symantec is not happy with this disclosure. But just blindly posting parts of their code was stupid. To say in this article that Peacefire clearly did not post copyright material is WRONG and muddles discussion of the real issue, which is simply reverse engineering. A valid, important issue, worthy of discussion, no doubt. But as with so many other things on Slashdot, people are quick to jump to conclusions without thoroughly reading what has actually happened.
----------
No, I'm not flaming Slashdot; I love everything else about the site. But its accessibility unfortunately didn't improve with the Andover.net takeover, nor through any of the other changes that have been happening in the last two years.
I'm sure other people's mileage will vary, I'm interested in hearing other people's experience.
----------
----------
Though I agree, it does seem weird to pass over Knuth in favor of Miguel. (No offense, Miguel, you and your contributions to GNOME and free software rock. :)
----------
I much prefer this analogy to all these fancy shmansy theories. :) Either that, or the old "How the Internet is Like a Penis"...
----------
From the article:
So it seems like the time is ripe for some extra help, especially dedicated (i.e. full-time) help like the kind RedHat can hopefully provide.
----------
Anyone have any technical info on StarOffice, like what language it is written in, and more importantly, does it use some sort of porting kit to make it cross platform (this might explain its bloat)?
----------
In any case, your point is well taken, that Hungarian notation is not as obfuscated as my not-so-contrived example makes out. My only experience with it however was on this one project which did have such convoluted examples. Hopefully my example speaks to the broader issue of useful variable naming, not just Hungarian notation.
----------
That "rule" is actually a good one. Except it should be more of a guideline, than a strict rule. The idea is a good one, which is to keep code in logical, relatively small and coherent modules. Going overboard to forcing it to exactly 25 lines (or any exact number), for all code, is bad.
----------
- Put all your code into a single function. (I've seen functions over 2000 lines in length.) After all, those nasty functions generate overhead on each call, and you want your code to be efficient right?
- Use hungarian notation for variables. Then instead of the overly verbose you have the nice and compact
- Don't indent your code uniformly. (This is a variation on #11 from the article.) Use Windoze or vi editors, with non-standard tab widths, for tabbing and indenting, which means that no one can see your code indented properly unless they use the same tools you use, with your same editing configuration.
- If using C or C++, don't use memory analysis tools like Purify, or its open source equivalents. After all, if you find your bugs too quickly, you might lose your job.
- On large projects with several programmers, make sure you change global header files that cause everybody else's code to break but yours. Do this late in the afternoon, so all hell breaks loose breaks right before people are going home, or late at night, so that everybody comes in fresh the next morning and wonders what the hell happened to the code that compiled perfectly when they left the day before. Either way, make sure you are not around when they find out! Otherwise you spare them the joy of figuring out what you changed, and why.
- Do really stupid stuff that you were taught from day 1 not to do, but everyone seems to do anyway: don't check for NULL, fix array sizes where you hardcode the max size everywhere, don't check for invalid or oversized input, etc.
- Use preprocessor macros. Lots of them. (I was actually on a project where someone suggested using cpp to define macros. For Java. Absolutely brilliant!) The key is to use a single macro for multiple statements, in effect using macros as function calls. Example: Notice the "hidden" use of external variables and functions. Remember, you want to avoid those expensive subroutine calls! And think of the joys of setting breakpoints and stepping through a debugger on that code!
- Don't use source code control. Or, use it, but never unlock or checkin your files. Feel free to steal locks on others, though.
And finally, one of my favorites, for all the young and aspiring hacker types out there:BONUS: With compact hungarian notation, you can become even more descriptive! So really the above becomes:
So much more descriptive information, all in the same amount of space. I've been on projects using this, and the sheer of joy of it cannot be accurately described in words.BONUS: Write extremely long lines of code, well over 80 characters per line.
BONUS: Do this right before a major deadline.
BONUS: Don't use the all uppercase convention in macro names; use the same naming convention as function calls. It's even more fun to debug when you have to spend time actually figuring out do_stuff() isn't even a function call!
MORE BONUS: Nest macro calls. Use the naming convention above.
EVEN MORE BONUS: Use macro calls as variables. Make sure the expanded macro makes function calls. Or uses other macros.
- Write code only for yourself. Assume no one will ever need to figure out how to use your code without poring through it in painstaking detail. Do not make it easy to use, interface with other code, or even compile. Include 30 caveats that would take you only a few minutes to fix, but you're just too lazy to. In other words, write as if no one will every look at or use your code, yet release it to everyone to look at and use. Defend your laziness, which is causing thousands of lost hours of work to others, by uttering useless and stupid "cool hacker" mantras like "Real Programmers don't write documentation" and "If it was hard to write, it should be hard to understand."
Phew. That little tirade made me feel good.----------
However, if other sites exist with the "Purdue" name in them, and Purdue University has not threatened or sued them, their stance is shaky. I am not a lawyer, but my understanding is that if you have a trademark, and don't defend it uniformly, then to some degree you lose rights to it.
Another thing to consider, which potentially weakens their stance, is other businesses which have the Purdue name, but are unrelated to Purdue University. (I'm not talking domain names, but business names outside of the Internet.) The Purdue brand for chicken comes to mind. In other words, if Purdue is associated with several well-known businesses then the University's claim to anything with "Purdue" in it is greatly weakened. Since your site deals directly with the Purdue University, I'm not sure how much this counts.
In any case, the best advice is what's been stated by others: communicate with them and try to find an alternative. You're not on great legal ground to fight them.
----------
I think that it's perfectly legit (i.e. non-hypocritical) for RedHat to sell their basic RedHat Linux system, which comprises all free software, and then to additionally sell more commercialized versions which include non-free software.
Note that RedHat has in the past included non-free software on their CDs, but it's only on the CD that you buy (i.e. it's not available via FTP), and it has been non-core parts of the OS. (The flak over KDE was because KDE was a core OS component, and therefore it was dangerous to support it.)
----------