ID isn't a theory nor a hypothesis, because you can not test it.
I didn't say it was. If you noticed, I specifically left out the third one, and if you did try what I did with the third one, then it wouldn't work. Why? ID relies on some "facts" that are not provable under current "knowledge" - I'm not saying I agree with ID - from the scientific viewpoint, I don't, and as a Creationist I dislike ID as it fumbles with the facts of both parties, and plays a dumb game of trying to mesh two un-meshable viewpoints.
I guess that is the big differences. Just to make the point again:
1. The big bang is a theory based on observations that tries to explain the genesis of our universe
2. The evolution is a theory, that tries to explain the origin of species.
An interesting part of grammar in English is that it stands that words are similar and basically mean the same thing when one word is substituted for another and the understood meaning doesn't change. For example, substituting 'hypothesis' above for 'theory' doesn't make a difference. Just an interesting observation:
1. The big bang is a [hypothesis] based on observations that tries to explain the genesis of our universe
2. The evolution is a [hypothesis] that tries to explain the origin of species.
It may "scientifically" be a "good" hypothesis based on current "knowledge", but nonetheless it is a hypothesis.
There's no religious problem with the big bang or evolution. It's only a problem for religious fundamentalists. If you don't believe in a clergy with the ability to understand god's message then you're left with the bible as the only source of knowledge about god. The bible is obviously not meant to be interpreted as a literal history of the earth, but fundamentalism has no other source of divine revelation. The bible in their view must be true, from start to finish. Where observable reality differs from the bible, observable reality is wrong.
Quite wrong. While there are many that will argue over the degree to which these lay, there is quite a foundation for understanding the Bible, and how to interpret it. Part of that is literal as history, part of it is figurative, part of it is correction, etc. What the religious "right" and "left" disagree upon is what percentage of each can be read as what - the "right" more or less gives equal weight across the board when interpreting, and uses "common sense" and context to differentiate literal and figurative. However, the "left" argues is that it is all figurative and little or no historical value.
Thus the "left" is willing to accept evolution as "theistic evolution", while the "right" point out the problems with doing such against what is written - what is "known as fact". The "right" allows passages such as Genesis 1 & 2 to be "known as fact" because we can't obverve it and anything further is a hypothesis based on observation of present information with a forced hind-sight that does not account for everything that has or may have happened, often a hind-sight that purposely looks to ignore facts that do not agree with what they want to find.
In either case, there is more discussion about ID, Creation, Theistic Evolution, and Evolution among the religious institutions - its impact on religion and science, how to do scientific research in light of and in ignorance of religion, etc - than there is among the non-religious institutions - schools, colleges, and universities. There has even been a non-religious book published that points this out. (See this post for the book)
You're right in thinking that exceptions should not propagate from library code to client code though -- in fact, that's generally recommended practice -- see my earlier post. But it's also generally accepted to use exceptions *within* the library code, so long as it doesn't spill over into the space of the library user.
Be consistent inside and outside the program or library. Leave not possibility for a spill-over to occur. That's not a weak reason by any means, nor is it a weak reason that it would "encourage lazy error handling".
I don't think any of them referred to the use of exceptions as the lazy person's weak substitute for good error handling; and they refer to exceptions (when discussing non-bug errors) as the first consideration, not the last resort.
They may do just that, but does that make them right? No. If they jumped off a bridge, would you? Now, while Stroustrup may have written the original C++ language; that does not mean he's right about everything since.
And yes, I'm quite aware that dynamically allocated objects will not be automatically destroyed upon exiting from the scope of their allocation, because such objects don't have a "scope". That's why you *give* them a scope by using smart pointers.
"Smart Pointers" are not a solution - just a bandaid. The solution is teaching programmers how to actually program correctly, part of which is managing resources. If you can't do that, then you don't belong teaching programmers how to program, and if a programmer can't do that then they don't belong programming. Pure and simple.
I *do* maintain a program without a strict OEOE rule, and it *is* quite feasible; we've been doing it for many, many years now.
What is your turnover rate of programmers working on the project? OEOE (Open Entry/Open Exit)may be useful for certain kinds of assembly programs, but in general across most any program or programming language it is complete crap, and SESE (Single Entry/Single Exit) should be adhered to. More specifically, OEOE may be good for parts of an OS kernel or driver, but for any application or non-hardware interfacing code in a kernel, SESE is best.
There are lots of functions where OEOE would be an imposition that does not arise from any real need, but from blind adherence to coding "standards".
The "real need" is doing it right, and doing it in a way that results in correct results every time using a consistent, efficient, and well thought out style. OEOE will not achieve this, and will cost you time and money in maintenance that SESE won't. Try tracking a resource that was allocated in one place, and dellocated somewhere else. Or try determining how many different places a program terminates from. With SESE that's very simple - 1. With OEOE, good luck.
SESE is best programming practice. It is also (in good programming circles) the rule, not the exception. OEOE, however, is the exception.
I think we pretty much agree in principle, but the definitions we're using are at disjoint. (That's a problem, because clear communication is very important in this business.) I think what you *meant* to say is, "don't use the default definition of assert because the default assertion failure action is to halt the program without giving much useful information to the end-user." That's a statement I can much more readily agree with.
While I can agree to that at least in principle, I would still not advocate using assert in any form or manner - it's just wrong so far as I'm concerned, and will for all intents and purposes not correct the behaviour that needs to be corrected - that is, telling the user what is wrong and handling it appropriately. The program should terminate as a last resort, after working with the user and the operating system to try to solve the problem.
In referring to the term "crash", I mean any reason why the program terminated without completing its action - either because of a seg fault or because the program hit a point that was either (a) unexpected by the programmer (e.g. resource X did not actually get created) or (b) something didn't happen quite right, and the programmer decided to just quit without trying to figure out what happened - e.g. a lazy programmer.
As per what to do about it, the program should so something like the GUI dialog you talked about, but tell the user what lead to the condition as well - for example, "Program X could not complete its operation because the operating system denied access to the Buffer Pool object while streaming file Y from server Z. Please fill out the information below to help the developers solve this problem.", and then send the information along with the core dump to the developers. Telling the user why the program thinks it has to quite in as much detail as possible (that the average user could understand) will help a long ways in not only debugging the program, and help desk - but also in creating a good perception of the program among your users, and they'll pleasantly be surprised that you think they're not as stupid as they really are, which will reflect well on you and your program.
*(not that I would ever have more than a few news hanging around in my code that aren't in constructors. it's amazing how few you can away with. standard good practice - every time you write 'new' think about how you can not do so, same with type casts. you'll be better for it.)*
Not always possible, but a good idea. For example, you shouldn't be doing:
int* num1 = new int; int* num2 = new int; ... delete num1; delete num2;
in the same function. But there will be times (like dynamic arrays) where you just can't get by without it. (And no, a vector STL or anything similar is not the answer either.)
Rather, just be responsible and make sure that your program's architecture allows for a single point of creation and a single point of deletion for objects that are necessary to be created in one place and handed around throughout the life of a program being different parts of the program.
For example, an array of buffers can not always be defined statically - and likely, in most situations needs to be dynamic. For example, try getting a listing of network interfaces from Windows. The first call will tell you how much memory need - for example, if there are 2 interfaces or 1. You can not hard code a static array there because you won't know how many there will really be - there could be 1000 - and the memory cost would be too much to hard code it, not to mention that it would not allow your program to be flexible.
There are trade offs - and they need to be decided & justified. Don't allocate something on the heap just because you can. Don't do it on the stack either just because you can. Make a valid choice based on why the memory is being allocated, and then back it up by providing the facilities within your program to properly clean it up. (e.g. a buffer pool that is in charge of allocating and destroying any buffers for a specific part of your program's algorithm).
Note that because C++ allows automatic destruction, having a single exit point explicitly represented in the program source code is not terribly important, and sticking hard-and-fast to this rule may lead to some unnecessary performance hits on account of extra calls to class assignment operators, extra class object temporaries, etc.
An explicit "single exit" rule makes more sense in a language like C, where there is no language feature that enables simple automatic clean-up.
Try maintaining a program in any language that does that - it's nearly impossible. Don't count on automatic destruction. Even in C++ if you allocate memory, it won't necessarily delete it at the end. (For example object* A = new object; The new object won't be deleted automatically when the function exits.) And garbage collecting is not an answer either - it may save your butt from memory leaks, but the memory leaks still exist; and it will (a) add overhead, (b) slow down your program, and (c) won't clean them up immediately - it waits until its next scheduled cycle.
Single-Entry-Single-Exit is one of the best programming practices a programmer can have. There are few exceptions to not using it - like certain chunks of code deep inside an OS kernel that just have to work a specific way that doesn't allow for it.
*It's good to be explicit about some things, but don't be inane.*
Actually, it's good to be inane. Why? It'll help you debug it that much faster. Who cares if it takes 2 more seconds to type it in, if it saves you 5 minutes in debugging?!!!
*For example, "int" is *always* "signed int" -- this is in the language definitions. So it's a waste of time to spell it out. Note the signed-ness of plain 'char' is implementation defined, so you could legitimately be explicit about that. But note again that a lot of Standard Library functions use plain 'char', so you have to be careful that your explicitness doesn't break things.*
The standard *may* say that, but don't trust it. It could change in 5 years, and then what? You're code would be broken. Is that change likely? No. But don't trust it. Don't trust your own code. Don't trust that a compiler will follow the standards. The more you don't trust it, the more you are likely to have a program that is rock solid.
That is not to say that you should do something like following:
X = B; if (X == B) { } else { /* Fail */ }
That's inane. But it is perfectly valid to be explicit about things like "signed int". It'll help you read the code, and it'll help you debug the code. And if you do have a problem calling something because it wants an "int" versus a "signed int" than I would suggest writing a wrapper that would do nothing more (could even be inline) than perform the necessary type-casts. (Typcasting yourself could be done too, but using a wrapper would be better.)
Additionally, if the compiler knows that an "int" is a "signed int", then it should do the change for you automatically - if it is a good compiler. But again, you don't necessarily need to trust it to do so; but I would say this is one case where you ought to be able to trust to to make that conversion for you *if* that's what the standard says and it complies with the standard.
*In short: be as explicit as you need to be (such that any human reader could draw the same conclusions), but no more. E.g, the parentheses in "a + (b * c)" are superfluous because everyone knows (or can quickly find out) that binary '*' has higher precedence. But then again, with lots of sub-expressions, it can help to add parentheses, line breaks, and indentation at certain points to ease readability. There's no hard rule for it; you just have to feel things out.*
Be explicit about your parenthese and everything else - it'll help you debug it, and ensure that the compiler understands you correctly. It would also save your butt if whoever wrote the compiler decided to change to a different style of precedence or association (prefix/postfix, etc.). Don't trust 'em - and don't trust yourself to get it right every time, or read it correctly everytime. Like I said above, it'll may take you an extra 2 seconds to write, but it'll likely save you 5 minutes or more in debugging time.
*It does help to be explicit about, say, constructors (which is why the creators of C++ added a keyword just for that purpose)*
I'm not saying anything about keywords in regards to being explicit. I'm simply saying that you be as clear in your code as possible - don't assume that another programmer will assume anything. Be explicit about what your code is and does. Do the same in your commenting.
Ok, but note that some C++ Standard Library functions will throw if they fail. So when you call these functions, you have to think about exception safety, but you can also assume that they have succeeded on the lines that immediately follow the call.
(Implementations vary though, so you'll need to check up on this for your compiler. E.g., with some older compilers, operator new returns NULL upon failure, whereas the Standard says it must throw.)
You still have to, in either case, handle the error and do so without assuming it succeeded. One program I inherited, the programmer assumed every memory allocation completed successfully. Fine under most circumstances, but absolutely horendous if the environment (for whatever reason) becomes overburden and memory becomes extremely scarce (a run away program, or failing RAM). If the call does something (like throw an exception), then use the appropriate means to catch the error and handle it; but don't continue the crappy error methodology just because it did.
Perhaps I misunderstood, but it seems that you're advocating the use of error codes instead of exception throwing/catching.
Quoth Herb Sutter and Andrei Alexandrescu (C++ Coding Standards, item 74): "Report errors at the point they are detected and identified as errors. Handle or translate each error at the nearest level that can do it correctly."
And then there's item 72, which is pretty lengthy and contains lots of references:
"Prefer to use exceptions to report errors.
"Summary
"Prefer using exceptions over error codes to report errors. Use status codes (e.g., return codes, errno) for errors when exceptions cannot be used (see Item 63), and for conditions that are not errors. Use other methods, such as graceful or ungraceful termination, when recovery is not required or is not possible."
(Item 63 basically says, "don't let exceptions propagate beyond the boundaries between your code and the code you don't control.")
Given that these experts have written at length about error handling, and that they suggest a preference for exceptions when dealing with [non-bug] errors from which you can recover, I think you need to talk more about the kinds of cases where you think exceptions are inappropriate (and give some complete code samples).
C++ has been accused of containing some useless features, but I don't think anyone of note has said that about exceptions.
It's rather the other way around - and I don't by any means advocate using a global errno variable. Rather - each object should have a state within itself, retrievable by a function like Get_Error_Code(), with an associated string retrievable via a function like Get_Error_String(Error Code #). Nothing global about it, and the caller should be checking for error codes when there's an error, and then handle and clear it before continuing; though error codes could be set up to add to each other (e.g an error occurs and there's already an existing error, and a different error code can signify both); however, it would be best if a function didn't work if an error existed (unless it could clear that error).
Exceptions, by contrast, just encourage lazy error handling and are (IMHO) crap that should not be used unless absolutely necessary. For example, I'm writing a set of API's. The first few sets are not allowed to use exceptions at all and will be the underlying set for any further API's. One of the last sets, while it will continue to support error codes the same way, will have to (because it's an API) support exceptions so that users in an environment that uses exceptions (for whatever reason) can use the API without having to change their program's error handling system. However, those programmers will likely not handle it at the closest level where something could actually be done (if anything at all), and instead just let the error fall out to somewhere else in the system that has no clue about the original object that generated the exception, nor any manner to be able to handle it.
Perhaps, (and this is just a guess) what you are writing complements what I am saying in some manner (not sure); however, it is not by exception (no pun intended) that the "status codes" (your terminology) should be used, rather it is by exception that exceptions should be used.
I really think you had better qualify this. IMO, assertion failures do not *cause* problems; they are messengers, and the message is always this: "Your program is broken."
I don't think you want to *recover* from a broken state. I think you want to debug it -- find out what went wrong, fix the code, recompile, test, and re-deploy.
It's very simple - don't use assert as assert will just crash the program. Rather, do something better. Detect the error, give the user a good and useful error message, and then terminate the program. You can't do anything else, but at least you can give the user some idea of what happened - of what went wrong - and you can give yourself a good idea where to look to debug it. And, BTW, nothing else in the system can produce a useful message to the user. Life would be a lot easier if everything in an OS did that. (Sure, a core dump helps the developer too, but it won't help the user know what happened, and it won't be very meaningful.)
Asserts just produce crappy software - and BSOD's.
Stable programming can be achieved, and achieved quite well. No single method is the "silver bullet", so to say, but using a VM'd languaged or garbage collected language won't do you any good either. Here's some basic principle for any language that can help make you programs stable.
1. Never trust anything coming in. Always check every parameter to a function and make sure that each is within the expected value ranges. For pointers, you can't tell whether they point to the right place, but you can make sure they are valid. If something doesn't look right, then return an error code - don't continue. Also check everything returned by any function you call - check for the error codes, and actually handle them; if a caller needs to handle it, then return a consistent error code and let it handle it. But, most importantly, HANDLE the errors.
2. HANDLE all the errors from any function or procedure - whether hardware or software. Throwing an "exception" is a bad method to handling the error and really does nothing for the actual problem - it's too generic, and too easily turned into giving the error to a higher level, which just prohibits the higher level from being able to actually overcome the error (fix it, handle it, etc.). Handle everything, and do so meaningfully, and when an error occurs, clean up anything that needs to be cleaned up before returning to the caller or exiting/terminating.
3. NEVER ASSERT!!!! Asserts will only lead to faulty, crashing programs. HANDLE THE ERRORS! (See #1 & #2)
4. Don't trust that system calls succeed - always check that memory is allocated, clear it, and then use it; and check that the correct amount of data got written out to disk or read in.
5. Be explicit about everything in your code. Don't assume that an "int" is signed - declare it as a "signed int"; this will help with reading and understanding the code as well.
6. Be explicit in your logic - use an explicit structure with single-entry-single-exit principles to do the above.
7. Since you're using C++, use Object's to control your resources efficiently. For example, don't just allocate buffers using "new" - create an entity in the program that is to do so, and then use it to do it. Return the buffer to it when you're done, and let it also destroy them. Same goes for threads, and any other resource. Don't rely on the OS, a VM, or a GC to clean up after you. DO IT YOURSELF!
8. Reuse proven code as much as possible, and use efficient algorithms. Sometimes an STL Vector class may be good for you; othertimes it won't be. Be aware of what you're using - its benefits AND costs, and consider them all in the process.
9. Be able to create and destroy, load and unload any object in the system - e.g. libraries. Make sure you can unload a library to re-initialize it if you need to. It would be great to be able to do this even for standard objects, but this must apply especially to libraries - first AND third party - so that you can clean out their errors or reset them if needed.
10. Design and Architect the software to achieve its goals and requirements. After each design and architecture is proposed, revisit the requirements and (a) check that the design meets the requirements, and (b) see what other requirements are then inferred by the design and architecture. Repeat as needed until a version that can be extended is viable. Do not try to do it all in one version.
11. Document. Document. Document. Document your code. Document your design. Document your algorithms. Document your architecture. Write it all down and make sure that anyone can pick up the documents and be able to understand exactly what it is you are doing - write each document to the necessary type of person, e.g. an SDK document should assume software programming background; overviews should be aimed at your manager or your manager's manager and Joe Smoe off the street (not that Joe Smoe will get it - just anyone should be able to understand it given th
What we need to have happen is to force accountability for patent fees, i.e. force some kind of license limit on the amount you can ream people for off of them.
In other words, something like this. Needs some work, but should offer at least a good starting point.
Headphones are always, always, going to have better sound quality over earphones.
Not quite true - headphones might get the technology first, but it would eventually trickle down to the earbuds/earphones. Not to mention that earbuds will have a better quality of sound as there is less interference (and less bouncing of the waves) in getting the sound to your ears.
I would think the little earphones would dammage your ears more than headphones; at the same sounding volume.
True - but the key here is the same volume level. The nice thing about earbuds is that you can get the same quality of sound as headphones at a lower volume level, with less outside interference.
I've been using earbuds for years, and love them. Some are better than others, and expense doesn't necessarily mean better. Currently I find the $10 Sony MDR-J10 earbuds to be the best, and have 2 or 3 pairs of them that I use nearly all the time.
As per the original question of why some people can use them and others can't stand them - I would lean towards the fact that while they are generally comfortable to me (some are more comfortable than others), others can't seem to be able to wear them at all; the cause of which I believe is the size of people ears. Headphones will always be usable by anyone, while for earbuds your ears have to be big enough to hold the earbud.
Except EFI is the BIOS, or rather replaces legacy BIOS. So it's either EFI/BIOS/etc (Phoenix, Award, etc. - there's two alternatives to BIOS right now - EFI is one, I forget the other, but I believe its made by Pheonix), Intel Core Duo, or the OS (WinXP, in this case).
Funny...that works exactly against you, as I am simply not holding that there is a difference between them, so the "equivocation" (from the root of equivocal) in the "misleading" sense (as provided by dictionary.com on equivocal) would be from the scientific community...in other words, the scientific community desires the "falsification by means of vague or ambiguous language" (dictionary.com on equivocation).
FYI - I am not playing the semantics game as claimed in #14572699 by Dimensio (311070) - rather the scientific community is, and purposefully so in order to do exactly what you essentially claimed above - mislead.
Quite similar to what is done in the scientific & medical communities with the word fetus, which while on account of the scientific community English has adopted a slightly different definition - the meaning is essentially "baby" when translated from latin properly. But that's a whole other topic.
If piracy is still rampant on P2P networks, and music sales are still down... doesn't that mean that more people are not buying the music that they claim on slashdot and elsewhere that they'd buy to support the band? What is going on with this? If most of the new music is so shitty you cannot buy a CD online for $12-$15 (sorry, most of the time claiming you're forced to pay $20 is bullshit with the internet) then why is piracy still rampant?
You seem to lack the understanding of the effect piracy has on mediums like music and movies. One good example of the effect is the Anime industry, where there is a lot of piracy; however, unlike the RIAA and the MPAA the industry embraces it and uses it as a way to get the word out about the music, shows, movies, and series. In return, since the fans don't have to play the lawsuit games the fans almost completely honor an "unspoken" code within the industry and purchase the music and movies.
I've personally come across, enjoyed, and purchased a number of series on account of this. And I wish the RIAA and MPAA would learn from the Anime industry how to do it right.
That does not mean that there are not Anime fans out there that do not buy after they watch, or keep it without buying. Most will usually buy it if they like but use the piracy to either (a) get stuff not available in country yet, or (b) sample it before purchasing. Because of how the Anime industry has embraced it, only a small percentage (likely 10%) truly pirate the goods - and usually the fans come down pretty hard on them for doing so. What the RIAA & MPAA need to do is make this same kind of cultural additude adjustment themselves and with their fans. They would likely be surprised at how quickly the profits change, and sales go up.
In scientific usage, a theory does not mean an unsubstantiated guess or hunch, as it often does in other contexts. Scientific theories are never proven to be true, but can be disproven. All scientific understanding takes the form of hypotheses, or conjectures. A theory is in this context a set of hypotheses that are logically bound together (See also hypothetico-deductive method).
Funny how the definition of theory for science is just a rewording of the definition for other contexts. There's a reason why the same word is used - it's the same thing. Get over it.
And for those of you that insist upon calling it the same thing and making it seem like there is a huge difference between them, check out its definition on sites like Dictionary.com: Definition of Theory. If you notice, it's the same. (It does have a "scientific" clause under one of them, but it's still basically the same.)
The difference is that in all cases (scientific or otherwise) it appears to be an "unsubstantiated guess or hunch", but in all cases (scientific or otherwise) it is still based on information that may (or may not) be available to the person calling it "unsubstantiated" - which just means it has not been proven, or shown that the evidence proves it true - corroborating it - to the point where nothing else could be possible.
Or how about this: If the soul goes to heaven immediately at the time of death, then what's the point of a Christian burial? Why don't we just cremate everybody and save valuable real estate for mad scientists and their ilk?
Christians believe in the resurrection when all true followers of Christ will be raised from the dead to join Christ in the sky (Heaven). It has been historically believed (rightly or wrongly) that the body should be buried so that it would be there for the resurrection. We know about decay (they did too), but it was still viewed differently.
Additionally, many of the non-Christian cultures around the early church did cremation, and so it was also done as a means to differentiate themselves from the cultures around them.
Why they celebrate birthdays and not conception days (they're so adamant at trying to control non-believers definitions of "life").
Could you tell me exactly what day you were conceived on? Very few couples know what day the actual conception took place on, but the day of birth is very much defined and known. Thus, we celebrate the known day - the birth day.
Why they believe that one who has no brain activity but body life might still be considered alive on this earth.
It is unknown exactly at what point death occurs as it is unknown to us when the soul leaves the body. Part of the reason this is so contraversial. The answers to all three questions are basically: we shouldn't, we won't, and we will never push our views on non-believers. The Bible is pretty strict about holding other believers accountable for their actions, but we should be leaving the rest of the world alone.
True - the Bible does say that we are not to hold non-believers accountable ourselves, but...
FALSE in that "we should be leaving the rest of the world alone". When Christ was here did He leave the rest of the world alone? Absolutely not. We are to engage the world and challenge it so as to show it the truth found in Christ; not to leave them alone to wallow in their sin and spiritual-death. (True that many "christians" miss this point, and many more don't follow it out of fear (among other things); that, however, does not absolve us or them from this fact.)
Wow, thats the first time I ever heard of Windows Updates being refered to as bars of gold. Seriously, though, thats the only time I use IE anymore.
Wasn't there something posted about Microsoft starting to support Firefox for its own websites including for Windows Update? Yeah...here
Firefox Windows Update Article
So yeah - even Microsoft is supporting more than one browser for some of their most lock-in tying websites (e.g. Windows Update).
I think you missed the point. If a user is dumb enough to run a script or downloaded executable, then that user can still fsck himself. Perhaps the user runs an innocent looking script that claims to clean up dupes in his mailfile and in reality it emails out his private ssh key? Or yeah, it could delete anything he has perms to.
Ah...but you missed the point - it is one thing if the user enables the script to run (chmod +x somescript), but quite another for it to run directly out of the browser like is possible on Windows. It is much harder to execute a script directly out of the browser on Linux because of this. So, at the very least the user has to knowingly and take a few extra steps to run it. If they run it, then yes - they are a dumb user that deserves what happens - but even so, it will only affect that user in most cases. (Per your example, if the attacker gains access via their account and then finds an exploit that can elevate their priviledges then it could affect other users too.)
Never said you did modify any information. Just pointed out that either Microsoft did change over, or at least some servers are returning the IIS info.
Nothing in Unix prevents a user from running a script that says "rm -rf ~", which ends up deleting all of their files. After all, part of the Unix philosophy is not holding the hands of users;).
Actually, there is - it is called permissions. Windows does not really understand the execute permission - it just looks at what file type it is, not what the user (or administrator) desires. That is not to say there are not ways to overcome it, or even ways to exploit programs - there are; but the impact is minimalized by how *nix/bsd security is set up. For the most part, it will only affect one user, not all of them; and even that can be minimalized by the default permissions scheme used, and developers not automatically giving downloaded files the execute permission (just read/write).
There does seem to be an execute permission under Windows, but it is pretty much a joke and no one (not Microsoft, or admins, or anyone else) pays attention to it. So the very fact that *nix/bsd and Mac OS X does pay attention to it (and the community is aware of its use) already puts them lightyears ahead of Windows.
Slashdot Mirror
ID isn't a theory nor a hypothesis, because you can not test it.
I didn't say it was. If you noticed, I specifically left out the third one, and if you did try what I did with the third one, then it wouldn't work. Why? ID relies on some "facts" that are not provable under current "knowledge" - I'm not saying I agree with ID - from the scientific viewpoint, I don't, and as a Creationist I dislike ID as it fumbles with the facts of both parties, and plays a dumb game of trying to mesh two un-meshable viewpoints.
I guess that is the big differences. Just to make the point again:
1. The big bang is a theory based on observations that tries to explain the genesis of our universe
2. The evolution is a theory, that tries to explain the origin of species.
An interesting part of grammar in English is that it stands that words are similar and basically mean the same thing when one word is substituted for another and the understood meaning doesn't change. For example, substituting 'hypothesis' above for 'theory' doesn't make a difference. Just an interesting observation:
1. The big bang is a [hypothesis] based on observations that tries to explain the genesis of our universe
2. The evolution is a [hypothesis] that tries to explain the origin of species.
It may "scientifically" be a "good" hypothesis based on current "knowledge", but nonetheless it is a hypothesis.
There's no religious problem with the big bang or evolution. It's only a problem for religious fundamentalists. If you don't believe in a clergy with the ability to understand god's message then you're left with the bible as the only source of knowledge about god. The bible is obviously not meant to be interpreted as a literal history of the earth, but fundamentalism has no other source of divine revelation. The bible in their view must be true, from start to finish. Where observable reality differs from the bible, observable reality is wrong.
Quite wrong. While there are many that will argue over the degree to which these lay, there is quite a foundation for understanding the Bible, and how to interpret it. Part of that is literal as history, part of it is figurative, part of it is correction, etc. What the religious "right" and "left" disagree upon is what percentage of each can be read as what - the "right" more or less gives equal weight across the board when interpreting, and uses "common sense" and context to differentiate literal and figurative. However, the "left" argues is that it is all figurative and little or no historical value.
Thus the "left" is willing to accept evolution as "theistic evolution", while the "right" point out the problems with doing such against what is written - what is "known as fact". The "right" allows passages such as Genesis 1 & 2 to be "known as fact" because we can't obverve it and anything further is a hypothesis based on observation of present information with a forced hind-sight that does not account for everything that has or may have happened, often a hind-sight that purposely looks to ignore facts that do not agree with what they want to find.
In either case, there is more discussion about ID, Creation, Theistic Evolution, and Evolution among the religious institutions - its impact on religion and science, how to do scientific research in light of and in ignorance of religion, etc - than there is among the non-religious institutions - schools, colleges, and universities. There has even been a non-religious book published that points this out. (See this post for the book)
You're right in thinking that exceptions should not propagate from library code to client code though -- in fact, that's generally recommended practice -- see my earlier post. But it's also generally accepted to use exceptions *within* the library code, so long as it doesn't spill over into the space of the library user.
Be consistent inside and outside the program or library. Leave not possibility for a spill-over to occur. That's not a weak reason by any means, nor is it a weak reason that it would "encourage lazy error handling".
I don't think any of them referred to the use of exceptions as the lazy person's weak substitute for good error handling; and they refer to exceptions (when discussing non-bug errors) as the first consideration, not the last resort.
They may do just that, but does that make them right? No. If they jumped off a bridge, would you? Now, while Stroustrup may have written the original C++ language; that does not mean he's right about everything since.
Notably, C++ is a decent language.
And yes, I'm quite aware that dynamically allocated objects will not be automatically destroyed upon exiting from the scope of their allocation, because such objects don't have a "scope". That's why you *give* them a scope by using smart pointers.
"Smart Pointers" are not a solution - just a bandaid. The solution is teaching programmers how to actually program correctly, part of which is managing resources. If you can't do that, then you don't belong teaching programmers how to program, and if a programmer can't do that then they don't belong programming. Pure and simple.
I *do* maintain a program without a strict OEOE rule, and it *is* quite feasible; we've been doing it for many, many years now.
What is your turnover rate of programmers working on the project? OEOE (Open Entry/Open Exit)may be useful for certain kinds of assembly programs, but in general across most any program or programming language it is complete crap, and SESE (Single Entry/Single Exit) should be adhered to. More specifically, OEOE may be good for parts of an OS kernel or driver, but for any application or non-hardware interfacing code in a kernel, SESE is best.
There are lots of functions where OEOE would be an imposition that does not arise from any real need, but from blind adherence to coding "standards".
The "real need" is doing it right, and doing it in a way that results in correct results every time using a consistent, efficient, and well thought out style. OEOE will not achieve this, and will cost you time and money in maintenance that SESE won't. Try tracking a resource that was allocated in one place, and dellocated somewhere else. Or try determining how many different places a program terminates from. With SESE that's very simple - 1. With OEOE, good luck.
SESE is best programming practice. It is also (in good programming circles) the rule, not the exception. OEOE, however, is the exception.
I think we pretty much agree in principle, but the definitions we're using are at disjoint. (That's a problem, because clear communication is very important in this business.) I think what you *meant* to say is, "don't use the default definition of assert because the default assertion failure action is to halt the program without giving much useful information to the end-user." That's a statement I can much more readily agree with.
While I can agree to that at least in principle, I would still not advocate using assert in any form or manner - it's just wrong so far as I'm concerned, and will for all intents and purposes not correct the behaviour that needs to be corrected - that is, telling the user what is wrong and handling it appropriately. The program should terminate as a last resort, after working with the user and the operating system to try to solve the problem.
In referring to the term "crash", I mean any reason why the program terminated without completing its action - either because of a seg fault or because the program hit a point that was either (a) unexpected by the programmer (e.g. resource X did not actually get created) or (b) something didn't happen quite right, and the programmer decided to just quit without trying to figure out what happened - e.g. a lazy programmer.
As per what to do about it, the program should so something like the GUI dialog you talked about, but tell the user what lead to the condition as well - for example, "Program X could not complete its operation because the operating system denied access to the Buffer Pool object while streaming file Y from server Z. Please fill out the information below to help the developers solve this problem.", and then send the information along with the core dump to the developers. Telling the user why the program thinks it has to quite in as much detail as possible (that the average user could understand) will help a long ways in not only debugging the program, and help desk - but also in creating a good perception of the program among your users, and they'll pleasantly be surprised that you think they're not as stupid as they really are, which will reflect well on you and your program.
*(not that I would ever have more than a few news hanging around in my code that aren't in constructors. it's amazing how few you can away with. standard good practice - every time you write 'new' think about how you can not do so, same with type casts. you'll be better for it.)*
Not always possible, but a good idea. For example, you shouldn't be doing:
int* num1 = new int;
int* num2 = new int;
...
delete num1;
delete num2;
in the same function. But there will be times (like dynamic arrays) where you just can't get by without it. (And no, a vector STL or anything similar is not the answer either.)
Rather, just be responsible and make sure that your program's architecture allows for a single point of creation and a single point of deletion for objects that are necessary to be created in one place and handed around throughout the life of a program being different parts of the program.
For example, an array of buffers can not always be defined statically - and likely, in most situations needs to be dynamic. For example, try getting a listing of network interfaces from Windows. The first call will tell you how much memory need - for example, if there are 2 interfaces or 1. You can not hard code a static array there because you won't know how many there will really be - there could be 1000 - and the memory cost would be too much to hard code it, not to mention that it would not allow your program to be flexible.
There are trade offs - and they need to be decided & justified. Don't allocate something on the heap just because you can. Don't do it on the stack either just because you can. Make a valid choice based on why the memory is being allocated, and then back it up by providing the facilities within your program to properly clean it up. (e.g. a buffer pool that is in charge of allocating and destroying any buffers for a specific part of your program's algorithm).
Note that because C++ allows automatic destruction, having a single exit point explicitly represented in the program source code is not terribly important, and sticking hard-and-fast to this rule may lead to some unnecessary performance hits on account of extra calls to class assignment operators, extra class object temporaries, etc. An explicit "single exit" rule makes more sense in a language like C, where there is no language feature that enables simple automatic clean-up.
Try maintaining a program in any language that does that - it's nearly impossible. Don't count on automatic destruction. Even in C++ if you allocate memory, it won't necessarily delete it at the end. (For example object* A = new object; The new object won't be deleted automatically when the function exits.) And garbage collecting is not an answer either - it may save your butt from memory leaks, but the memory leaks still exist; and it will (a) add overhead, (b) slow down your program, and (c) won't clean them up immediately - it waits until its next scheduled cycle.
Single-Entry-Single-Exit is one of the best programming practices a programmer can have. There are few exceptions to not using it - like certain chunks of code deep inside an OS kernel that just have to work a specific way that doesn't allow for it.
*It's good to be explicit about some things, but don't be inane.*
Actually, it's good to be inane. Why? It'll help you debug it that much faster. Who cares if it takes 2 more seconds to type it in, if it saves you 5 minutes in debugging?!!!
*For example, "int" is *always* "signed int" -- this is in the language definitions. So it's a waste of time to spell it out. Note the signed-ness of plain 'char' is implementation defined, so you could legitimately be explicit about that. But note again that a lot of Standard Library functions use plain 'char', so you have to be careful that your explicitness doesn't break things.*
The standard *may* say that, but don't trust it. It could change in 5 years, and then what? You're code would be broken. Is that change likely? No. But don't trust it. Don't trust your own code. Don't trust that a compiler will follow the standards. The more you don't trust it, the more you are likely to have a program that is rock solid.
That is not to say that you should do something like following:
X = B;
if (X == B)
{
}
else
{
/* Fail */
}
That's inane. But it is perfectly valid to be explicit about things like "signed int". It'll help you read the code, and it'll help you debug the code. And if you do have a problem calling something because it wants an "int" versus a "signed int" than I would suggest writing a wrapper that would do nothing more (could even be inline) than perform the necessary type-casts. (Typcasting yourself could be done too, but using a wrapper would be better.)
Additionally, if the compiler knows that an "int" is a "signed int", then it should do the change for you automatically - if it is a good compiler. But again, you don't necessarily need to trust it to do so; but I would say this is one case where you ought to be able to trust to to make that conversion for you *if* that's what the standard says and it complies with the standard.
*In short: be as explicit as you need to be (such that any human reader could draw the same conclusions), but no more. E.g, the parentheses in "a + (b * c)" are superfluous because everyone knows (or can quickly find out) that binary '*' has higher precedence. But then again, with lots of sub-expressions, it can help to add parentheses, line breaks, and indentation at certain points to ease readability. There's no hard rule for it; you just have to feel things out.*
Be explicit about your parenthese and everything else - it'll help you debug it, and ensure that the compiler understands you correctly. It would also save your butt if whoever wrote the compiler decided to change to a different style of precedence or association (prefix/postfix, etc.). Don't trust 'em - and don't trust yourself to get it right every time, or read it correctly everytime. Like I said above, it'll may take you an extra 2 seconds to write, but it'll likely save you 5 minutes or more in debugging time.
*It does help to be explicit about, say, constructors (which is why the creators of C++ added a keyword just for that purpose)*
I'm not saying anything about keywords in regards to being explicit. I'm simply saying that you be as clear in your code as possible - don't assume that another programmer will assume anything. Be explicit about what your code is and does. Do the same in your commenting.
You still have to, in either case, handle the error and do so without assuming it succeeded. One program I inherited, the programmer assumed every memory allocation completed successfully. Fine under most circumstances, but absolutely horendous if the environment (for whatever reason) becomes overburden and memory becomes extremely scarce (a run away program, or failing RAM). If the call does something (like throw an exception), then use the appropriate means to catch the error and handle it; but don't continue the crappy error methodology just because it did.
It's rather the other way around - and I don't by any means advocate using a global errno variable. Rather - each object should have a state within itself, retrievable by a function like Get_Error_Code(), with an associated string retrievable via a function like Get_Error_String(Error Code #). Nothing global about it, and the caller should be checking for error codes when there's an error, and then handle and clear it before continuing; though error codes could be set up to add to each other (e.g an error occurs and there's already an existing error, and a different error code can signify both); however, it would be best if a function didn't work if an error existed (unless it could clear that error).
Exceptions, by contrast, just encourage lazy error handling and are (IMHO) crap that should not be used unless absolutely necessary. For example, I'm writing a set of API's. The first few sets are not allowed to use exceptions at all and will be the underlying set for any further API's. One of the last sets, while it will continue to support error codes the same way, will have to (because it's an API) support exceptions so that users in an environment that uses exceptions (for whatever reason) can use the API without having to change their program's error handling system. However, those programmers will likely not handle it at the closest level where something could actually be done (if anything at all), and instead just let the error fall out to somewhere else in the system that has no clue about the original object that generated the exception, nor any manner to be able to handle it.
Perhaps, (and this is just a guess) what you are writing complements what I am saying in some manner (not sure); however, it is not by exception (no pun intended) that the "status codes" (your terminology) should be used, rather it is by exception that exceptions should be used.
It's very simple - don't use assert as assert will just crash the program. Rather, do something better. Detect the error, give the user a good and useful error message, and then terminate the program. You can't do anything else, but at least you can give the user some idea of what happened - of what went wrong - and you can give yourself a good idea where to look to debug it. And, BTW, nothing else in the system can produce a useful message to the user. Life would be a lot easier if everything in an OS did that. (Sure, a core dump helps the developer too, but it won't help the user know what happened, and it won't be very meaningful.)
Asserts just produce crappy software - and BSOD's.
Stable programming can be achieved, and achieved quite well. No single method is the "silver bullet", so to say, but using a VM'd languaged or garbage collected language won't do you any good either. Here's some basic principle for any language that can help make you programs stable.
1. Never trust anything coming in. Always check every parameter to a function and make sure that each is within the expected value ranges. For pointers, you can't tell whether they point to the right place, but you can make sure they are valid. If something doesn't look right, then return an error code - don't continue. Also check everything returned by any function you call - check for the error codes, and actually handle them; if a caller needs to handle it, then return a consistent error code and let it handle it. But, most importantly, HANDLE the errors.
2. HANDLE all the errors from any function or procedure - whether hardware or software. Throwing an "exception" is a bad method to handling the error and really does nothing for the actual problem - it's too generic, and too easily turned into giving the error to a higher level, which just prohibits the higher level from being able to actually overcome the error (fix it, handle it, etc.). Handle everything, and do so meaningfully, and when an error occurs, clean up anything that needs to be cleaned up before returning to the caller or exiting/terminating.
3. NEVER ASSERT!!!! Asserts will only lead to faulty, crashing programs. HANDLE THE ERRORS! (See #1 & #2)
4. Don't trust that system calls succeed - always check that memory is allocated, clear it, and then use it; and check that the correct amount of data got written out to disk or read in.
5. Be explicit about everything in your code. Don't assume that an "int" is signed - declare it as a "signed int"; this will help with reading and understanding the code as well.
6. Be explicit in your logic - use an explicit structure with single-entry-single-exit principles to do the above.
7. Since you're using C++, use Object's to control your resources efficiently. For example, don't just allocate buffers using "new" - create an entity in the program that is to do so, and then use it to do it. Return the buffer to it when you're done, and let it also destroy them. Same goes for threads, and any other resource. Don't rely on the OS, a VM, or a GC to clean up after you. DO IT YOURSELF!
8. Reuse proven code as much as possible, and use efficient algorithms. Sometimes an STL Vector class may be good for you; othertimes it won't be. Be aware of what you're using - its benefits AND costs, and consider them all in the process.
9. Be able to create and destroy, load and unload any object in the system - e.g. libraries. Make sure you can unload a library to re-initialize it if you need to. It would be great to be able to do this even for standard objects, but this must apply especially to libraries - first AND third party - so that you can clean out their errors or reset them if needed.
10. Design and Architect the software to achieve its goals and requirements. After each design and architecture is proposed, revisit the requirements and (a) check that the design meets the requirements, and (b) see what other requirements are then inferred by the design and architecture. Repeat as needed until a version that can be extended is viable. Do not try to do it all in one version.
11. Document. Document. Document. Document your code. Document your design. Document your algorithms. Document your architecture. Write it all down and make sure that anyone can pick up the documents and be able to understand exactly what it is you are doing - write each document to the necessary type of person, e.g. an SDK document should assume software programming background; overviews should be aimed at your manager or your manager's manager and Joe Smoe off the street (not that Joe Smoe will get it - just anyone should be able to understand it given th
What we need to have happen is to force accountability for patent fees, i.e. force some kind of license limit on the amount you can ream people for off of them.
In other words, something like this. Needs some work, but should offer at least a good starting point.
Headphones are always, always, going to have better sound quality over earphones.
Not quite true - headphones might get the technology first, but it would eventually trickle down to the earbuds/earphones. Not to mention that earbuds will have a better quality of sound as there is less interference (and less bouncing of the waves) in getting the sound to your ears.
I would think the little earphones would dammage your ears more than headphones; at the same sounding volume.
True - but the key here is the same volume level. The nice thing about earbuds is that you can get the same quality of sound as headphones at a lower volume level, with less outside interference.
I've been using earbuds for years, and love them. Some are better than others, and expense doesn't necessarily mean better. Currently I find the $10 Sony MDR-J10 earbuds to be the best, and have 2 or 3 pairs of them that I use nearly all the time.
As per the original question of why some people can use them and others can't stand them - I would lean towards the fact that while they are generally comfortable to me (some are more comfortable than others), others can't seem to be able to wear them at all; the cause of which I believe is the size of people ears. Headphones will always be usable by anyone, while for earbuds your ears have to be big enough to hold the earbud.
My bet the problem is in BIOS, and not EFI.
Except EFI is the BIOS, or rather replaces legacy BIOS. So it's either EFI/BIOS/etc (Phoenix, Award, etc. - there's two alternatives to BIOS right now - EFI is one, I forget the other, but I believe its made by Pheonix), Intel Core Duo, or the OS (WinXP, in this case).
What you're doing is called equivocation.
Funny...that works exactly against you, as I am simply not holding that there is a difference between them, so the "equivocation" (from the root of equivocal) in the "misleading" sense (as provided by dictionary.com on equivocal) would be from the scientific community...in other words, the scientific community desires the "falsification by means of vague or ambiguous language" (dictionary.com on equivocation).
FYI - I am not playing the semantics game as claimed in #14572699 by Dimensio (311070) - rather the scientific community is, and purposefully so in order to do exactly what you essentially claimed above - mislead.
Quite similar to what is done in the scientific & medical communities with the word fetus, which while on account of the scientific community English has adopted a slightly different definition - the meaning is essentially "baby" when translated from latin properly. But that's a whole other topic.
If piracy is still rampant on P2P networks, and music sales are still down... doesn't that mean that more people are not buying the music that they claim on slashdot and elsewhere that they'd buy to support the band? What is going on with this? If most of the new music is so shitty you cannot buy a CD online for $12-$15 (sorry, most of the time claiming you're forced to pay $20 is bullshit with the internet) then why is piracy still rampant?
You seem to lack the understanding of the effect piracy has on mediums like music and movies. One good example of the effect is the Anime industry, where there is a lot of piracy; however, unlike the RIAA and the MPAA the industry embraces it and uses it as a way to get the word out about the music, shows, movies, and series. In return, since the fans don't have to play the lawsuit games the fans almost completely honor an "unspoken" code within the industry and purchase the music and movies.
I've personally come across, enjoyed, and purchased a number of series on account of this. And I wish the RIAA and MPAA would learn from the Anime industry how to do it right.
That does not mean that there are not Anime fans out there that do not buy after they watch, or keep it without buying. Most will usually buy it if they like but use the piracy to either (a) get stuff not available in country yet, or (b) sample it before purchasing. Because of how the Anime industry has embraced it, only a small percentage (likely 10%) truly pirate the goods - and usually the fans come down pretty hard on them for doing so. What the RIAA & MPAA need to do is make this same kind of cultural additude adjustment themselves and with their fans. They would likely be surprised at how quickly the profits change, and sales go up.
In scientific usage, a theory does not mean an unsubstantiated guess or hunch, as it often does in other contexts. Scientific theories are never proven to be true, but can be disproven. All scientific understanding takes the form of hypotheses, or conjectures. A theory is in this context a set of hypotheses that are logically bound together (See also hypothetico-deductive method).
Funny how the definition of theory for science is just a rewording of the definition for other contexts. There's a reason why the same word is used - it's the same thing. Get over it.
And for those of you that insist upon calling it the same thing and making it seem like there is a huge difference between them, check out its definition on sites like Dictionary.com: Definition of Theory.
If you notice, it's the same. (It does have a "scientific" clause under one of them, but it's still basically the same.)
The difference is that in all cases (scientific or otherwise) it appears to be an "unsubstantiated guess or hunch", but in all cases (scientific or otherwise) it is still based on information that may (or may not) be available to the person calling it "unsubstantiated" - which just means it has not been proven, or shown that the evidence proves it true - corroborating it - to the point where nothing else could be possible.
Or how about this: If the soul goes to heaven immediately at the time of death, then what's the point of a Christian burial? Why don't we just cremate everybody and save valuable real estate for mad scientists and their ilk?
Christians believe in the resurrection when all true followers of Christ will be raised from the dead to join Christ in the sky (Heaven). It has been historically believed (rightly or wrongly) that the body should be buried so that it would be there for the resurrection. We know about decay (they did too), but it was still viewed differently.
Additionally, many of the non-Christian cultures around the early church did cremation, and so it was also done as a means to differentiate themselves from the cultures around them.
Why they celebrate birthdays and not conception days (they're so adamant at trying to control non-believers definitions of "life").
Could you tell me exactly what day you were conceived on? Very few couples know what day the actual conception took place on, but the day of birth is very much defined and known. Thus, we celebrate the known day - the birth day.
Why they believe that one who has no brain activity but body life might still be considered alive on this earth.
It is unknown exactly at what point death occurs as it is unknown to us when the soul leaves the body. Part of the reason this is so contraversial.
The answers to all three questions are basically: we shouldn't, we won't, and we will never push our views on non-believers. The Bible is pretty strict about holding other believers accountable for their actions, but we should be leaving the rest of the world alone.
True - the Bible does say that we are not to hold non-believers accountable ourselves, but...
FALSE in that "we should be leaving the rest of the world alone". When Christ was here did He leave the rest of the world alone? Absolutely not. We are to engage the world and challenge it so as to show it the truth found in Christ; not to leave them alone to wallow in their sin and spiritual-death. (True that many "christians" miss this point, and many more don't follow it out of fear (among other things); that, however, does not absolve us or them from this fact.)
Wow, thats the first time I ever heard of Windows Updates being refered to as bars of gold. Seriously, though, thats the only time I use IE anymore.
Wasn't there something posted about Microsoft starting to support Firefox for its own websites including for Windows Update? Yeah...here Firefox Windows Update Article
So yeah - even Microsoft is supporting more than one browser for some of their most lock-in tying websites (e.g. Windows Update).
I think you missed the point. If a user is dumb enough to run a script or downloaded executable, then that user can still fsck himself. Perhaps the user runs an innocent looking script that claims to clean up dupes in his mailfile and in reality it emails out his private ssh key? Or yeah, it could delete anything he has perms to.
Ah...but you missed the point - it is one thing if the user enables the script to run (chmod +x somescript), but quite another for it to run directly out of the browser like is possible on Windows. It is much harder to execute a script directly out of the browser on Linux because of this. So, at the very least the user has to knowingly and take a few extra steps to run it. If they run it, then yes - they are a dumb user that deserves what happens - but even so, it will only affect that user in most cases. (Per your example, if the attacker gains access via their account and then finds an exploit that can elevate their priviledges then it could affect other users too.)
I have not modified any information
Never said you did modify any information. Just pointed out that either Microsoft did change over, or at least some servers are returning the IIS info.
Nothing in Unix prevents a user from running a script that says "rm -rf ~", which ends up deleting all of their files. After all, part of the Unix philosophy is not holding the hands of users ;).
Actually, there is - it is called permissions. Windows does not really understand the execute permission - it just looks at what file type it is, not what the user (or administrator) desires. That is not to say there are not ways to overcome it, or even ways to exploit programs - there are; but the impact is minimalized by how *nix/bsd security is set up. For the most part, it will only affect one user, not all of them; and even that can be minimalized by the default permissions scheme used, and developers not automatically giving downloaded files the execute permission (just read/write).
There does seem to be an execute permission under Windows, but it is pretty much a joke and no one (not Microsoft, or admins, or anyone else) pays attention to it. So the very fact that *nix/bsd and Mac OS X does pay attention to it (and the community is aware of its use) already puts them lightyears ahead of Windows.