The cost of a bug isn't in cash per se. Whether a programmer is in-house or a contractor, they're going to be at your shop for the standard work-week at least, right? So they're either fixing your bug or they're browsing slashdot. You pay the same either way.
The REAL cost of a bug while the project is being coded is in delays to your project, which could push you past deadline. The cost of a bug after the project rolls out is the embarassment of getting caught with your pants down, and of having the inconvenience of pulling people off of other work to fix it.
So in my opinion, bugs are "cheapest" to fix during the initial design and prototype phase, where you're probably not that close to your deadline and you have some wiggle room.
They're more "expensive" to fix when you're closer to a deadline and the delay screws you up (for example, find a bug during user acceptance testing and you've got to go back and code, then start the testing all over again).
They're most "expensive" to fix when you've rolled out the project, the users come to depend on it, and something goes wrong. This embarrasses you and makes your code look untrustworthy, and forces you to scramble to deal with the problem, rolling out a patch, etc, all while dealing with hot-under-the-collar users.
I think this three-level way of looking at it is a lot more useful than any kind of imaginary mathemagical flim-flam. Forget the numbers, worry about the egg on your face.;)
First of all, I thought your point about going from twenty points to twenty one was hilarious. What, do you think you're not going to have to add code when using the session? You have to recode your app whether you use session variables or form posts. It comes out to about the same amount of code, too. See, if you're smart, all those hidden variables are tucked into the page by your server side code in one fell swoop -- so you don't have to recode the HTML, just the server-side scripting. And, it takes the same amount of coding as fetching from a session. So that's a great big fat red herring you threw out there. Besides, how are you coding your pages, if you have to update every page on your site when you change your code? Why aren't you building your code into a single module you can include throughout your site via SSI, if you're using it everywhere? Are you statically embedding your code EVERYWHERE??? Why? Isn't that like jabbing yourself in the eyes to make them water, instead of using Visine?
Here's another red herring: You think you can't mix form posts and regular links on a page, because it'll ruin the form posting? If you're walking the user through some process in which he needs to pass state forward, you shouldn't be building in ways out of the process anyway! Any additional links on the page should generate a new window, leaving the current page alone. Remember, a REQUESTED popup window is generally okay. For instance, during a set of signup pages, you might want to offer a popup "help" app. Right? But you wouldn't want it to take the user out of his task, now, would you? And, that would be a problem whether you're using sessions or form posts. It's about workflow.
And, network utilization? What, for a few hundred bytes of plain text form post? Give me a break. YOUR way still uses the network, but it also uses processor, and ram, and doesn't scale (unless you waste a lot of bread)... MY way leaves the data out of the system most of the time. The only time it gets transferred is when the user is actually submitting a page as part of a process, which is a tiny, tiny fraction of the time (and would never happen for static pages). YOUR way keeps it in RAM continuously, as long as the user is online. Which takes up a LOT more resources than MY way. Maybe I'm old fashioned, but Jesus, keeping all that in server RAM just seems nutso to me. Distributed processing is not a bad thing!
Anyway, these are the things you're "missing". I totally get that there are shops that use sessions to the hilt. But those shops spend way more money and have to acquire way more equipment than shops which do things the "old way". Sure, both methods work. But mine is not invalid just because it's old. And, mine is a whole lot more lightweight than yours (which is DEFINITELY an issue in some shops).
First off, ok, I was rude to you but you were rude to me first. I guess we're even.
Now let me defend my position.
When you're programming in a large enough institution (like, say, the government where I work) your webmasters are in one department, your network admins are in another, your database guys are in another, and YOU are in applications development. You can "ask" your webmaster to set up sessions in a certain way, but he may or may not agree with you. He might have his own way of setting up sessions, and he might not be interested in your opinion. Things get complicated. Another thing is, sometimes you have to share your server with as many as hundreds of other applications, so depending on how good the other programmers were, resources might be extremely thin. And you can't just order up more RAM or processing power, because now you're asking another department to screw up their budget for YOUR sake. They're going to say "Tough luck, guy; maybe you should make that app a little more lightweight". What then?
Here's something: when you're serving up static content, you're not going to have any state on the client, period. The only time you're going to be passing state (even with a form post) is when the client is in the middle of performing some task. In other words, the client has begun some process, and you're walking him through it. Form posts are a natural approach for this sort of thing. It's what they were designed for. I don't see why you're having such a problem with them.
If you're worried about something like a login, that can be put in the session without impacting RAM too heavily. But you could also take the userid and password the user supplied, concatenate them, encrypt it, and stick it in a session cookie, too, couldn't you? Then, every time the user does something that touches your database, you fetch the cookie and doublecheck the user's login. Since all the encryption is done on your server, you're not going to have to worry too much about the cookie getting hacked, and you can embed a timestamp and expire the thing easily enough. THEN, you're only using resources when the user actually DOES something, instead of using them up continuously. Is your problem with this approach because it's too old? Not shiny enough? I don't think that's a fair way to assess an idea. Arithmatic is thousands of years old, but without it, you're not balancing that checkbook, now are you?
And, let me point out that you're ALWAYS getting data from the client, even if you put it in a session. You ALWAYS have to doublecheck it. So that's hardly a fair criticism.
1994, eh? Yeah, I was programming back then. So what? I had my first website in '95, before any of this crap hit the mainstream. What's your point? Old = bad? Ha, that's rich... If that's true, better not use Linux/BSD, because it's thirty years old! Oooh, better use Windows Server 2003, it's shiny and new!
You can't EVER assume you've got good data from the user. You ALWAYS have to check it. And re-check it. And check it again. If you're not doing this, you're way too trusting...
As far as main memory databases go, well, that's all well and good, but *what if my shop doesn't have one*? And, what if we're constrained to only use approved vendors, thus can't get one? And, what if the people managing databases are in one department, and the people managing the web servers and network are in another, and the programmers are in another again, so that you get the database that is provided for you, period. So you can't just order up whatever you want, even if it would be perfect for you.
YES, there are solutions that would address some of the things I mentioned. But, NO, not everyone can use them. I know it's stupid, but it's life.
And, I only called him that because he was rude to me.
Well, those are pretty good points, and I definitely see what you're saying. However, some shops can't afford to buy more hardware every time they roll something out, and we have to squeeze a little more out of what we already have. Even if we didn't, though, throwing tons of money and hardware on a problem goes against my grain; I tend to favor thrift whenever possible, and lean towards a more efficient solution that uses the hardware I've already got. This probably comes from the fact I work for the government, and we have more constraints than people do in private industry (especially budgetary constraints).
Form posts tend to keep all that user data on the browser side, which is a good thing; if you use SSL, the data is just on the user's machine, and relatively safe. You set your pages up so they can't be cached, and you're ok. The nice thing about this is that you have very little overhead on your side. It's not about the transfer, with text data it's not going to use up much bandwidth. It's about resources. As you agreed, when you're hitting a backend database for data that the user already "knows" (and should have in his browser) you're throwing away processor cycles and ram on two of your own internal machines (DB and web servers), and internal bandwidth as well. The form post trick only adds a little additional bandwidth to a request the user would already be making, and in my view this is much more efficient.
As far as logins go, well, you can put a login and password in the session without eating up all your RAM, probably, which would probably be secure. But I like the idea of a session cookie; it's true that you as the user can probably try to fiddle with your cookie, but I as the programmer can assume you're going to do that and do things to annoy and frustrate you. For example, I can concatenate your userid and password fields, add some garbage data to mess up the field lengths, then encrypt them before I put them in your session cookie. After several pages of form posts, during which I'm just checking to see if the cookie is there and hasn't expired, you might submit all your data. At that time, I decrypt and parse out the session cookie and check your login a second time. If your login doesn't work, sorry, no ticket to ride. I kick you out to an error message and let you start over. That's not bad, is it? And it's not that much programming... No resources are consumed on the server until you actually submit your data (where we're going to be using resources anyway). Kinda clean.
This is actually something I'm working on in one of my apps right now. I generally go on the assumption that my users would love to escalate priviledge, so one of my goals is to stymie them. It feels like playing checkers. I don't want to get jumped, so I double up on everything (like checking logins at beginning and end). I don't want anyone to be able to DOS me by loading up my server with session vars, so I don't use them (my pages tend to be mostly stateless aside from form posts). I don't want to slow down other people's apps (a lot of us share the same servers) so I keep my processing to an absolute minimum... Of course I'm under more constraints than you probably are, but no matter how much horsepower you have, faster is better, right?
Anyway, I do see your points. But you can understand why I'd lean towards my approach...
Well, now, hang on a second. Some of your points are red herrings. For example:
* Most of your points seem to revolve around using session data for user sign-in to a services site. This is a pretty small use of session vars, and ok, I'll buy that that isn't going to hurt things much. But once people start using session vars, they start using them in all their user interfaces as well, including forms for collecting data. Which is where I was coming from with the hidden form posts. Setting that aside, if you want to handle user signin without sessions, what's wrong with a session cookie? It's not a third party cookie. It's not spyware. It's not persistant. What's the big deal? You think it's insecure? That's up to the programmer, isn't it?
* Using form posts doesn't have any effect on the back button -- PROVIDED you're not doing database inserts or updates on each page (which you really shouldn't be anyway, but if you feel the need to, you can handle this issue in a variety of ways).
* Using form posts doesn't kill "friendly URLs" (whatever those are) because any link can have an onclick method which sets the form's action and submits it. But if you're collecting user data, then you shouldn't have multiple ways off the page -- you should be in tight control of the way in which the user uses your app. Again, if you're just doing the sign-in thing, use a session cookie and you don't have to do form posts at all.
* If you're using a session cookie, the back button won't log you back in, because you'll have killed it in your code, right? So it won't be there when the user goes "back"...
* you can set up your pages so they won't be cached. Of course.
* You should ALWAYS doublecheck the user data, not only on the client side but on the user side as well. This is simply standard practice. So it's not an issue with what I'm saying.
* As far as overhead goes, I would agree with you that using an app server would involve more overhead than a single database call IF that database call was just a userid thing as you're saying. But we're talking about a broader subject, i.e. the use of session variables. This involves a whole lot more than sign-on; a lot of people put way too much in their session vars. Plus, you're mixing apples and oranges. The overhead of running a bigger server is one thing, thousands and thousands of hits to a database is another, no matter how little data you're fetching. On one hand, you're talking about RAM, on the other you're talking about RAM AND sockets AND bandwidth AND Ram on a database server, etc.
And, what's up with that comment about the form post data taking up bandwidth? What, a couple of kilobytes of plaintext in the extreme case? Gimme a break. Most will be a few hundred bytes. Relax...
Not to be shrill, but boy are people giving me a hard time about this one suggestion. Jeez, everyone's so in love with their session vars...
Hey, hey, come on, be cool. All day, every day, I do VB.Net and web services, so I'm not anti-.Net. Actually I like.Net a lot. All I was saying was that the original poster shouldn't pick up on any buzz-word (like Java,.Net, PHP, or anything else) unless it'll actually help him code his application. If what he's been using is working out for him, my thinking went, he should stick with it and formulate a load-balancing strategy around it. Load balancing isn't going to force him to change his platform at all.
Let's all remain calm, ok? No disrespect intended to.Net, Java, or anything else.
Anyway, I barely even mentioned.Net in my post. Where did all this come from???
Sigh... You know... Aside from the load balancing issue, it wasn't so long ago that people were advised not to use session variables at all because under heavy load, they use up too much RAM on your server. Methinks you read too many vendor brochures... But, I'll be nice and explain why using hidden form fields is NOT like trying to code a C++ compiler in Cobol (god, what a weirdo analogy -- you think that one up all by yourself?).
Putting values in hidden form fields means you don't have to keep them in your server's memory. Because they're in form elements, they're not even in client memory. They only exist in memory during the actual HTTP post, and then only while the page is being loaded. This is a Good Thing. Because when your site is being hit by tens of thousands of people, and you're processing, say, seventy five pieces of data each, you're going to be using a whole lot of ram if you go with session variables instead of form posts. And, session variables are PERSISTENT. Let me say that again. They're PERSISTENT. This means that they're held in memory as long as that person has a session open unless you null 'em out. If you have a bunch of dropped sessions, or sessions where the user just went out for coffee in the middle of things, that's memory that's dead for all extents and purposes until the session times out. Which could be set to hours, depending on how smart your webmaster is. SO SESSIONS SUCK. They suck RAM, and they suck processor power. Don't even get me started on the idiocy of using a database for session management -- who the fuck thought it was a good idea to put a call to an external database in every page load??? That's even slower than file access for fuck's sake. Talk about speedbumps...
See, you'd know that if you were the kind of developer who looks into different ways of doing things, instead of just doing whatever the SAMS book tells you to do. Let me guess: you got a book on web development, it told you all about session variables, and you were sold on the idea. No critical thought, no consideration of what using session variables MEANS, just "Ok, it says to do it, I'll do it and that's the way everyone must do it".
Ugh. People like you... Arrogant, closed-minded recipe followers. Bark at someone else, my little chihuahua.
Websphere and Weblogic I can understand; it makes sense to use session variables if you've got a server setup that takes care of sessions across different servers and it's transparent to you. I can see the utility in that.
As far as putting sessions in a database, boy oh boy, I don't like that idea much at all. Calling out to a database (on a different server, since we're talking about cross-server sessions) every time you load a page and have to check the session adds in a nice little speed bump -- no thanks.
If I really must have sessions and load balancing at the same time, I'll use one of the servers you mentioned, Websphere or Weblogic. But I can't really envision being too stubborn about wanting both.
I'd rather use hidden form elements, myself. I know it's old fashioned, but it takes up fewer resources, causes fewer headaches, doesn't require app servers or databases (cheaper!), and is easier to debug. Just my opinion -- I don't have a problem with people who like session variables, state, etc. But I don't personally see much use for 'em.
I beg your pardon, but I'm not trolling. I was making a totally serious comment. I know it's traditional slashdot etiquette to label all opinions you disagree with as "trolling" but let's keep a civil conversation civil, ok?
Ok, having said that, I was under the impression that you had to take a couple of extra steps in Java to run an external program, mostly due to its sandbox approach to security. I.E. that it was doable, but slightly more complicated than it is in a scripting language.
Why you might want to do it in a scripting language is obvious; compiled code is very fast, features you might want are supplied in your compiled language but not your scripting language, and you might want to do something complex which would be helped by an OOP approach. Also, if you build your external apps well, you can access them from code you'll write in the future, not just from the script you're writing right now (kinda like web services, eh?).
Since you mentioned it, you might want to do it from Java because you might want to benefit from using REALLY compiled code rather than JIT compiled code. A JIT compiler compiles each class as it hits it. So unless you have a prep app which touches each class at least once, your stuff is going to be compiled on the fly for at least some of your users. Thus slower than a completely precompiled app. Of course, you won't find this compelling, because is it? I don't know. Maybe not. But it's a possible reason for using external modules, etc...
ANYWAY, my point was that scripts can get a performance and development benefit from using external modules, and that I think that's kinda neat. Useful. Not really related to script vs. Java, but sort of interesting in a tangential way.
Connection pooling means, basically, that the server sets up a pool of already open connections to a database, and your app can borrow a connection from the pool when it needs to interact with the database, then release the connection back to the pool. It's a performance trick, because opening a connection and closing it eats up resources, so you open up all the connections at once and leave them open, and they just handle requests which is less resource-intensive. I haven't had much need for it myself, but I've read about it...
Re: Could someone explain instead of just flaming?
on
PHP Scales As Well As Java
·
· Score: 2, Insightful
I think you're mixing two concepts here. First, there's Java/J2EE. You can do Java without doing J2EE. J2EE is a whole set of additional tools and ideas which are java-based. My impression of it is that it's more useful to huge organizations like banks, where you've got different servers in different buildings which have to interoperate (hence things like javabeans and servlets). It's not a scalability thing, it's a distributed application thing, you know? Although I'm sure J2EE has scalability features built into it, I don't think scalability is the whole point of J2EE.
On the other hand, if you're talking about just scaling to larger numbers of users, you're probably talking about load balancing more than anything else. One server will basically be handing off requests to other servers based on how busy they are. That has nothing to do with Java Vs. PHP. You can use either with that. The only gotcha is you should make your pages stateless (no session variables, etc). If you pass data from one page to the next, do it the old-school way using hidden form elements, because then no matter which server gets handed the current request, you'll have the passed-along data and you don't have to futz around with the session.
My thinking is, as long as your scalability has to do with load, just worry about load-balancing, make your pages stateless (there IS state, but you're passing it along on form posts rather than trying to store it on the server), and use whichever language has been working for you up until now. Don't touch J2EE (or.Net, or any other buzzword) unless you actually *need* it, like for example, if your app is distributed and very complex.
Yeah... Perl lets you do C modules too, it's one of the nicer features of the scripting languages. Another cool thing is you can run external programs you've developed elsewhere to offload parts of your task. So let's say you've got something really horrible and complicated, which could best be done using OOP techniques. No problem; use the Perl or PHP script as a frontend, and call an object oriented program from within the script, passing in the data in one of a few ways. Then you get all the benefit of object oriented programming in the complicated parts, inheritence, reusability, speed of a compiled language, etc, but you also get to work with scripting. I'm pretty sure doing something like that is at best nontrivial in Java. If it's possible at all.
Although I lean towards Perl, personally, I've heard only good things about PHP. Looks interesting!
Fixed IPs are a mixed bag, though. Although a fixed IP lets you house your own server, it also makes it much easier for someone to hack your home machine; in a way you're a sitting duck. And, running a server at home means leaving your home machine turned on all the time, which leaves a hacker plenty of room to take his time and crack your box while you're at work. It's a great big headache waiting to happen.
On the other hand, you can use an ISP which gives you a dynamic IP address via DHCP, and only turn the computer on when you're actually working on it. This makes it infinitely more difficult for someone to mess with you. Not only do they have to determine your dynamically-assigned IP address, but they have to catch you while you're actually online. This moves you up to the top of the tree, above the low-hanging fruit the script kiddies prefer.
Another issue is, if you want to run a bunch of services, it's safer to run them from a co-lo service, so that your personal stuff (like the book you're writing and your email) is on your safer home machine and your public stuff is on a separate, locked down machine in a server cage somewhere. Even if your co-lo gets hacked, none of your personal stuff will get lost. Better for you, isn't it?
My friends make fun of me, saying I'm the most paranoid human alive. I only use laptops, and lock them up (with my cablemodem!) when I'm not using them (Fire safes are cheap!); Whenever I'm online, it's behind a NAT hardware firewall with paranoid settings; and I've got a firewall running on each laptop as well. I never use Microsoft software on any internet-connected machine (at home, at least -- at work I'm stuck with it). And, I never host any services on my local machines (all ports are closed by default).
You don't have to go to those lengths of course. But still, you have to admit, running a server is like painting a big bullseye on your forehead.
What's the big deal about going with a co-lo? usually, with a co-lo, you pay around a hundred bucks a month and supply your own machine, which you then remotely admin using ssh or something. If you want all the additional power you're talking about, you can always spend a little more money and do it right. A side benefit is physical security, which is generally better than that in an apartment (i.e. a locked server cage vs. a one-bedroom with thin wooden doors and a possibly shifty landlord with a key). I understand your point of view, and yes, what you want would be cheaper, but even if ISPs take it away from you you have options.
Most consumers using cable modems have the option of setting up a web page for free through their ISP, and they can publish whatever they want (within certain reasonable limits) on it. Similarly, anyone who can afford about 35.00 a month can get a really solid hosted site together. Just because ISPs don't let you serve from your own PC doesn't mean you can't serve up pages. You just have to find a host... And, this isn't going to go away because it's a big market and it makes money. Those hosting fees add up.
Husband: "Wife, you have ten seconds to open the door, then something terribly rude will happen."
Wife: "Fuck off!"
Husband (throws paving stone through picture window) : CRASH! Clink, clatter... "Ah, much better. Goodnight, dear, I'll call the glazier in the morning. Please have my copy of the keys ready for me in the morning. If you do, perhaps I won't show these ribald photos of you getting buttsex from the locksmith to the judge during our imminent divorce."
Wife: "..."
Husband: "Oh, by the way, I play golf with that guy. You DO know he has herpes and the clap, don't you? NO? Oh, dear me. Your poor butt is going to HURT..."
Wife: "!!!"
Husband: "Nighty night, dear. No sex necessary, I fucked your sister a few hours ago." (closes door to study before wife can respond).
Turn those cell phones off, "to conserve energy". Say it; it rolls off the tongue, doesn't it? "Honey, I'm 'conserving energy'!" Then you cannot be called, period -- and almost no telemarketers are crazy enough to leave you a message. Check your messages from time to time, to see that your wife has a flat, etc, but leave the phone off when you're not checking messages or dialling out.
That's what I do... And, the side benefit is, no one is capable of bothering you. Consider this scenario:
Wife (to self): "I wonder where my husband is... The lawn's getting long and we have shopping to do. I think I'll call him and tell him to drag his butt home, I bet he's just in the bar with the boys anyway..."
Ring, ring, "Please leave a message."
Wife (out loud): "Dack, Nabbit! His cell's off! Ooohhh!"
(four hours later, sun going down, too late to mow).
Husband: "Wife, I'm home!"
Wife: (icily) YOUR CELL PHONE WAS OFF.
Husband: "Was it? I turned it on this morning... I wonder if the battery's going dead?"
Wife, grabbing cell phone and repeatedly stabbing the 'ON' button with her thumb: "YOU TURNED IT OFF!"
Husband: "Oh, yeah, I forgot, I was conserving energy... You yelled at me yesterday for turning all the lights on and..."
Wife: "AAAARGH!"
Husband: "Jesus, lose your temper, too. Man... I'm leaving! I'll see you later. While I'm gone, you think about your abusive attitude..."
(Husband goes back to bar. Wife calls mother and shrieks for half an hour straight. When husband gets back, wife is asleep and things are quiet).
Man... That's a beautiful thing. Thank you for posting that delightful bit of prose, it was wonderful. I'm SO GLAD I killed my landline, and am only using cell phones now...
Not only do I get free long distance...
Not only do I get to carry my phone with me, ready for anything weird that might happen to me...
Not only do I get really great service and zillions of minutes for less than fifty bucks a month (in contrast, my old landline was 45/month not counting long distance and semi-local)...
But, it's illegal for telemarketers to call my cell!
Almost EVERYONE "penetrates" via IIS. It's like a friggin' freebie, so everyone tends to use it. Barring that, they'll go for the RPC thing, or some other service Microsoft stupidly leaves turned on in almost all of their home machines. Or they'll just send the person an email; for a large percentage of users, that'll work like a charm. (Another reason Linux is safer; most Linux email programs are text-mode, without all the weird scripting bullshit Microsoft tucks into Outlook).
If a little hacker cared about stopping the firewall it would be because they want to run an IRC server, or maybe start doing DDOS, or some other stupid script kiddie trick. Which, by the way, is how most worms propagate. And, how most of the more annoying problems happen on the internet. So I guess the firewall thing DOES matter, doesn't it?
Go soak your arrogant, know-nothing little head until your ego shrinks back to normal size, you demented little shit.
See? I can call names too. Do you feel special now?
Blah, blah blah. Calling me names again. How old are you, fifteen? You're so rude and immature.
But, since we're not getting anywhere, let me re-iterate: the network connection comes up while Norton Personal Firewall is still displaying an icon that claims it's disabled. SO, if the firewall is disabled, I guess it's not firewalling, now is it?
And, who cares WHAT you tell me; what are you, the pope? Not that anyone listens to him, either...
All of your points on Linux, which you seem to think I'm not aware of, are irrelevant, and you're a moron for trying to throw them at me. BECAUSE, on Linux, YES, you can work with kernel modules, etc, IF YOU HAVE ROOT. But if you're just probing a machine, and trying to GET root, you're up a creek unless the person is running an exploitable service AND that service is running SUID. If the user is even remotely clueful, he'll be running as an unpriviledged user, he'll have most SUID scripts turned off, and it'll be damned hard for you to get the kind of access you would need to do what you're saying.
Compare this with Windows, where due to poor application design, most users run as administrator (because they're added to the administrator group so they can USE their software) and most services people attack are run as administrator (or a relatively priviledged system user). So if you hack any major service or ANYONE's account you're an administrator, and can do whatever the hell you want. Quite a bit different, now, isn't it?
Keep calling me stupid, everyone on Slashdot does, I don't mind. I have a thick skin. But anyone reading the whole thread will say, "well, they called him stupid, but they're not addressing his points."
And, to your TCP/IP stack notes, thanks for the lecture Mr. Wizard, but I think you're putting a little too much faith in Microsoft's systems, there. Because after all, if someone wanted to kill your pesky windows firewall, they'd attack your IIS, and run some code that disables the firewall, rather than crashing it outright, which pops those hooks RIGHT OUT of your precious TCP/IP stack and we're off to the races. Don't be such a schmuck.
Take your book on OS concepts and put it someplace uncomfortable, you arrogant little noob.
Slashdot Mirror
The cost of a bug isn't in cash per se. Whether a programmer is in-house or a contractor, they're going to be at your shop for the standard work-week at least, right? So they're either fixing your bug or they're browsing slashdot. You pay the same either way.
;)
The REAL cost of a bug while the project is being coded is in delays to your project, which could push you past deadline. The cost of a bug after the project rolls out is the embarassment of getting caught with your pants down, and of having the inconvenience of pulling people off of other work to fix it.
So in my opinion, bugs are "cheapest" to fix during the initial design and prototype phase, where you're probably not that close to your deadline and you have some wiggle room.
They're more "expensive" to fix when you're closer to a deadline and the delay screws you up (for example, find a bug during user acceptance testing and you've got to go back and code, then start the testing all over again).
They're most "expensive" to fix when you've rolled out the project, the users come to depend on it, and something goes wrong. This embarrasses you and makes your code look untrustworthy, and forces you to scramble to deal with the problem, rolling out a patch, etc, all while dealing with hot-under-the-collar users.
I think this three-level way of looking at it is a lot more useful than any kind of imaginary mathemagical flim-flam. Forget the numbers, worry about the egg on your face.
Ok, I'll "enlighten you". You ARE missing a lot.
First of all, I thought your point about going from twenty points to twenty one was hilarious. What, do you think you're not going to have to add code when using the session? You have to recode your app whether you use session variables or form posts. It comes out to about the same amount of code, too. See, if you're smart, all those hidden variables are tucked into the page by your server side code in one fell swoop -- so you don't have to recode the HTML, just the server-side scripting. And, it takes the same amount of coding as fetching from a session. So that's a great big fat red herring you threw out there. Besides, how are you coding your pages, if you have to update every page on your site when you change your code? Why aren't you building your code into a single module you can include throughout your site via SSI, if you're using it everywhere? Are you statically embedding your code EVERYWHERE??? Why? Isn't that like jabbing yourself in the eyes to make them water, instead of using Visine?
Here's another red herring: You think you can't mix form posts and regular links on a page, because it'll ruin the form posting? If you're walking the user through some process in which he needs to pass state forward, you shouldn't be building in ways out of the process anyway! Any additional links on the page should generate a new window, leaving the current page alone. Remember, a REQUESTED popup window is generally okay. For instance, during a set of signup pages, you might want to offer a popup "help" app. Right? But you wouldn't want it to take the user out of his task, now, would you? And, that would be a problem whether you're using sessions or form posts. It's about workflow.
And, network utilization? What, for a few hundred bytes of plain text form post? Give me a break. YOUR way still uses the network, but it also uses processor, and ram, and doesn't scale (unless you waste a lot of bread)... MY way leaves the data out of the system most of the time. The only time it gets transferred is when the user is actually submitting a page as part of a process, which is a tiny, tiny fraction of the time (and would never happen for static pages). YOUR way keeps it in RAM continuously, as long as the user is online. Which takes up a LOT more resources than MY way. Maybe I'm old fashioned, but Jesus, keeping all that in server RAM just seems nutso to me. Distributed processing is not a bad thing!
Anyway, these are the things you're "missing". I totally get that there are shops that use sessions to the hilt. But those shops spend way more money and have to acquire way more equipment than shops which do things the "old way". Sure, both methods work. But mine is not invalid just because it's old. And, mine is a whole lot more lightweight than yours (which is DEFINITELY an issue in some shops).
Harsh, buddy, harsh.
First off, ok, I was rude to you but you were rude to me first. I guess we're even.
Now let me defend my position.
When you're programming in a large enough institution (like, say, the government where I work) your webmasters are in one department, your network admins are in another, your database guys are in another, and YOU are in applications development. You can "ask" your webmaster to set up sessions in a certain way, but he may or may not agree with you. He might have his own way of setting up sessions, and he might not be interested in your opinion. Things get complicated. Another thing is, sometimes you have to share your server with as many as hundreds of other applications, so depending on how good the other programmers were, resources might be extremely thin. And you can't just order up more RAM or processing power, because now you're asking another department to screw up their budget for YOUR sake. They're going to say "Tough luck, guy; maybe you should make that app a little more lightweight". What then?
Here's something: when you're serving up static content, you're not going to have any state on the client, period. The only time you're going to be passing state (even with a form post) is when the client is in the middle of performing some task. In other words, the client has begun some process, and you're walking him through it. Form posts are a natural approach for this sort of thing. It's what they were designed for. I don't see why you're having such a problem with them.
If you're worried about something like a login, that can be put in the session without impacting RAM too heavily. But you could also take the userid and password the user supplied, concatenate them, encrypt it, and stick it in a session cookie, too, couldn't you? Then, every time the user does something that touches your database, you fetch the cookie and doublecheck the user's login. Since all the encryption is done on your server, you're not going to have to worry too much about the cookie getting hacked, and you can embed a timestamp and expire the thing easily enough. THEN, you're only using resources when the user actually DOES something, instead of using them up continuously. Is your problem with this approach because it's too old? Not shiny enough? I don't think that's a fair way to assess an idea. Arithmatic is thousands of years old, but without it, you're not balancing that checkbook, now are you?
And, let me point out that you're ALWAYS getting data from the client, even if you put it in a session. You ALWAYS have to doublecheck it. So that's hardly a fair criticism.
1994, eh? Yeah, I was programming back then. So what? I had my first website in '95, before any of this crap hit the mainstream. What's your point? Old = bad? Ha, that's rich... If that's true, better not use Linux/BSD, because it's thirty years old! Oooh, better use Windows Server 2003, it's shiny and new!
Or... Not!
You can't EVER assume you've got good data from the user. You ALWAYS have to check it. And re-check it. And check it again. If you're not doing this, you're way too trusting...
As far as main memory databases go, well, that's all well and good, but *what if my shop doesn't have one*? And, what if we're constrained to only use approved vendors, thus can't get one? And, what if the people managing databases are in one department, and the people managing the web servers and network are in another, and the programmers are in another again, so that you get the database that is provided for you, period. So you can't just order up whatever you want, even if it would be perfect for you.
YES, there are solutions that would address some of the things I mentioned. But, NO, not everyone can use them. I know it's stupid, but it's life.
And, I only called him that because he was rude to me.
Well, those are pretty good points, and I definitely see what you're saying. However, some shops can't afford to buy more hardware every time they roll something out, and we have to squeeze a little more out of what we already have. Even if we didn't, though, throwing tons of money and hardware on a problem goes against my grain; I tend to favor thrift whenever possible, and lean towards a more efficient solution that uses the hardware I've already got. This probably comes from the fact I work for the government, and we have more constraints than people do in private industry (especially budgetary constraints).
Form posts tend to keep all that user data on the browser side, which is a good thing; if you use SSL, the data is just on the user's machine, and relatively safe. You set your pages up so they can't be cached, and you're ok. The nice thing about this is that you have very little overhead on your side. It's not about the transfer, with text data it's not going to use up much bandwidth. It's about resources. As you agreed, when you're hitting a backend database for data that the user already "knows" (and should have in his browser) you're throwing away processor cycles and ram on two of your own internal machines (DB and web servers), and internal bandwidth as well. The form post trick only adds a little additional bandwidth to a request the user would already be making, and in my view this is much more efficient.
As far as logins go, well, you can put a login and password in the session without eating up all your RAM, probably, which would probably be secure. But I like the idea of a session cookie; it's true that you as the user can probably try to fiddle with your cookie, but I as the programmer can assume you're going to do that and do things to annoy and frustrate you. For example, I can concatenate your userid and password fields, add some garbage data to mess up the field lengths, then encrypt them before I put them in your session cookie. After several pages of form posts, during which I'm just checking to see if the cookie is there and hasn't expired, you might submit all your data. At that time, I decrypt and parse out the session cookie and check your login a second time. If your login doesn't work, sorry, no ticket to ride. I kick you out to an error message and let you start over. That's not bad, is it? And it's not that much programming... No resources are consumed on the server until you actually submit your data (where we're going to be using resources anyway). Kinda clean.
This is actually something I'm working on in one of my apps right now. I generally go on the assumption that my users would love to escalate priviledge, so one of my goals is to stymie them. It feels like playing checkers. I don't want to get jumped, so I double up on everything (like checking logins at beginning and end). I don't want anyone to be able to DOS me by loading up my server with session vars, so I don't use them (my pages tend to be mostly stateless aside from form posts). I don't want to slow down other people's apps (a lot of us share the same servers) so I keep my processing to an absolute minimum... Of course I'm under more constraints than you probably are, but no matter how much horsepower you have, faster is better, right?
Anyway, I do see your points. But you can understand why I'd lean towards my approach...
Well, now, hang on a second. Some of your points are red herrings. For example:
* Most of your points seem to revolve around using session data for user sign-in to a services site. This is a pretty small use of session vars, and ok, I'll buy that that isn't going to hurt things much. But once people start using session vars, they start using them in all their user interfaces as well, including forms for collecting data. Which is where I was coming from with the hidden form posts. Setting that aside, if you want to handle user signin without sessions, what's wrong with a session cookie? It's not a third party cookie. It's not spyware. It's not persistant. What's the big deal? You think it's insecure? That's up to the programmer, isn't it?
* Using form posts doesn't have any effect on the back button -- PROVIDED you're not doing database inserts or updates on each page (which you really shouldn't be anyway, but if you feel the need to, you can handle this issue in a variety of ways).
* Using form posts doesn't kill "friendly URLs" (whatever those are) because any link can have an onclick method which sets the form's action and submits it. But if you're collecting user data, then you shouldn't have multiple ways off the page -- you should be in tight control of the way in which the user uses your app. Again, if you're just doing the sign-in thing, use a session cookie and you don't have to do form posts at all.
* If you're using a session cookie, the back button won't log you back in, because you'll have killed it in your code, right? So it won't be there when the user goes "back"...
* you can set up your pages so they won't be cached. Of course.
* You should ALWAYS doublecheck the user data, not only on the client side but on the user side as well. This is simply standard practice. So it's not an issue with what I'm saying.
* As far as overhead goes, I would agree with you that using an app server would involve more overhead than a single database call IF that database call was just a userid thing as you're saying. But we're talking about a broader subject, i.e. the use of session variables. This involves a whole lot more than sign-on; a lot of people put way too much in their session vars. Plus, you're mixing apples and oranges. The overhead of running a bigger server is one thing, thousands and thousands of hits to a database is another, no matter how little data you're fetching. On one hand, you're talking about RAM, on the other you're talking about RAM AND sockets AND bandwidth AND Ram on a database server, etc.
And, what's up with that comment about the form post data taking up bandwidth? What, a couple of kilobytes of plaintext in the extreme case? Gimme a break. Most will be a few hundred bytes. Relax...
Not to be shrill, but boy are people giving me a hard time about this one suggestion. Jeez, everyone's so in love with their session vars...
Hey, hey, come on, be cool. All day, every day, I do VB.Net and web services, so I'm not anti-.Net. Actually I like .Net a lot. All I was saying was that the original poster shouldn't pick up on any buzz-word (like Java, .Net, PHP, or anything else) unless it'll actually help him code his application. If what he's been using is working out for him, my thinking went, he should stick with it and formulate a load-balancing strategy around it. Load balancing isn't going to force him to change his platform at all.
.Net, Java, or anything else.
.Net in my post. Where did all this come from???
Let's all remain calm, ok? No disrespect intended to
Anyway, I barely even mentioned
Sigh... You know... Aside from the load balancing issue, it wasn't so long ago that people were advised not to use session variables at all because under heavy load, they use up too much RAM on your server. Methinks you read too many vendor brochures... But, I'll be nice and explain why using hidden form fields is NOT like trying to code a C++ compiler in Cobol (god, what a weirdo analogy -- you think that one up all by yourself?).
Putting values in hidden form fields means you don't have to keep them in your server's memory. Because they're in form elements, they're not even in client memory. They only exist in memory during the actual HTTP post, and then only while the page is being loaded. This is a Good Thing. Because when your site is being hit by tens of thousands of people, and you're processing, say, seventy five pieces of data each, you're going to be using a whole lot of ram if you go with session variables instead of form posts. And, session variables are PERSISTENT. Let me say that again. They're PERSISTENT. This means that they're held in memory as long as that person has a session open unless you null 'em out. If you have a bunch of dropped sessions, or sessions where the user just went out for coffee in the middle of things, that's memory that's dead for all extents and purposes until the session times out. Which could be set to hours, depending on how smart your webmaster is. SO SESSIONS SUCK. They suck RAM, and they suck processor power. Don't even get me started on the idiocy of using a database for session management -- who the fuck thought it was a good idea to put a call to an external database in every page load??? That's even slower than file access for fuck's sake. Talk about speedbumps...
See, you'd know that if you were the kind of developer who looks into different ways of doing things, instead of just doing whatever the SAMS book tells you to do. Let me guess: you got a book on web development, it told you all about session variables, and you were sold on the idea. No critical thought, no consideration of what using session variables MEANS, just "Ok, it says to do it, I'll do it and that's the way everyone must do it".
Ugh. People like you... Arrogant, closed-minded recipe followers. Bark at someone else, my little chihuahua.
Websphere and Weblogic I can understand; it makes sense to use session variables if you've got a server setup that takes care of sessions across different servers and it's transparent to you. I can see the utility in that.
As far as putting sessions in a database, boy oh boy, I don't like that idea much at all. Calling out to a database (on a different server, since we're talking about cross-server sessions) every time you load a page and have to check the session adds in a nice little speed bump -- no thanks.
If I really must have sessions and load balancing at the same time, I'll use one of the servers you mentioned, Websphere or Weblogic. But I can't really envision being too stubborn about wanting both.
I'd rather use hidden form elements, myself. I know it's old fashioned, but it takes up fewer resources, causes fewer headaches, doesn't require app servers or databases (cheaper!), and is easier to debug. Just my opinion -- I don't have a problem with people who like session variables, state, etc. But I don't personally see much use for 'em.
I beg your pardon, but I'm not trolling. I was making a totally serious comment. I know it's traditional slashdot etiquette to label all opinions you disagree with as "trolling" but let's keep a civil conversation civil, ok?
Ok, having said that, I was under the impression that you had to take a couple of extra steps in Java to run an external program, mostly due to its sandbox approach to security. I.E. that it was doable, but slightly more complicated than it is in a scripting language.
Why you might want to do it in a scripting language is obvious; compiled code is very fast, features you might want are supplied in your compiled language but not your scripting language, and you might want to do something complex which would be helped by an OOP approach. Also, if you build your external apps well, you can access them from code you'll write in the future, not just from the script you're writing right now (kinda like web services, eh?).
Since you mentioned it, you might want to do it from Java because you might want to benefit from using REALLY compiled code rather than JIT compiled code. A JIT compiler compiles each class as it hits it. So unless you have a prep app which touches each class at least once, your stuff is going to be compiled on the fly for at least some of your users. Thus slower than a completely precompiled app. Of course, you won't find this compelling, because is it? I don't know. Maybe not. But it's a possible reason for using external modules, etc...
ANYWAY, my point was that scripts can get a performance and development benefit from using external modules, and that I think that's kinda neat. Useful. Not really related to script vs. Java, but sort of interesting in a tangential way.
Connection pooling means, basically, that the server sets up a pool of already open connections to a database, and your app can borrow a connection from the pool when it needs to interact with the database, then release the connection back to the pool. It's a performance trick, because opening a connection and closing it eats up resources, so you open up all the connections at once and leave them open, and they just handle requests which is less resource-intensive. I haven't had much need for it myself, but I've read about it...
I think you're mixing two concepts here. First, there's Java/J2EE. You can do Java without doing J2EE. J2EE is a whole set of additional tools and ideas which are java-based. My impression of it is that it's more useful to huge organizations like banks, where you've got different servers in different buildings which have to interoperate (hence things like javabeans and servlets). It's not a scalability thing, it's a distributed application thing, you know? Although I'm sure J2EE has scalability features built into it, I don't think scalability is the whole point of J2EE.
.Net, or any other buzzword) unless you actually *need* it, like for example, if your app is distributed and very complex.
On the other hand, if you're talking about just scaling to larger numbers of users, you're probably talking about load balancing more than anything else. One server will basically be handing off requests to other servers based on how busy they are. That has nothing to do with Java Vs. PHP. You can use either with that. The only gotcha is you should make your pages stateless (no session variables, etc). If you pass data from one page to the next, do it the old-school way using hidden form elements, because then no matter which server gets handed the current request, you'll have the passed-along data and you don't have to futz around with the session.
My thinking is, as long as your scalability has to do with load, just worry about load-balancing, make your pages stateless (there IS state, but you're passing it along on form posts rather than trying to store it on the server), and use whichever language has been working for you up until now. Don't touch J2EE (or
Yeah... Perl lets you do C modules too, it's one of the nicer features of the scripting languages. Another cool thing is you can run external programs you've developed elsewhere to offload parts of your task. So let's say you've got something really horrible and complicated, which could best be done using OOP techniques. No problem; use the Perl or PHP script as a frontend, and call an object oriented program from within the script, passing in the data in one of a few ways. Then you get all the benefit of object oriented programming in the complicated parts, inheritence, reusability, speed of a compiled language, etc, but you also get to work with scripting. I'm pretty sure doing something like that is at best nontrivial in Java. If it's possible at all.
Although I lean towards Perl, personally, I've heard only good things about PHP. Looks interesting!
Fixed IPs are a mixed bag, though. Although a fixed IP lets you house your own server, it also makes it much easier for someone to hack your home machine; in a way you're a sitting duck. And, running a server at home means leaving your home machine turned on all the time, which leaves a hacker plenty of room to take his time and crack your box while you're at work. It's a great big headache waiting to happen.
On the other hand, you can use an ISP which gives you a dynamic IP address via DHCP, and only turn the computer on when you're actually working on it. This makes it infinitely more difficult for someone to mess with you. Not only do they have to determine your dynamically-assigned IP address, but they have to catch you while you're actually online. This moves you up to the top of the tree, above the low-hanging fruit the script kiddies prefer.
Another issue is, if you want to run a bunch of services, it's safer to run them from a co-lo service, so that your personal stuff (like the book you're writing and your email) is on your safer home machine and your public stuff is on a separate, locked down machine in a server cage somewhere. Even if your co-lo gets hacked, none of your personal stuff will get lost. Better for you, isn't it?
My friends make fun of me, saying I'm the most paranoid human alive. I only use laptops, and lock them up (with my cablemodem!) when I'm not using them (Fire safes are cheap!); Whenever I'm online, it's behind a NAT hardware firewall with paranoid settings; and I've got a firewall running on each laptop as well. I never use Microsoft software on any internet-connected machine (at home, at least -- at work I'm stuck with it). And, I never host any services on my local machines (all ports are closed by default).
You don't have to go to those lengths of course. But still, you have to admit, running a server is like painting a big bullseye on your forehead.
What's the big deal about going with a co-lo? usually, with a co-lo, you pay around a hundred bucks a month and supply your own machine, which you then remotely admin using ssh or something. If you want all the additional power you're talking about, you can always spend a little more money and do it right. A side benefit is physical security, which is generally better than that in an apartment (i.e. a locked server cage vs. a one-bedroom with thin wooden doors and a possibly shifty landlord with a key). I understand your point of view, and yes, what you want would be cheaper, but even if ISPs take it away from you you have options.
Most consumers using cable modems have the option of setting up a web page for free through their ISP, and they can publish whatever they want (within certain reasonable limits) on it. Similarly, anyone who can afford about 35.00 a month can get a really solid hosted site together. Just because ISPs don't let you serve from your own PC doesn't mean you can't serve up pages. You just have to find a host... And, this isn't going to go away because it's a big market and it makes money. Those hosting fees add up.
Here's hoping for a triumphant, safe return to Earth and many more safe, successful missions. Congradulations, China! Good job...
...Where you see the rest of us and say, "You too?" And we respond, "But of course! Grab a glass! The keg's cold..."
Husband: "Wife, you have ten seconds to open the door, then something terribly rude will happen."
Wife: "Fuck off!"
Husband (throws paving stone through picture window) : CRASH! Clink, clatter... "Ah, much better. Goodnight, dear, I'll call the glazier in the morning. Please have my copy of the keys ready for me in the morning. If you do, perhaps I won't show these ribald photos of you getting buttsex from the locksmith to the judge during our imminent divorce."
Wife: "..."
Husband: "Oh, by the way, I play golf with that guy. You DO know he has herpes and the clap, don't you? NO? Oh, dear me. Your poor butt is going to HURT..."
Wife: "!!!"
Husband: "Nighty night, dear. No sex necessary, I fucked your sister a few hours ago." (closes door to study before wife can respond).
Wife: "Wha???"
Husband: "I win!"
Boys, boys... When WILL you learn?
Turn those cell phones off, "to conserve energy". Say it; it rolls off the tongue, doesn't it? "Honey, I'm 'conserving energy'!" Then you cannot be called, period -- and almost no telemarketers are crazy enough to leave you a message. Check your messages from time to time, to see that your wife has a flat, etc, but leave the phone off when you're not checking messages or dialling out.
That's what I do... And, the side benefit is, no one is capable of bothering you. Consider this scenario:
Wife (to self): "I wonder where my husband is... The lawn's getting long and we have shopping to do. I think I'll call him and tell him to drag his butt home, I bet he's just in the bar with the boys anyway..."
Ring, ring, "Please leave a message."
Wife (out loud): "Dack, Nabbit! His cell's off! Ooohhh!"
(four hours later, sun going down, too late to mow).
Husband: "Wife, I'm home!"
Wife: (icily) YOUR CELL PHONE WAS OFF.
Husband: "Was it? I turned it on this morning... I wonder if the battery's going dead?"
Wife, grabbing cell phone and repeatedly stabbing the 'ON' button with her thumb: "YOU TURNED IT OFF!"
Husband: "Oh, yeah, I forgot, I was conserving energy... You yelled at me yesterday for turning all the lights on and..."
Wife: "AAAARGH!"
Husband: "Jesus, lose your temper, too. Man... I'm leaving! I'll see you later. While I'm gone, you think about your abusive attitude..."
(Husband goes back to bar. Wife calls mother and shrieks for half an hour straight. When husband gets back, wife is asleep and things are quiet).
Husband: "I win!"
Man... That's a beautiful thing. Thank you for posting that delightful bit of prose, it was wonderful. I'm SO GLAD I killed my landline, and am only using cell phones now...
Not only do I get free long distance...
Not only do I get to carry my phone with me, ready for anything weird that might happen to me...
Not only do I get really great service and zillions of minutes for less than fifty bucks a month (in contrast, my old landline was 45/month not counting long distance and semi-local)...
But, it's illegal for telemarketers to call my cell!
That made my whole day. Thanks again...
Silly boy.
Almost EVERYONE "penetrates" via IIS. It's like a friggin' freebie, so everyone tends to use it. Barring that, they'll go for the RPC thing, or some other service Microsoft stupidly leaves turned on in almost all of their home machines. Or they'll just send the person an email; for a large percentage of users, that'll work like a charm. (Another reason Linux is safer; most Linux email programs are text-mode, without all the weird scripting bullshit Microsoft tucks into Outlook).
If a little hacker cared about stopping the firewall it would be because they want to run an IRC server, or maybe start doing DDOS, or some other stupid script kiddie trick. Which, by the way, is how most worms propagate. And, how most of the more annoying problems happen on the internet. So I guess the firewall thing DOES matter, doesn't it?
Go soak your arrogant, know-nothing little head until your ego shrinks back to normal size, you demented little shit.
See? I can call names too. Do you feel special now?
Blah, blah blah. Calling me names again. How old are you, fifteen? You're so rude and immature.
But, since we're not getting anywhere, let me re-iterate: the network connection comes up while Norton Personal Firewall is still displaying an icon that claims it's disabled. SO, if the firewall is disabled, I guess it's not firewalling, now is it?
And, who cares WHAT you tell me; what are you, the pope? Not that anyone listens to him, either...
They hit the control key, which makes button 1 into button 2. ;)
All of your points on Linux, which you seem to think I'm not aware of, are irrelevant, and you're a moron for trying to throw them at me. BECAUSE, on Linux, YES, you can work with kernel modules, etc, IF YOU HAVE ROOT. But if you're just probing a machine, and trying to GET root, you're up a creek unless the person is running an exploitable service AND that service is running SUID. If the user is even remotely clueful, he'll be running as an unpriviledged user, he'll have most SUID scripts turned off, and it'll be damned hard for you to get the kind of access you would need to do what you're saying.
Compare this with Windows, where due to poor application design, most users run as administrator (because they're added to the administrator group so they can USE their software) and most services people attack are run as administrator (or a relatively priviledged system user). So if you hack any major service or ANYONE's account you're an administrator, and can do whatever the hell you want. Quite a bit different, now, isn't it?
Keep calling me stupid, everyone on Slashdot does, I don't mind. I have a thick skin. But anyone reading the whole thread will say, "well, they called him stupid, but they're not addressing his points."
And, to your TCP/IP stack notes, thanks for the lecture Mr. Wizard, but I think you're putting a little too much faith in Microsoft's systems, there. Because after all, if someone wanted to kill your pesky windows firewall, they'd attack your IIS, and run some code that disables the firewall, rather than crashing it outright, which pops those hooks RIGHT OUT of your precious TCP/IP stack and we're off to the races. Don't be such a schmuck.
Take your book on OS concepts and put it someplace uncomfortable, you arrogant little noob.