Heluna - rather than installing any software or hardware, it's a service that accepts all of your incoming e-mail and forwards on the good messages. Unlimited mailboxes, quarantines, approved/blocked senders, and it only costs based upon the number of good messages that you get.
I had written out a fairly complex post about how you need to pick "the right tool for the job" but you already knew all that crap-- if you don't need to enforce MVC, don't bother with Struts, etc.
What you really need to look for is a mature product. Market share helps, but I keep waiting for that announcement that Ruby on Rails has some horrendous security hole because it's a 1.0 release. What you need is something that has been expanded upon, revised, and rethought a few times after having been deployed in the field. For me, if I need MVC, I pick Struts. For database abstraction, Hibernate is pretty slick. Both of those packages have been around the block a few times, so I'm fairly confident that any custom problems that I might see, have probably already been solved.
The kind of coder who deliberately writes bad code just to maintain their employment is always the first coder shown the door. Always. It is a complete urban myth that not commenting spaghetti code will keep you in a job. There is always someone else willing to do your job, no matter how specialized you think you may be.
Quit trying to make up bogus reasons as to why you don't want to be in a cube and just tell your boss, "I don't want to be in a cube."
If it's a dealbreaker for you, resign. Next they'll be moving you down into the basement and taking away your red stapler.
The only reason people think they use ISAPI is because that's what they originally used, and an executive decision was made to not break any existing links at any time, ever.
Check the Powered by Java image. The/ws/eBayISAPI.dll that you see in all of the requests just invokes a servlet.
It is now official. Netcraft confirms: Longhorn is dying
One more crippling bombshell hit the already beleaguered Longhorn community when IDC confirmed that Longhorn market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that Longhorn has lost more market share, this news serves to reinforce what we've known all along. Longhorn is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.
You don't need to be the Amazing Kreskin to predict Longhorn's future. The hand writing is on the wall: Longhorn faces a bleak future. In fact there won't be any future at all for Longhorn because Longhorn is dying. Things are looking very bad for Longhorn. As many of us are already aware, Longhorn continues to lose market share. Red ink flows like a river of blood.
64-bit Longhorn is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time 64-bit Longhorn developers Relph Slenson and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: Longhorn is dying.
Because customers are paying them to do it. If Kelkea (the new MAPS owners) lose enough business because they put a large chunk of AOL on their blacklist, then they'll think twice before making large decisions like this.
However, my guess is that they won't lose any business at all.
I have a text document that is owned by me, sitting in my home directory. I run a program that has a backdoor in it. This backdoor triggers the command "rm -rf/".
Yes, 99% of my machine will not be affected. But guess what? I'm still losing that text document, which, to me is a hell of a lot more important than losing/bin/ls (which I can just reinstall). I think this is where Michael was heading, before he went down that road of overgeneralization. There's no safe way for me to protect that document from a malicious program.
Also, you speak about keeping important files listed under a different user-- here's the issue: you shouldn't need to do that. If I have to authenticate every time I want to save a gif from Photoshop, that doesn't make for a good user experience at all.
Lastly, you say: If I so desired, I could limit the login / password for my MySQL account to only allow row INSERTs and SELECTs, but no DELETEs or DROPs.
But you don't, right? Why not? Because you're willing to take the risk that your MySQL login won't get swiped. So where's the acceptable level of risk? Michael seems to think that Linux has good enough security to make running as root not that big of a deal.
You're talking about the Google farm, I assume. Yes, I suspect that we will see a lot more of this as time goes by, but even in a grid layout, I would still pick Java as my development environment due to portability.
As it stands today, I can work on my Java app on my Wintel desktop, or my Mac laptop, and then deploy it all to the mixed-Solaris/Linux environment that is our production cluster. Web apps under Java are extremely portable-- much, much moreso than even the simplest PHP application.
Imagine a PHP application where all of the PHP server config, PHP app config, all the PHP files, required libraries, images, etc etc, were in a single zipfile and could be moved from machine to machine without any modification. That's what a Java WAR (Web ARchive) file is, and that's how hot deployment works.
I think the reason why I don't admin a huge corporate dynamic website is about to be pointed out though.....
Well, if you insist...
Java as a "dynamic deployment platform", as you put it, offers trivial matters such as load balancing, server-independent sessions, and hot deployment (where new sessions get the new codebase, while old sessions get the old codebase), just to name a few. These three items alone are nearly impossible to pull off in a PHP/MySQL configuration, without keeping your sessions in a database and reloading them for every single pageview. Nearly every Java app server gives you these without having to write any code.
And I think that's where a lot of these pseudo-flamewars get started. On an individual page basis where all I'm doing is "SELECT * FROM NEWS WHERE ID = ?", on one machine, of course PHP and MySQL are going to run faster. But once you start deploying your application to multiple boxes, the advantages of Java become clear.
Additionally, I would challenge you to this test: let's say you have a stock PHP installation, without the GD libraries linked into the PHP binary. Now let's say you want to create a PHP application that uses GD. Do you A) recompile your PHP server, or B) give up platform-independence and run some kind of system call? Under Java, the answer is C) add in a GD jarfile to your application, and you're done, without any recompilation or configuration on your part.
My point, and I do have one, is this: in exchange for the inefficient startup time of the VM and potentially inefficient bytecode (depending on your app server-- Tomcat is a real dog in this aspect) Java gives you a ton of freedom. With hardware getting faster every day, I'll make that tradeoff every single time.
In the worker mpm, this is true only in cases when you are handling a very small amount of traffic -- in all other cases, the memory used by the worker mpm mode is far, far less.
Example: here is a box currently handling 146 simultaneous requests, running at 34 requests per second.
That's around 175 megs of memory being used. Apache 1.3, using the prefork model, would have to take up only 1.5 megs of memory for each process to be as memory-efficient as Apache 2.0.
FYI, PHP compiled in CGI-mode completely eliminates the threading issues that PHP has with Apache 2, and allows you to continue to use Apache in worker mpm mode (which is, by far, the most efficient -- think orders of magnitude better performance on the same hardware).
The CGI may be a little slow to start up a PHP interpreter, etc etc, but it is rock solid. That said, using a real multithreaded application server (like, oh, any of your Java app servers) with Apache 2.0 is the best solution.
There is nothing in your list that doesn't come with a halfway decent Java application server, like Resin.
"Built-in object database". Uh, yeah, java was OO last I checked.
"Built-in http server". Check.
"Ability to integrate with other http servers". Check.
"Built-in scripting/application language". Java/JSP, or JSTL for those of you who aren't programmers.
"Built-in ability to connect to traditional databases" - seriously, this is one of your selling points? You're kidding, right?
"WEBDAV compliant". So is Apache.
"Built-in support for XML" (xerces)
"HTML" (holy cow, really?)
"Buzzword, buzzword, and buzzword"
"Ability to extend the environment by building modules that become integral to the site". You just described a jar file.
"If you can reach it from the network, you can develop and administer it." Like any other web application.
"A large stable of free/open source modules that can be loaded". Check.
"Built-in ability to cluster a site across multiple machines". Check.
Look, I'm happy that you're using Python to develop new and supposedly interesting applications, but let's face it, your environment is nothing new.
Seriously, isn't there a bit of a credibility gap? I love Gizmodo and all, but are they really the end-all-be-all of format reviewers? Let's see Tom's or Anandtech's opinions.
Okay, so setting up SPF records aside, have you actually modified their mail servers to do anything with incoming SPF data?
As someone who hosts a few domains on a box, I'm very very hesitant to modify Mimedefang to drop messages that fail SPF, because a few people have.forward files on other boxes that point at me.
Has anyone solved the.forward problem with SPF yet?
I find it rather funny that most of the responses claim that I haven't looked at the ports tree. On the contrary, I have kept very close tabs on the advancement of Java under FreeBSD. Back when our app ran under 1.1.8, we happily deployed FreeBSD. I will be first in line to deploy it again when the 1.4 JDK is bumped up to production-ready.
I want to be able to deploy a server on more than just faith. Five nines uptime is not something you can shoot for with a JDK that is deployable "at your own risk".
"For the record, [...] 4K+ users [...] each day [...]"
Let me know when your usage grows by three orders of magnitude. When you have problems at that point, then I will listen to you. Until then I'm forced to decide between a multitude of shitty Linux distributions, the godawful expensive Solaris, or Apple (?!). Like I said, I really want to go back to FreeBSD.
I've said it once before already, but the line "use in a production environment is still at your own risk" is a show-stopper. Call me overly paranoid, but as I am consistently shooting for highly available web applications, "at your own risk" is too much risk to deal with.
Native binaries, blessed by Sun, available on FreeBSD. Yes I know I should complain to Sun. Yes I know it isn't FreeBSD's fault. But would it kill the FreeBSD developers to try to work up a relationship with Sun?
Slashdot Mirror
Heluna - rather than installing any software or hardware, it's a service that accepts all of your incoming e-mail and forwards on the good messages. Unlimited mailboxes, quarantines, approved/blocked senders, and it only costs based upon the number of good messages that you get.
What you really need to look for is a mature product. Market share helps, but I keep waiting for that announcement that Ruby on Rails has some horrendous security hole because it's a 1.0 release. What you need is something that has been expanded upon, revised, and rethought a few times after having been deployed in the field. For me, if I need MVC, I pick Struts. For database abstraction, Hibernate is pretty slick. Both of those packages have been around the block a few times, so I'm fairly confident that any custom problems that I might see, have probably already been solved.
Quit trying to make up bogus reasons as to why you don't want to be in a cube and just tell your boss, "I don't want to be in a cube." If it's a dealbreaker for you, resign. Next they'll be moving you down into the basement and taking away your red stapler.
The only reason people think they use ISAPI is because that's what they originally used, and an executive decision was made to not break any existing links at any time, ever. Check the Powered by Java image. The /ws/eBayISAPI.dll that you see in all of the requests just invokes a servlet.
Wow, I'm getting disappointed in the Apple Slashdot zealots.
How many redundant posts will we see in this thread?
One more crippling bombshell hit the already beleaguered Longhorn community when IDC confirmed that Longhorn market share has dropped yet again, now down to less than a fraction of 1 percent of all servers. Coming on the heels of a recent Netcraft survey which plainly states that Longhorn has lost more market share, this news serves to reinforce what we've known all along. Longhorn is collapsing in complete disarray, as fittingly exemplified by failing dead last in the recent Sys Admin comprehensive networking test.
You don't need to be the Amazing Kreskin to predict Longhorn's future. The hand writing is on the wall: Longhorn faces a bleak future. In fact there won't be any future at all for Longhorn because Longhorn is dying. Things are looking very bad for Longhorn. As many of us are already aware, Longhorn continues to lose market share. Red ink flows like a river of blood.
64-bit Longhorn is the most endangered of them all, having lost 93% of its core developers. The sudden and unpleasant departures of long time 64-bit Longhorn developers Relph Slenson and Mike Smith only serve to underscore the point more clearly. There can no longer be any doubt: Longhorn is dying.
[...]
Because customers are paying them to do it. If Kelkea (the new MAPS owners) lose enough business because they put a large chunk of AOL on their blacklist, then they'll think twice before making large decisions like this.
However, my guess is that they won't lose any business at all.
Parent is the answer to why some providers ignore TTL, to prevent nutjobs like this from breaking the Internet.
Please enter user34023's password to read "Saved Email 2".
Please enter user1180's password to send "Letter to Parents to buy me a Real OS".
Yeah, sign me up for that.
Yes, 99% of my machine will not be affected. But guess what? I'm still losing that text document, which, to me is a hell of a lot more important than losing /bin/ls (which I can just reinstall). I think this is where Michael was heading, before he went down that road of overgeneralization. There's no safe way for me to protect that document from a malicious program.
Also, you speak about keeping important files listed under a different user-- here's the issue: you shouldn't need to do that. If I have to authenticate every time I want to save a gif from Photoshop, that doesn't make for a good user experience at all.
Lastly, you say: If I so desired, I could limit the login / password for my MySQL account to only allow row INSERTs and SELECTs, but no DELETEs or DROPs.
But you don't, right? Why not? Because you're willing to take the risk that your MySQL login won't get swiped. So where's the acceptable level of risk? Michael seems to think that Linux has good enough security to make running as root not that big of a deal.
As it stands today, I can work on my Java app on my Wintel desktop, or my Mac laptop, and then deploy it all to the mixed-Solaris/Linux environment that is our production cluster. Web apps under Java are extremely portable-- much, much moreso than even the simplest PHP application.
Imagine a PHP application where all of the PHP server config, PHP app config, all the PHP files, required libraries, images, etc etc, were in a single zipfile and could be moved from machine to machine without any modification. That's what a Java WAR (Web ARchive) file is, and that's how hot deployment works.
Java as a "dynamic deployment platform", as you put it, offers trivial matters such as load balancing, server-independent sessions, and hot deployment (where new sessions get the new codebase, while old sessions get the old codebase), just to name a few. These three items alone are nearly impossible to pull off in a PHP/MySQL configuration, without keeping your sessions in a database and reloading them for every single pageview. Nearly every Java app server gives you these without having to write any code.
And I think that's where a lot of these pseudo-flamewars get started. On an individual page basis where all I'm doing is "SELECT * FROM NEWS WHERE ID = ?", on one machine, of course PHP and MySQL are going to run faster. But once you start deploying your application to multiple boxes, the advantages of Java become clear.
Additionally, I would challenge you to this test: let's say you have a stock PHP installation, without the GD libraries linked into the PHP binary. Now let's say you want to create a PHP application that uses GD. Do you A) recompile your PHP server, or B) give up platform-independence and run some kind of system call? Under Java, the answer is C) add in a GD jarfile to your application, and you're done, without any recompilation or configuration on your part.
My point, and I do have one, is this: in exchange for the inefficient startup time of the VM and potentially inefficient bytecode (depending on your app server-- Tomcat is a real dog in this aspect) Java gives you a ton of freedom. With hardware getting faster every day, I'll make that tradeoff every single time.
Compare: Jesusonic screenshot.
Max/MSP screenshot.
I think you can see which one is much more powerful.
In the worker mpm, this is true only in cases when you are handling a very small amount of traffic -- in all other cases, the memory used by the worker mpm mode is far, far less.
Example: here is a box currently handling 146 simultaneous requests, running at 34 requests per second.
That's around 175 megs of memory being used. Apache 1.3, using the prefork model, would have to take up only 1.5 megs of memory for each process to be as memory-efficient as Apache 2.0.The CGI may be a little slow to start up a PHP interpreter, etc etc, but it is rock solid. That said, using a real multithreaded application server (like, oh, any of your Java app servers) with Apache 2.0 is the best solution.
"p.s. I know squat"
We have a winner!
Installing a JVM and an application server is about 99% less time consuming, and easier, than a comparable PHP installation.
Check Resin Quickstart
There is nothing in your list that doesn't come with a halfway decent Java application server, like Resin. "Built-in object database". Uh, yeah, java was OO last I checked. "Built-in http server". Check. "Ability to integrate with other http servers". Check. "Built-in scripting/application language". Java/JSP, or JSTL for those of you who aren't programmers. "Built-in ability to connect to traditional databases" - seriously, this is one of your selling points? You're kidding, right? "WEBDAV compliant". So is Apache. "Built-in support for XML" (xerces) "HTML" (holy cow, really?) "Buzzword, buzzword, and buzzword" "Ability to extend the environment by building modules that become integral to the site". You just described a jar file. "If you can reach it from the network, you can develop and administer it." Like any other web application. "A large stable of free/open source modules that can be loaded". Check. "Built-in ability to cluster a site across multiple machines". Check. Look, I'm happy that you're using Python to develop new and supposedly interesting applications, but let's face it, your environment is nothing new.
Seriously, isn't there a bit of a credibility gap? I love Gizmodo and all, but are they really the end-all-be-all of format reviewers? Let's see Tom's or Anandtech's opinions.
Okay, so setting up SPF records aside, have you actually modified their mail servers to do anything with incoming SPF data? As someone who hosts a few domains on a box, I'm very very hesitant to modify Mimedefang to drop messages that fail SPF, because a few people have .forward files on other boxes that point at me.
Has anyone solved the .forward problem with SPF yet?
I find it rather funny that most of the responses claim that I haven't looked at the ports tree. On the contrary, I have kept very close tabs on the advancement of Java under FreeBSD. Back when our app ran under 1.1.8, we happily deployed FreeBSD. I will be first in line to deploy it again when the 1.4 JDK is bumped up to production-ready.
YES!
I want to be able to deploy a server on more than just faith. Five nines uptime is not something you can shoot for with a JDK that is deployable "at your own risk".
"For the record, [...] 4K+ users [...] each day [...]"
Let me know when your usage grows by three orders of magnitude. When you have problems at that point, then I will listen to you. Until then I'm forced to decide between a multitude of shitty Linux distributions, the godawful expensive Solaris, or Apple (?!). Like I said, I really want to go back to FreeBSD.
Native binaries, blessed by Sun, available on FreeBSD. Yes I know I should complain to Sun. Yes I know it isn't FreeBSD's fault. But would it kill the FreeBSD developers to try to work up a relationship with Sun?
"The JDK(TM) it produces is de facto compliant, but use in a production environment is still at your own risk."
But thanks for your words of encouragement. That "We don't want you" crack must make you feel really good.