I recall reading a story somewhere - might have been slashdot, I don't remember - where some country greatly reduced its cases of MRSA by no longer prescribing antibiotics unless they were really needed. I think it was The Netherlands?
And you also mean the porting of thousands and thousands of x86 apps as well?
That's what emulation is for; if MS decides to port Windows to ARM, they'll probably provide an emulator and a shim layer for native calls, and at least support a number of major Windows apps (even though they'll probably run S.L.O.W.L.Y. to begin with). Silverlight and.NET apps should also run more or less out of the box.
Google deployed maps in a standard browser using DHTML
Well, duh. Terraserver was launched in 1998, when most people used either IE3, or Netscape 3, neither of which supported DHTML. Google just took the idea and updated it to the state of the technology at the time when they launched.
But everyone just seems to ignore the fact that their maps and streetview is a blatant rip off of Google
Or, people who actually know what they're talking about, will know that Microsoft had Terraserver back in 1998, while Google bought their maps technology years later, in 2004 and actually launched it in 2005.
"Since many board members are senior executives at other firms and sit on each others boards, there really isn't much incentive for them to not grant large parachutes and such. It simply wouldn't be rational to potentially jeopardize their own upcoming reward."
So, why don't the stockholder vote these board members out?
Of course, that's the simplistic answer. Reality is, as usual, more complex. There are many mechanisms in place that stop or deflect shareholder revolt. Some of the mechanisms are used by the boards themselves - information suppression or obfuscation (how many small shareholders are knowledgeable enough to understand the employment contracts of a CEO?), misleading reports, bad decisions that satisfy groups of shareholders (like paying dividends at the wrong time), and others . Some are not, like the inherent inertia of most shareholders, and especially the fact that many of the largest shareholders in major companies are institutional: banks, mutual funds, pension funds, investment companies. The boards of THOSE shareholders are exactly the people the GP was talking about, and they won't vote to replace their country club colleagues.
Yes, of course, but there is a major difference in public perception, consequences and even logistics between snooping into somebody's data (especially if you can without the owner's knowledge), and hauling him in for a meeting with the rubber hose. While even warantless privacy breaches are regarded with apathy by the majority of Americans (or even rationalized by some), picking up random people for rubber hosing without warrants would be politically much more difficult to justify and impossible to do on the same scale (if only because of the expense of industrial scale torturing).
It's also important to understand that some individuals are much more interesting to snoopers than others. Snoopers will look at your data because it's so easy and cheap (for them), but if the process becomes expensive (be it in units of CPU power, warrants or political fall-back), the snoopers will concentrate their effort onto the individuals of interest and let you alone
OTOH, given the lack of interest of the majority of people, the very act of encrypting your data will probably move you to the "interesting" category. It would therefore be really good if the commercial PCs would enable strong encryption by default.
They added this OO stuff because you can't do much on windows with text processing tools (i.e. parse the registry),
That's just not true; there are plenty of text processing tools in Windows, including ports of all the Unix utilities. If anybody needed it, it's trivial to write some utility that reads the registry and dumps it to stdout for parsing. They added the OO stuff because it's a much more powerful and modern approach.
In the end, this OO stuff makes it more complex and less powerfull than the good old character streams, which work so well exactly because they are damn simple.
I'll have to disagree; character streams are simple, but this simplicity makes them less powerful, not more. The programmer is forced to do a lot of work the computer ought to handle. As to the complexity, this is due to the data itself: modern applications push around all kinds of data that aren't, by their nature, character strings. The Unix approach requires applications to convert the data to character streams and back (so the programmer needs to design a format complex enough to represent the data items and their relationships as character streams, write serialization code and parsers to convert it back). That's a lot of overhead.
But wouldn't that be more overhead (passing an object) because now the application accepting said list of files has to understand the structure of passed object in order to process it correctly, where in Linux you simply pass text/streams as specified by the accepting application. These applications can be written by anyone with no prior knowledge of the object structure of another application that may be sending it information.
On the contrary, the overhead ought to be smaller with PowerShell; first, cmdlets run in the PS process: once instantiated, passing references around should be enough, and objects don't need to be marshalled and translated as a step of piping from one cmdlet to another. Compared to the Unix model, there is no need to serialize the internal object to stdout, push it to a pipe (maybe requiring OS involvement, buffering, etc.), very little need for custom glue code that modifies the output to make it understandable to the second app, and no need to deserialize the result from stdin into the internal representation of the accepting application. And even if your apps didn't run in the same process, the CLI handles serialization and deserialization for you, so you don't need to write your own custom parser - fun as it may be:)
Your other concern, that the accepting cmdlet must understand the structure of the incoming object is not a problem either: the accepting cmdlet does not usually need to understand all of the structure of the objects received. Often the requirement is simply that the objects in question implement a certain interface. That gives one a lot of flexibility, because you can push very different objects through without having to write glue code, as long as the required interface exists. Note also that in the CLI, some properties or methods are predefined (for example the ToString() method), and that the receiving application can use reflection to investigate the methods and properties exposed by the input objects.
Anyone care to point out to me how PowerShell can be more "integrated" than bash?
The references to the CLI should give you an indication. The integration is between components running under PowerShell. PowerShell cmdlets use object pipelines to communicate: they send whole objects to each other, and can all access well known and defined properties of those objects. I haven't seen this kind of integration under Unix, where the standard model is to pipe character streams. This requires serialization, weird and often painful custom parsing with liberal use of text processing tools like awk, sed and so on. See here for more details.
Well, I saw Coraline in 3D, with the red/blue glasses; I won't repeat the experience. The 3D effect came and went, glasses got annoying after a time, I had to keep my head straight up or the two images got out of sync (so no stretching on the sofa), the colors were all washed up and changed weirdly (maybe my eyes aren't trained to correct for brightness with colored glasses?). But even if the quality were better, I don't think this kind of gimmick adds much to the movie. I'll wait for real 3D displays, maybe holography-based.
Except that no one I knows blasts Hotmail or Live messenger or those services
All right, but apart from the sanitation, the medicine, education, wine, public order, irrigation, roads, a fresh water system, and public health, what have the Romans ever done for us?"
Windows 7 Starter Edition won't let you run more than 3 windows at a time
You really have no idea what you're talking about, do you? Or else, given your posts here, you're intentionally spreading FUD. First, comparison with the Starter edition is at least misleading. In the USA the most usual versions are going to be Home Premium or higher. Unless Granny has a tiny netbook (which I wouldn't foist on any of my elderly relatives), you'd have to bend over backwards to get your grandmother a Starter Edition machine. Second, your assertion about the 3 application limit is just plain untrue. Go educate yourselfa bit before posting FUD.
You mean using Google services? Do you really think Google would bar people from using their services from other browsers/OSes?
You have it exactly backwards: of course Google won't stop people from using their services from anywhere. The services (and ads) is how they make money. They don't try to monetize the desktop software, but they'll use Chrome to drive people from using other companies' services to theirs. It probably won't be a straightforward refusal to connect to say Yahoo, but the Google OS will be (surprise, surprise) optimized to work with Google's data centers, it will use the internal knowledge Google programmers have about how the server side works, disadvantaging other competitors for the data center. New services and features on the data center will work first in Chrome, reinforcing the loop.
By the same token, it's in Google interest to make the Chrome OS code free and available. People studying it will learn how to better connect and work *with Google's ad servers*, not with Yahoo's or MSN's, or other Google competitors'. Thus, Google would extend their predominance in the data center/search business to the desktop.
I think most people will stick with Windows and proper GNU/Linux netbooks
Yeah, this sounds to me like just another try at the failed Internet appliance idea. Didn't work then, and I doubt it'll work now. With a netbook you should be able to run everything Chrome has (as long as you have a browser and a network connection), plus a huge variety of other stuff. For example, on planes I carry a netbook with a few movies and a lot of music; will I be able to use a Chrome device for that?
Maybe if the price were significantly better, I might consider one of those things, but again I don't see how. Netbooks are cheap enough as is, and I don't believe manufacturers will be able to save much on Chrome OS devices.
This. The Micro Framework is for resource-constrained embedded devices... which are just about the last place you'd want to run bytecode anyway, as far as I can see. We've got tons of embedded stuff where I work, but I fail to see how controllers for mechanical bits and pieces are going to benefit from having the CLR, object classes, GUIs, etc. made available to them.
I think they're targetting the same area as some embedded Java implementations, like MicroJava. You're getting a nice programming environment (you can use Visual Studio to write C# software for your embedded app), you're getting automatic memory management and it'll offer a migration path for people familiar with larger platforms. While it's not going to be as efficient as hand-tightened C and/or assembly code, it should allow faster development for embedded applications.
Yes, I know they're hoping to scoop the mobile market, but which part of it - the non-smartphone (dumbphone) market?
Not sure they're interested only (or even mainly) in the mobile market; the.NET MF can run on much lower performance processors than the ones used in phones, even feature phones (i.e., not smartphones). From what I've seen most phones use ARM 9 level CPUs, or even ARM + DSP combos, like the TI's OMAP (please feel free to correct me, phones aren't an area I have much interest in). That's overkill for the.NET MF which can happily run on ARM7 level CPUs.
.NET micro is mostly for embedded devices running WinCE.
Nope, you're wrong. You're thinking of the.Net Compact Framework. Basically there are three.NET implementations available from MS (ignoring Rotor for the time being). The Windows one (known as "the.Net Framework") is the largest, with lots of libraries and capabilities. The Compact Framework targets Win CE level devices (fewer resources, lower capabilities), and takes about 12 Mbytes. The.NET Micro Framework targets even smaller devices; it has a subset of the.NET classes, and can fit in 300 kBytes or less. The.NET Micro Framework doesn't need an OS to run (but it can run on an OS). That's the thing that was running in the (now defunct) SPOT watches and MSN Direct traffic dongles. Those were tiny devices which couldn't have run Win CE.
That's actually a misconception. It is fairly widespread, but it's a misconception nevertheless. Secure passwords don't "demand" nonstandard characters at all, and I'm pretty annoyed sometimes at web sites that require one to go through all kinds of contortions to get an acceptable password (lower case and upper case, symbols, numbers and a partridge in a pear tree). They only show that the web designer doesn't understand security.
Let me explain:
A strong password is one that can not be easily guessed or cracked. That means some things like your dog's name, or your birthday should not be used. This information is available in all kinds of places, and an attacker can get it and try it. Dictionary attacks against passwords use huge lists of words (dictionaries), trying all of them until the attack succeeds. That means it's not a good idea to use a real word ("Swordfish"). Modern dictionary attack software also tries varieties of "leet" spelling ("Sw0rdf!sh"), so that's not a good password either (even though it does use upper/lower case, numbers and symbols).
The important thing to understand though, is that any such attack is basically a search through the total password space (the password space being the total number of combinations possible with the given symbol set. For example, if your password length is 5, and you can use only lowercase letters, the password space is composed of the combinations from 'aaaaa' through 'zzzzz'). In order to defend against an attack you need to make the search as difficult as possible. That means two thigs: first, the password space must be large (otherwise the attacker can simply do an exhaustive search through all possible combinations until he finds the right one). Second, the password's position in the password space must be as random as possible. The more a priori information your attacker has about your password, the easier his work is. For example, people aren't very good at generating random passwords, and that's why dictionary attacks work: the attacker only needs to search through the small subset of "real words" of this password space, using the fact that many people will use existing words (maybe with a few fairly predictable changes). If the password is truly random, the attacker will have to do a brute force search through your password space, which is usually impractical.
To return to the initial misconception: the requirement to use nonstandard characters is an attempt to increase the number of random bits in the password, given the user's tendency to pick short passwords. It is not the only one; another way is to make the password longer. It's fairly trivial to compute where a longer password composed only of say lower case characters becomes as strong as a given (shorter) password that uses a larger symbol set (see here for details). Note that forcing users to use nonstandard characters may make your password less secure, because it reduces your password space: an attacker doesn't need to try any non-conforming password, so his work is simplified.
Sure, let's talk about Apache then: Apache 2.2.x, 17 advisories, 28 vulnerabilities, 2 unpatched. IIS 7.x, 2 advisories, 2 vulnerabilities, all patched. Are you going to apologize now? I didn't think so.
Do you get paid to shill?
Being a devil's advocate on an issue != being a troll on an issue, but pretending to be a devil's advocate just so you can FUD = Troll.
You don't know what you're talking about (as shown above), and you attack the person instead of the message. On top of that, you've been spamming your silly "shilling" accusation all over the place, no matter what other posters say. I think you're the troll here, and not a very bright one either.
The universe could simply induce a sufficient e/m force to stop the proton beams colliding. It wouldn't take much, on a cosmic scale, and would be a far more likely outcome than an entire macroscopic object being foobared just to protect the continuity of the universe
ObSF: Connie Willis, "To Say Nothing of the Dog", where the Universe arranges drowning cats, stolen Victorian ironmongery, jumble sales and croquet games to avoid paradox:). (very good book, BTW, especially if you like British humor and Jerome K. Jerome)
Not a new idea; I read a short story (blanking on the title, sorry) written by the Russian SF authors Arkady and Boris Strugatsky sometimes in the seventies. In the story, a physicist teetering on the brink of a major discovery that would change the Universe gets interrupted in his work by weirder and weirder occurences, including a gun-toting dwarf. After reflection he realizes it's a reaction from the Universe, which tends to conserve its state, under some kind of Le Chtelier's principle.
My understanding is that in England, most of the time if you are born in the "working class", your children will die as part of the "working class". If you look at U.S. statistics, you discover that most of the people in the bottom quarter of wealth in the population ten years ago, aren't in the bottom quarter today
Your understanding doesn't seem to match facts. This study indicates that the UK and the US have similar degrees of social mobility, and they're both at the bottom of the list, compared to Canada, Germany and other developed countries.
Might result, as in "someone finds some BSD-licensed code, makes some changes and releases a closed-source paid version". Mind you, this scenario is not inherently a bad thing, but it fits some of the many definitions of "restricting freedom", wether the restriction is actually an issue or not - in this case, someone who ends up being a user of the released binary is deprived of the right to see the source code and modify it
You're confused here: the user of the released binary is not deprived of any rights as far as the original code is concerned: he still has full access to the original BSD code, and can modify it to his heart's content. The user doesn't have access to the *new* code, developed by a second party, but this is a decision the second party coder has made. It's not correct to blame the original programmer or the original licence for what the second party does. As far as I can see, a BSD licence gives freedom both to the user (who can do whatever with the BSD code), and to the second party coder, who can do what he wants with *his* code.
Slashdot Mirror
I recall reading a story somewhere - might have been slashdot, I don't remember - where some country greatly reduced its cases of MRSA by no longer prescribing antibiotics unless they were really needed. I think it was The Netherlands?
It was Norway
And you also mean the porting of thousands and thousands of x86 apps as well?
That's what emulation is for; if MS decides to port Windows to ARM, they'll probably provide an emulator and a shim layer for native calls, and at least support a number of major Windows apps (even though they'll probably run S.L.O.W.L.Y. to begin with). Silverlight and .NET apps should also run more or less out of the box.
Google deployed maps in a standard browser using DHTML
Well, duh. Terraserver was launched in 1998, when most people used either IE3, or Netscape 3, neither of which supported DHTML. Google just took the idea and updated it to the state of the technology at the time when they launched.
But everyone just seems to ignore the fact that their maps and streetview is a blatant rip off of Google
Or, people who actually know what they're talking about, will know that Microsoft had Terraserver back in 1998, while Google bought their maps technology years later, in 2004 and actually launched it in 2005.
"Since many board members are senior executives at other firms and sit on each others boards, there really isn't much incentive for them to not grant large parachutes and such. It simply wouldn't be rational to potentially jeopardize their own upcoming reward."
So, why don't the stockholder vote these board members out?
Of course, that's the simplistic answer. Reality is, as usual, more complex. There are many mechanisms in place that stop or deflect shareholder revolt. Some of the mechanisms are used by the boards themselves - information suppression or obfuscation (how many small shareholders are knowledgeable enough to understand the employment contracts of a CEO?), misleading reports, bad decisions that satisfy groups of shareholders (like paying dividends at the wrong time), and others . Some are not, like the inherent inertia of most shareholders, and especially the fact that many of the largest shareholders in major companies are institutional: banks, mutual funds, pension funds, investment companies. The boards of THOSE shareholders are exactly the people the GP was talking about, and they won't vote to replace their country club colleagues.
Yes, of course, but there is a major difference in public perception, consequences and even logistics between snooping into somebody's data (especially if you can without the owner's knowledge), and hauling him in for a meeting with the rubber hose. While even warantless privacy breaches are regarded with apathy by the majority of Americans (or even rationalized by some), picking up random people for rubber hosing without warrants would be politically much more difficult to justify and impossible to do on the same scale (if only because of the expense of industrial scale torturing).
It's also important to understand that some individuals are much more interesting to snoopers than others. Snoopers will look at your data because it's so easy and cheap (for them), but if the process becomes expensive (be it in units of CPU power, warrants or political fall-back), the snoopers will concentrate their effort onto the individuals of interest and let you alone
OTOH, given the lack of interest of the majority of people, the very act of encrypting your data will probably move you to the "interesting" category. It would therefore be really good if the commercial PCs would enable strong encryption by default.
They added this OO stuff because you can't do much on windows with text processing tools (i.e. parse the registry),
That's just not true; there are plenty of text processing tools in Windows, including ports of all the Unix utilities. If anybody needed it, it's trivial to write some utility that reads the registry and dumps it to stdout for parsing. They added the OO stuff because it's a much more powerful and modern approach.
In the end, this OO stuff makes it more complex and less powerfull than the
good old character streams, which work so well exactly because they are damn simple.
I'll have to disagree; character streams are simple, but this simplicity makes them less powerful, not more. The programmer is forced to do a lot of work the computer ought to handle. As to the complexity, this is due to the data itself: modern applications push around all kinds of data that aren't, by their nature, character strings. The Unix approach requires applications to convert the data to character streams and back (so the programmer needs to design a format complex enough to represent the data items and their relationships as character streams, write serialization code and parsers to convert it back). That's a lot of overhead.
But wouldn't that be more overhead (passing an object) because now the application accepting said list of files has to understand the structure of passed object in order to process it correctly, where in Linux you simply pass text/streams as specified by the accepting application. These applications can be written by anyone with no prior knowledge of the object structure of another application that may be sending it information.
On the contrary, the overhead ought to be smaller with PowerShell; first, cmdlets run in the PS process: once instantiated, passing references around should be enough, and objects don't need to be marshalled and translated as a step of piping from one cmdlet to another. Compared to the Unix model, there is no need to serialize the internal object to stdout, push it to a pipe (maybe requiring OS involvement, buffering, etc.), very little need for custom glue code that modifies the output to make it understandable to the second app, and no need to deserialize the result from stdin into the internal representation of the accepting application. And even if your apps didn't run in the same process, the CLI handles serialization and deserialization for you, so you don't need to write your own custom parser - fun as it may be :)
Your other concern, that the accepting cmdlet must understand the structure of the incoming object is not a problem either: the accepting cmdlet does not usually need to understand all of the structure of the objects received. Often the requirement is simply that the objects in question implement a certain interface. That gives one a lot of flexibility, because you can push very different objects through without having to write glue code, as long as the required interface exists. Note also that in the CLI, some properties or methods are predefined (for example the ToString() method), and that the receiving application can use reflection to investigate the methods and properties exposed by the input objects.
Anyone care to point out to me how PowerShell can be more "integrated" than bash?
The references to the CLI should give you an indication. The integration is between components running under PowerShell. PowerShell cmdlets use object pipelines to communicate: they send whole objects to each other, and can all access well known and defined properties of those objects. I haven't seen this kind of integration under Unix, where the standard model is to pipe character streams. This requires serialization, weird and often painful custom parsing with liberal use of text processing tools like awk, sed and so on. See here for more details.
Coraline, Up
Well, I saw Coraline in 3D, with the red/blue glasses; I won't repeat the experience. The 3D effect came and went, glasses got annoying after a time, I had to keep my head straight up or the two images got out of sync (so no stretching on the sofa), the colors were all washed up and changed weirdly (maybe my eyes aren't trained to correct for brightness with colored glasses?). But even if the quality were better, I don't think this kind of gimmick adds much to the movie. I'll wait for real 3D displays, maybe holography-based.
For all 479 recommended products...so simple, aye?
Of course not, duh! Only remove the CDs you bought as "gifts"; once they're gone, ALL the recommended products will change, it's like magic!
Except that no one I knows blasts Hotmail or Live messenger or those services
All right, but apart from the sanitation, the medicine, education, wine, public order, irrigation, roads, a fresh water system, and public health, what have the Romans ever done for us?"
Windows 7 Starter Edition won't let you run more than 3 windows at a time
You really have no idea what you're talking about, do you? Or else, given your posts here, you're intentionally spreading FUD. First, comparison with the Starter edition is at least misleading. In the USA the most usual versions are going to be Home Premium or higher. Unless Granny has a tiny netbook (which I wouldn't foist on any of my elderly relatives), you'd have to bend over backwards to get your grandmother a Starter Edition machine. Second, your assertion about the 3 application limit is just plain untrue. Go educate yourselfa bit before posting FUD.
You mean using Google services? Do you really think Google would bar people from using their services from other browsers/OSes?
You have it exactly backwards: of course Google won't stop people from using their services from anywhere. The services (and ads) is how they make money. They don't try to monetize the desktop software, but they'll use Chrome to drive people from using other companies' services to theirs. It probably won't be a straightforward refusal to connect to say Yahoo, but the Google OS will be (surprise, surprise) optimized to work with Google's data centers, it will use the internal knowledge Google programmers have about how the server side works, disadvantaging other competitors for the data center. New services and features on the data center will work first in Chrome, reinforcing the loop.
By the same token, it's in Google interest to make the Chrome OS code free and available. People studying it will learn how to better connect and work *with Google's ad servers*, not with Yahoo's or MSN's, or other Google competitors'. Thus, Google would extend their predominance in the data center/search business to the desktop.
I think most people will stick with Windows and proper GNU/Linux netbooks
Yeah, this sounds to me like just another try at the failed Internet appliance idea. Didn't work then, and I doubt it'll work now. With a netbook you should be able to run everything Chrome has (as long as you have a browser and a network connection), plus a huge variety of other stuff. For example, on planes I carry a netbook with a few movies and a lot of music; will I be able to use a Chrome device for that?
Maybe if the price were significantly better, I might consider one of those things, but again I don't see how. Netbooks are cheap enough as is, and I don't believe manufacturers will be able to save much on Chrome OS devices.
This. The Micro Framework is for resource-constrained embedded devices... which are just about the last place you'd want to run bytecode anyway, as far as I can see. We've got tons of embedded stuff where I work, but I fail to see how controllers for mechanical bits and pieces are going to benefit from having the CLR, object classes, GUIs, etc. made available to them.
I think they're targetting the same area as some embedded Java implementations, like MicroJava. You're getting a nice programming environment (you can use Visual Studio to write C# software for your embedded app), you're getting automatic memory management and it'll offer a migration path for people familiar with larger platforms. While it's not going to be as efficient as hand-tightened C and/or assembly code, it should allow faster development for embedded applications.
Yes, I know they're hoping to scoop the mobile market, but which part of it - the non-smartphone (dumbphone) market?
Not sure they're interested only (or even mainly) in the mobile market; the .NET MF can run on much lower performance processors than the ones used in phones, even feature phones (i.e., not smartphones). From what I've seen most phones use ARM 9 level CPUs, or even ARM + DSP combos, like the TI's OMAP (please feel free to correct me, phones aren't an area I have much interest in). That's overkill for the .NET MF which can happily run on ARM7 level CPUs.
.NET micro is mostly for embedded devices running WinCE.
Nope, you're wrong. You're thinking of the .Net Compact Framework. Basically there are three .NET implementations available from MS (ignoring Rotor for the time being). The Windows one (known as "the .Net Framework") is the largest, with lots of libraries and capabilities. The Compact Framework targets Win CE level devices (fewer resources, lower capabilities), and takes about 12 Mbytes. The .NET Micro Framework targets even smaller devices; it has a subset of the .NET classes, and can fit in 300 kBytes or less. The .NET Micro Framework doesn't need an OS to run (but it can run on an OS). That's the thing that was running in the (now defunct) SPOT watches and MSN Direct traffic dongles. Those were tiny devices which couldn't have run Win CE.
Secure passwords demand nonstandard characters.
Bring up the charmap or memorize your alt codes
That's actually a misconception. It is fairly widespread, but it's a misconception nevertheless. Secure passwords don't "demand" nonstandard characters at all, and I'm pretty annoyed sometimes at web sites that require one to go through all kinds of contortions to get an acceptable password (lower case and upper case, symbols, numbers and a partridge in a pear tree). They only show that the web designer doesn't understand security.
Let me explain:
A strong password is one that can not be easily guessed or cracked. That means some things like your dog's name, or your birthday should not be used. This information is available in all kinds of places, and an attacker can get it and try it. Dictionary attacks against passwords use huge lists of words (dictionaries), trying all of them until the attack succeeds. That means it's not a good idea to use a real word ("Swordfish"). Modern dictionary attack software also tries varieties of "leet" spelling ("Sw0rdf!sh"), so that's not a good password either (even though it does use upper/lower case, numbers and symbols).
The important thing to understand though, is that any such attack is basically a search through the total password space (the password space being the total number of combinations possible with the given symbol set. For example, if your password length is 5, and you can use only lowercase letters, the password space is composed of the combinations from 'aaaaa' through 'zzzzz'). In order to defend against an attack you need to make the search as difficult as possible. That means two thigs: first, the password space must be large (otherwise the attacker can simply do an exhaustive search through all possible combinations until he finds the right one). Second, the password's position in the password space must be as random as possible. The more a priori information your attacker has about your password, the easier his work is. For example, people aren't very good at generating random passwords, and that's why dictionary attacks work: the attacker only needs to search through the small subset of "real words" of this password space, using the fact that many people will use existing words (maybe with a few fairly predictable changes). If the password is truly random, the attacker will have to do a brute force search through your password space, which is usually impractical.
To return to the initial misconception: the requirement to use nonstandard characters is an attempt to increase the number of random bits in the password, given the user's tendency to pick short passwords. It is not the only one; another way is to make the password longer. It's fairly trivial to compute where a longer password composed only of say lower case characters becomes as strong as a given (shorter) password that uses a larger symbol set (see here for details). Note that forcing users to use nonstandard characters may make your password less secure, because it reduces your password space: an attacker doesn't need to try any non-conforming password, so his work is simplified.
Apache would like to have a word with you.
Sure, let's talk about Apache then: Apache 2.2.x, 17 advisories, 28 vulnerabilities, 2 unpatched. IIS 7.x, 2 advisories, 2 vulnerabilities, all patched. Are you going to apologize now? I didn't think so.
Do you get paid to shill?
Being a devil's advocate on an issue != being a troll on an issue, but pretending to be a devil's advocate just so you can FUD = Troll.
You don't know what you're talking about (as shown above), and you attack the person instead of the message. On top of that, you've been spamming your silly "shilling" accusation all over the place, no matter what other posters say. I think you're the troll here, and not a very bright one either.
The universe could simply induce a sufficient e/m force to stop the proton beams colliding. It wouldn't take much, on a cosmic scale, and would be a far more likely outcome than an entire macroscopic object being foobared just to protect the continuity of the universe
ObSF: Connie Willis, "To Say Nothing of the Dog", where the Universe arranges drowning cats, stolen Victorian ironmongery, jumble sales and croquet games to avoid paradox :). (very good book, BTW, especially if you like British humor and Jerome K. Jerome)
Not a new idea; I read a short story (blanking on the title, sorry) written by the Russian SF authors Arkady and Boris Strugatsky sometimes in the seventies. In the story, a physicist teetering on the brink of a major discovery that would change the Universe gets interrupted in his work by weirder and weirder occurences, including a gun-toting dwarf. After reflection he realizes it's a reaction from the Universe, which tends to conserve its state, under some kind of Le Chtelier's principle.
Same goes for engineers. Name a well-known (outside of engineering) engineer. I'll wait ...
Sure, here you are, off the top of my head:
- Leonardo da Vinci
- Alexander Graham Bell
- Henry Ford
- Ray Dolby
- Gustave Eiffel
- Neil Armstrong
- Isambard Brunel
- Rudolf Diesel
- Graf von Zeppelin
- Charles Babbage
- Alexander Graham Bell
- Lee DeForest
- Neil Armstrong
- Seymour Cray
- Ray Dolby
- John Fleming (the inventor of the first vacuum tube, not Alexander, the penicillin guy)
- Westinghouse
- Lord Kelvin
- Tesla
- Lee Iacocca
- Robert Fulton
- of course, Ferdinand Porsche
... and many, many others!
My understanding is that in England, most of the time if you are born in the "working class", your children will die as part of the "working class". If you look at U.S. statistics, you discover that most of the people in the bottom quarter of wealth in the population ten years ago, aren't in the bottom quarter today
Your understanding doesn't seem to match facts. This study indicates that the UK and the US have similar degrees of social mobility, and they're both at the bottom of the list, compared to Canada, Germany and other developed countries.
Might result, as in "someone finds some BSD-licensed code, makes some changes and releases a closed-source paid version". Mind you, this scenario is not inherently a bad thing, but it fits some of the many definitions of "restricting freedom", wether the restriction is actually an issue or not - in this case, someone who ends up being a user of the released binary is deprived of the right to see the source code and modify it
You're confused here: the user of the released binary is not deprived of any rights as far as the original code is concerned: he still has full access to the original BSD code, and can modify it to his heart's content. The user doesn't have access to the *new* code, developed by a second party, but this is a decision the second party coder has made. It's not correct to blame the original programmer or the original licence for what the second party does. As far as I can see, a BSD licence gives freedom both to the user (who can do whatever with the BSD code), and to the second party coder, who can do what he wants with *his* code.
Windows doesn't even come with a decent shell, so it's already decades behind unix-like systems on file management
Yes, it does. Look up Powershell. Very nice, powerful scripting language, beats most Unix shells in capabilities.