Japanese is actually even more complicated than Chinese in that regard. On the one hand it *does* have definite limited alphabets (e.g. hiragana) but also imports a huge amount from Chinese characters. So not only do they have multiple base alphabets, all of which have large distinct character counts, they also have a character library. In doing so I think they have the worst of both worlds - a lot to remember, hard to encode, and not even very compatible with other languages.
Chinese ideographs are so numerous and difficult to remember that they are considered one of the reasons for China's incredibly low literacy rate. The language reform didn't really help either. I guess it's a side effect of bringing in complex written language, once only used by the educated elite, to the average masses who don't have the time or resources to learn. It's not as much of a big deal with simpler languages. Russian language is a bit more complicated than English, but also more sensible and internally consistent, and Russia has one of the highest literacy rates of any nation. I don't know if that's because of better education or just a better language design, but the numbers are there looking us in the face.
The math for that is pretty reasonable. It's pretty easy to type that fast. However, most code time is spent thinking, testing, editing, refactoring, etc. and any code which doesn't have a good application of these habits is not worth writing. You're seriously better off doing things in smaller increments, especially with how human memory works. That's not always possible of course, but preferrable. I'd rather spend two days writing code than one day writing and the next three days fixing. It's especially discouraging to have unworking code for days at a time, and this is known to kill many otherwise promising projects, even open source ones.
Precisely, and applying that on a mass scale would weed out a lot of problems. It just won't really take place on a large enough scale to e.g. create world peace. What we *can* do is continue to improve education and culture to help the process along as much as possible. I hope it's clear to everyone that cultural influence does play a significant role in the 'character' of an individual and therefore their resistance to corruption. I consider it a valuable part of real education, so it's a shame many schools neutralise it in fear of offending other cultures. I guess that one will be up for debate forever.
I just mean that weak-minded people are likely to empower those would who cause harm. Those scientists were terrified of the harm that would come to them if they didn't cooperate. Some even believed the propaganda at the time. One person refusing to cooperate gets themselves killed, an entire country refusing to cooperate means a powerless leader. No amount of evil can push a population around if there's nobody willing to apply that evil. It's exceptionally unlikely that most nations would ever have such a level of social hygeine though.
Well, that depends what you call science. I consider anything science if it's already out there waiting to be discovered or defined, and anything artificial an art, technology, etc.
I also firmly believe that evil gains its power through the stupidity (or at the very least cowardice) of others. One person, no matter how evil, can't get very far in a world that looks after itself intelligently. Tyrants get into power by swaying weak minds. It's like a poison taking over a body with a poor immune system. A good social immune system - one complete with intelligence, knowledge and good character - can destroy evil readily. It's a whole other matter in some societies where the poison is the norm and not the exception. There's very little that can be done about that. At that stage, any good and pure thought is supressed.
Who says I don't? That's not part of my argument at all. In fact I hope it's clear I'm suggesting that a lot of things that the garden variety atheist would consider impossible aren't absolutely so, which means I entirely accept the possibility of a lot of Jesus' work being factual. There's not much point splitting hairs on exactly what's obvious, probable, improbable, etc.
My personal faith is in science, that we'll probably get a good lot of research done before the human race is extinguished entirely by the Nth Bush administration. We're dying less from diseases and more from stupidity. Real scientific success will be curing stupidity. Or maybe that's a real miracle. If there's a Second Coming, I hope it will be to address this growing concern.
If you're willing to believe that resurrection is something that non-Jesus people can do, then you have to take it as something that's *not* a great power. And you can't have it half way - if you're going to believe the accounts that Jesus raised the dead, all of the other resurrection miracles have to apply too.
You also can't take "ascending to the heavens" as a feat. If it's just about going straight up a few kilometers, we've been doing a good job of that lately with spaceflight. If it's about crossing from this mortal world into another, how can anyone actually attest that the person arrived in any other world? For all we know they could have been vaporised or otherwise concealed.
I was copying what was already said, but yes, that is a botched way to phrase it. I welcome your correction - thank you.
What I meant to say, and I hope this part is clear, is that the purpose of science largely involves discovering what isn't considered common knowledge yet. Sometimes that involves investigating what has previously been regarded preposterous. The earth isn't flat. That's just something we couldn't easily see from where we were before.
Maybe in a few centuries, miracle resurrection will be a hobby and not an act of God. It doesn't have to come from technology - we could just discover how to use some innate human power. We can't seriously say that's not at all possible.
As typical as it is to suggest the acts of JC are hugely exaggerated, by modern standards they're pretty tame. All over the world, especially in some of the older surviving civilizations like Russia, China, India, etc. there are people who can show you much more impressive feats at a moment's natice, and they don't claim to have inherited any powers of God. There's just a lot about science we haven't charted yet, but that doesn't mean the practice of unscientific feats is impossible. As has been said, absence of evidence isn't evidence of absence. While I'm not suggesting JC performed the feats attributed to him, I am suggesting it wouldn't be otherworldly if somebody did. It's unscientific to insist upon impossibility, despite what most people seem to instinctively believe about science.
I don't know how useful it is, but I haven't heard of anyone actually using it either.
Who actually cares? JIT+VM-in-kernel has been available for many years in the form of Inferno, and nobody cared then either.
Besides, we already have reasonably light-weight runtimes for Python, Ruby, etc. that perform on embedded devices, with infinitely more expressive power than Java. Even Sun appreciates this and is integrating expressive, dynamic languages into future JDK releases, but the typical JVM runtime is still way too heavy to be useful for embedded work and the stripped ones still take up too much space to fit a dynamic language platform on top, let alone execute it fast enough to be useful.
That doesn't seem reasonable. The undo/redo functionality tends to be per-change, not per-save. And VFS isn't the place for it, because VFS layers deal with locating files/directories/etc and not data itself. In a clean system it tends to be the block or filesystem logic that handles those things.
It is, however, rather simple to integrate granular and partly automated revision control into many programs, and this has many bonuses over forcing it into the kernel, especially the independence from kernel implementations. Even Microsoft Office does a pretty good job of tracking and autosaving your work while still allowing returns to the past, even if the tracking is not done quite as well as a full revision system ala CVS/SVN/... would.
Just for per-write file versioning, you could have a versioning *layered* file system with something like FUSE, which would be sufficiently portable across platforms and not require any VFS tampering. But making that behave properly with the usual assumptions programs have about file systems (i.e. writing is free and can be done per-keystroke if necessary) is a challenge on a whole new level. I would not in my right mind run an autosaving editor like VIM on such a system.
Tell that to BSD projects, who use GPL code extensively but retain the BSD license on most of their code. It's a pragmatic approach - they can keep most of the code truly free (BSD) and still make use of the virally free (GPL) projects that are virtually irreplacable. That's because 3-clause BSD is GPL-compatible. You can cut a binary distribution of a BSD with no GPL code, and hack it up for embedded development, as many companies do. You can debate until the heat-death of the universe about whether GPL or BSD is overall better, but the fact is that their coexistence is best of all. If it wasn't for BSD, many companies would just have to write new, less compatible, less tested code because there's no way in hell they're going to open up as per GPL. If it wasn't for GPL, Microsoft would have embrace-and-extended GNU/Linux into oblivion, though now they're stuck doing it through patents instead.
You can't seriously claim that "the vast majority" can take advantage. Look on any Unix package manager web interface (e.g. http://www.freshports.org/ and take a sample of about 20 programs randomly (heck, even just the most recent ones) and think of a genuinely good reason to make it more parallel. Keep in mind that many programs will be running in parallel anyway, without being multi-threaded in their own right, so you can't call that parallelising the programs.
Just becoming more parallel does not mean it's an advantage - it carries significant impacts to complexity and makes the correctness of a program very difficult to verify formally. I would say "the vast majority of real world applications can severely cripple themselves in the search for parallelism". That's at least consistent with reality.
I don't know how much experience you have developing real-world systems, but it can't be very much. Very, very many programs spend very, very little CPU time. You only start gaining throughput performance from multiple cores when you've already maxed out one, even if it's only because now you're switching contexts less. If you have a heavily loaded database engine, you have a decent chance of needing more cores.
This is all really easy to measure in Unix - just use the 'time' command built in to most shells, and also available as a standalone binary for backend use. You can also issue the 'getrusage' standard library function and receive resource usage of your process, and its child processes.
Many cores are also useful if you need each task to finish quickly but also in parallel, so even though you won't max out available CPU time, you will get things done 'earlier'. Sun has taken this idea and applied it for the Niagara processor, which has an unholy number of cores which are all pretty slow. It's a niche, but it does well for that niche.
But really, I've written a fair few systems, and even the "scientific data processing" ones still never needed even a full 1-core CPU that you could buy for $100. If you write in.NET or something heavyweight like that, yeah, now you need a lot more CPU just to do what C/gcc can do. I don't care what people will say about JIT optimization and fast garbage collectors, it's nowhere near C for many very real-world applications. That's why my path is generally Python/Ruby/whatever + C extension for the mechanical bits that take over 95% of the CPU time. With this, I've yet to require threading.
The one time I over-engineered a system with elegant but over-used message passing, it ended up being overall slower than just single threading it, but it's Java so that's partly to blame. I ended up making it optional to run the system synchronously, and recommended people do that until they really needed a lot more throughput. Optional threading is pretty easy to implement if you're using an elegant message passing implementation. DragonFly BSD is doing something like this on the kernel level, and also extending that messaging to be able to run across machines on a network or the Internet. It's inspiring to say the least.
They're significantly reducing the lockin to Microsoft products, by encouraging, buying and thereafter funding web application projects that often overlap with what is currently locked in to Microsoft. They even brew some of their own sometimes. They continue the development of Linux and Python with a wide adoption of both. All of these things are creating wealth for everyone, and crippling Microsoft little by little, which we know is what we want. I'd much rather have a Google & Microsoft duopoly if it means Microsoft would finally have to clean up its shit and accomodate whatever open source platform Google would support in that scenario.
How isn't it Microsoft's fault? They've created and continue to fuel a world of poor proprietary software, setting the foundations by not fixing DOS before its release (and consequent requirements for bug-for-bug compatibility, like C:\foo\bar file paths), and continuing to abuse and ignore standards to ensure maximum vendor lockin. Really bad software just doesn't survive in the open source world - either it's changed until it's good, or it's dropped altogether. Moderately bad software like the Mozilla family tree and MySQL become extremely popular and eventually creep towards being acceptable. Proprietary rubbish survives because of vendor lockin, and that's the kind of world Microsoft wants, because it's in the business of selling new lockin.
'Boo', a language with roughly Python-like syntax for the.NET runtime. It also has bonus type inference and a generally nice feel to it, even though it's not quite complete. I'd still rather code in real Python myself, since the base library is a Unix programmer's dream, and pure duck typing feels a lot more expressive. Anything that needs to go much faster is either in a C library already, or I can make my own.
Time to read malloc source. And by that I mean a good one like FreeBSD's. Not all unmanaged memory allocation is brutally slow, and if you have special needs, writing a queued slab allocator is trivial even in C, even a thread-safe one using pthread primitives. And Boost C++ offers a general memory slab kit for C++. Yes, writing a thread safe queued homogeneous slab allocator is still more work than the 'pants = WorkPants()' you get with Python, but if malloc actually is your bottleneck then you need a better allocator anyway, maybe just a better malloc. If malloc isn't a significant part of your CPU time, then it's intensely stupid to trumpet some VMs having better allocation than a specifically bad malloc like Microsoft's.
C# (and, since they're almost exactly the same, Java too) may as well just be for faster bytecode, and the main logic should be written in a more expressive language like Python. The same argument that suggests Java and C# are better than C++ applies the same for Python, Ruby, etc being better than those languages. They're much slower, but much more expressive languages, and should be used where practical.
If all their software is sold at 90% discount, it's no longer discounted, that's the new standard price. It's a marketing ploy to claim any different. So what they can do is increase the price tenfold, but continue charging the same, claiming they're giving everybody a 90% discount. Which is ridiculously stupid, and therefore is exactly what they'll do once somebody reads this post. Microsoft is much better at writing suicide notes than software or licenses.
Good - we need more pressure on Linux to tighten its security. Even the public exploits are too many, and many lesser distributions have a poor response time to patching. BSDs and even the proprietary Solaris are more secure in general, and if Linux catches up in this space (difficult with its development model, but entirely possible) it will be better for absolutely everybody, even people whose only contact with Linux is servers, even Microsoft who necessarily rely on a lot of Linux machines in the world to host software that unfucks Windows a little. So a higher adoption for Linux implies a higher pressure for security engineering and quality control, which is better for everyone. Monoculture should still be avoided, but most of the damage of monoculture can be negated by individual randomization like what OpenBSD has been doing by default for some time.
Let's agree to never listen to people who voluntarily use (let alone develop) PHP software talk about "vulnerabilities". They're right alongside "health experts" who abuse hard drugs.
Slashdot Mirror
Japanese is actually even more complicated than Chinese in that regard. On the one hand it *does* have definite limited alphabets (e.g. hiragana) but also imports a huge amount from Chinese characters. So not only do they have multiple base alphabets, all of which have large distinct character counts, they also have a character library. In doing so I think they have the worst of both worlds - a lot to remember, hard to encode, and not even very compatible with other languages.
Chinese ideographs are so numerous and difficult to remember that they are considered one of the reasons for China's incredibly low literacy rate. The language reform didn't really help either. I guess it's a side effect of bringing in complex written language, once only used by the educated elite, to the average masses who don't have the time or resources to learn. It's not as much of a big deal with simpler languages. Russian language is a bit more complicated than English, but also more sensible and internally consistent, and Russia has one of the highest literacy rates of any nation. I don't know if that's because of better education or just a better language design, but the numbers are there looking us in the face.
The math for that is pretty reasonable. It's pretty easy to type that fast. However, most code time is spent thinking, testing, editing, refactoring, etc. and any code which doesn't have a good application of these habits is not worth writing. You're seriously better off doing things in smaller increments, especially with how human memory works. That's not always possible of course, but preferrable. I'd rather spend two days writing code than one day writing and the next three days fixing. It's especially discouraging to have unworking code for days at a time, and this is known to kill many otherwise promising projects, even open source ones.
Precisely, and applying that on a mass scale would weed out a lot of problems. It just won't really take place on a large enough scale to e.g. create world peace. What we *can* do is continue to improve education and culture to help the process along as much as possible. I hope it's clear to everyone that cultural influence does play a significant role in the 'character' of an individual and therefore their resistance to corruption. I consider it a valuable part of real education, so it's a shame many schools neutralise it in fear of offending other cultures. I guess that one will be up for debate forever.
LFreeBSDX. LSolarisX. Ah, crap, I couldn't do it :)
I just mean that weak-minded people are likely to empower those would who cause harm. Those scientists were terrified of the harm that would come to them if they didn't cooperate. Some even believed the propaganda at the time. One person refusing to cooperate gets themselves killed, an entire country refusing to cooperate means a powerless leader. No amount of evil can push a population around if there's nobody willing to apply that evil. It's exceptionally unlikely that most nations would ever have such a level of social hygeine though.
Well, that depends what you call science. I consider anything science if it's already out there waiting to be discovered or defined, and anything artificial an art, technology, etc.
I also firmly believe that evil gains its power through the stupidity (or at the very least cowardice) of others. One person, no matter how evil, can't get very far in a world that looks after itself intelligently. Tyrants get into power by swaying weak minds. It's like a poison taking over a body with a poor immune system. A good social immune system - one complete with intelligence, knowledge and good character - can destroy evil readily. It's a whole other matter in some societies where the poison is the norm and not the exception. There's very little that can be done about that. At that stage, any good and pure thought is supressed.
Who says I don't? That's not part of my argument at all. In fact I hope it's clear I'm suggesting that a lot of things that the garden variety atheist would consider impossible aren't absolutely so, which means I entirely accept the possibility of a lot of Jesus' work being factual. There's not much point splitting hairs on exactly what's obvious, probable, improbable, etc.
My personal faith is in science, that we'll probably get a good lot of research done before the human race is extinguished entirely by the Nth Bush administration. We're dying less from diseases and more from stupidity. Real scientific success will be curing stupidity. Or maybe that's a real miracle. If there's a Second Coming, I hope it will be to address this growing concern.
http://en.wikipedia.org/wiki/Resurrection#Resurrec tion_miracles
If you're willing to believe that resurrection is something that non-Jesus people can do, then you have to take it as something that's *not* a great power. And you can't have it half way - if you're going to believe the accounts that Jesus raised the dead, all of the other resurrection miracles have to apply too.
You also can't take "ascending to the heavens" as a feat. If it's just about going straight up a few kilometers, we've been doing a good job of that lately with spaceflight. If it's about crossing from this mortal world into another, how can anyone actually attest that the person arrived in any other world? For all we know they could have been vaporised or otherwise concealed.
I was copying what was already said, but yes, that is a botched way to phrase it. I welcome your correction - thank you.
What I meant to say, and I hope this part is clear, is that the purpose of science largely involves discovering what isn't considered common knowledge yet. Sometimes that involves investigating what has previously been regarded preposterous. The earth isn't flat. That's just something we couldn't easily see from where we were before.
Maybe in a few centuries, miracle resurrection will be a hobby and not an act of God. It doesn't have to come from technology - we could just discover how to use some innate human power. We can't seriously say that's not at all possible.
As typical as it is to suggest the acts of JC are hugely exaggerated, by modern standards they're pretty tame. All over the world, especially in some of the older surviving civilizations like Russia, China, India, etc. there are people who can show you much more impressive feats at a moment's natice, and they don't claim to have inherited any powers of God. There's just a lot about science we haven't charted yet, but that doesn't mean the practice of unscientific feats is impossible. As has been said, absence of evidence isn't evidence of absence. While I'm not suggesting JC performed the feats attributed to him, I am suggesting it wouldn't be otherworldly if somebody did. It's unscientific to insist upon impossibility, despite what most people seem to instinctively believe about science.
https://jinux.dev.java.net/
I don't know how useful it is, but I haven't heard of anyone actually using it either.
Who actually cares? JIT+VM-in-kernel has been available for many years in the form of Inferno, and nobody cared then either.
Besides, we already have reasonably light-weight runtimes for Python, Ruby, etc. that perform on embedded devices, with infinitely more expressive power than Java. Even Sun appreciates this and is integrating expressive, dynamic languages into future JDK releases, but the typical JVM runtime is still way too heavy to be useful for embedded work and the stripped ones still take up too much space to fit a dynamic language platform on top, let alone execute it fast enough to be useful.
That doesn't seem reasonable. The undo/redo functionality tends to be per-change, not per-save. And VFS isn't the place for it, because VFS layers deal with locating files/directories/etc and not data itself. In a clean system it tends to be the block or filesystem logic that handles those things. It is, however, rather simple to integrate granular and partly automated revision control into many programs, and this has many bonuses over forcing it into the kernel, especially the independence from kernel implementations. Even Microsoft Office does a pretty good job of tracking and autosaving your work while still allowing returns to the past, even if the tracking is not done quite as well as a full revision system ala CVS/SVN/... would. Just for per-write file versioning, you could have a versioning *layered* file system with something like FUSE, which would be sufficiently portable across platforms and not require any VFS tampering. But making that behave properly with the usual assumptions programs have about file systems (i.e. writing is free and can be done per-keystroke if necessary) is a challenge on a whole new level. I would not in my right mind run an autosaving editor like VIM on such a system.
That sounds familiar. http://spetskod.blogspot.com/2007/04/learn-to-love -net.html
Tell that to BSD projects, who use GPL code extensively but retain the BSD license on most of their code. It's a pragmatic approach - they can keep most of the code truly free (BSD) and still make use of the virally free (GPL) projects that are virtually irreplacable. That's because 3-clause BSD is GPL-compatible. You can cut a binary distribution of a BSD with no GPL code, and hack it up for embedded development, as many companies do. You can debate until the heat-death of the universe about whether GPL or BSD is overall better, but the fact is that their coexistence is best of all. If it wasn't for BSD, many companies would just have to write new, less compatible, less tested code because there's no way in hell they're going to open up as per GPL. If it wasn't for GPL, Microsoft would have embrace-and-extended GNU/Linux into oblivion, though now they're stuck doing it through patents instead.
You can't seriously claim that "the vast majority" can take advantage. Look on any Unix package manager web interface (e.g. http://www.freshports.org/ and take a sample of about 20 programs randomly (heck, even just the most recent ones) and think of a genuinely good reason to make it more parallel. Keep in mind that many programs will be running in parallel anyway, without being multi-threaded in their own right, so you can't call that parallelising the programs.
Just becoming more parallel does not mean it's an advantage - it carries significant impacts to complexity and makes the correctness of a program very difficult to verify formally. I would say "the vast majority of real world applications can severely cripple themselves in the search for parallelism". That's at least consistent with reality.
I don't know how much experience you have developing real-world systems, but it can't be very much. Very, very many programs spend very, very little CPU time. You only start gaining throughput performance from multiple cores when you've already maxed out one, even if it's only because now you're switching contexts less. If you have a heavily loaded database engine, you have a decent chance of needing more cores.
.NET or something heavyweight like that, yeah, now you need a lot more CPU just to do what C/gcc can do. I don't care what people will say about JIT optimization and fast garbage collectors, it's nowhere near C for many very real-world applications. That's why my path is generally Python/Ruby/whatever + C extension for the mechanical bits that take over 95% of the CPU time. With this, I've yet to require threading.
This is all really easy to measure in Unix - just use the 'time' command built in to most shells, and also available as a standalone binary for backend use. You can also issue the 'getrusage' standard library function and receive resource usage of your process, and its child processes.
Many cores are also useful if you need each task to finish quickly but also in parallel, so even though you won't max out available CPU time, you will get things done 'earlier'. Sun has taken this idea and applied it for the Niagara processor, which has an unholy number of cores which are all pretty slow. It's a niche, but it does well for that niche.
But really, I've written a fair few systems, and even the "scientific data processing" ones still never needed even a full 1-core CPU that you could buy for $100. If you write in
The one time I over-engineered a system with elegant but over-used message passing, it ended up being overall slower than just single threading it, but it's Java so that's partly to blame. I ended up making it optional to run the system synchronously, and recommended people do that until they really needed a lot more throughput. Optional threading is pretty easy to implement if you're using an elegant message passing implementation. DragonFly BSD is doing something like this on the kernel level, and also extending that messaging to be able to run across machines on a network or the Internet. It's inspiring to say the least.
They're significantly reducing the lockin to Microsoft products, by encouraging, buying and thereafter funding web application projects that often overlap with what is currently locked in to Microsoft. They even brew some of their own sometimes. They continue the development of Linux and Python with a wide adoption of both. All of these things are creating wealth for everyone, and crippling Microsoft little by little, which we know is what we want. I'd much rather have a Google & Microsoft duopoly if it means Microsoft would finally have to clean up its shit and accomodate whatever open source platform Google would support in that scenario.
How isn't it Microsoft's fault? They've created and continue to fuel a world of poor proprietary software, setting the foundations by not fixing DOS before its release (and consequent requirements for bug-for-bug compatibility, like C:\foo\bar file paths), and continuing to abuse and ignore standards to ensure maximum vendor lockin. Really bad software just doesn't survive in the open source world - either it's changed until it's good, or it's dropped altogether. Moderately bad software like the Mozilla family tree and MySQL become extremely popular and eventually creep towards being acceptable. Proprietary rubbish survives because of vendor lockin, and that's the kind of world Microsoft wants, because it's in the business of selling new lockin.
Wow, way to completely not support UTF-8, Slashshit.
Transliterated almost phonetically:
"Hochu krasivuyu Siberskuyu devushku". Which you can reduce to "Hochu krasivuyu Siberyaku", and it even specifies the gender. Russian is like that.
" ". Which you can reduce to " ", and it even specifies the gender. Russian is like that.
'Boo', a language with roughly Python-like syntax for the .NET runtime. It also has bonus type inference and a generally nice feel to it, even though it's not quite complete. I'd still rather code in real Python myself, since the base library is a Unix programmer's dream, and pure duck typing feels a lot more expressive. Anything that needs to go much faster is either in a C library already, or I can make my own.
Time to read malloc source. And by that I mean a good one like FreeBSD's. Not all unmanaged memory allocation is brutally slow, and if you have special needs, writing a queued slab allocator is trivial even in C, even a thread-safe one using pthread primitives. And Boost C++ offers a general memory slab kit for C++. Yes, writing a thread safe queued homogeneous slab allocator is still more work than the 'pants = WorkPants()' you get with Python, but if malloc actually is your bottleneck then you need a better allocator anyway, maybe just a better malloc. If malloc isn't a significant part of your CPU time, then it's intensely stupid to trumpet some VMs having better allocation than a specifically bad malloc like Microsoft's.
C# (and, since they're almost exactly the same, Java too) may as well just be for faster bytecode, and the main logic should be written in a more expressive language like Python. The same argument that suggests Java and C# are better than C++ applies the same for Python, Ruby, etc being better than those languages. They're much slower, but much more expressive languages, and should be used where practical.
If all their software is sold at 90% discount, it's no longer discounted, that's the new standard price. It's a marketing ploy to claim any different. So what they can do is increase the price tenfold, but continue charging the same, claiming they're giving everybody a 90% discount. Which is ridiculously stupid, and therefore is exactly what they'll do once somebody reads this post. Microsoft is much better at writing suicide notes than software or licenses.
Good - we need more pressure on Linux to tighten its security. Even the public exploits are too many, and many lesser distributions have a poor response time to patching. BSDs and even the proprietary Solaris are more secure in general, and if Linux catches up in this space (difficult with its development model, but entirely possible) it will be better for absolutely everybody, even people whose only contact with Linux is servers, even Microsoft who necessarily rely on a lot of Linux machines in the world to host software that unfucks Windows a little. So a higher adoption for Linux implies a higher pressure for security engineering and quality control, which is better for everyone. Monoculture should still be avoided, but most of the damage of monoculture can be negated by individual randomization like what OpenBSD has been doing by default for some time.
Let's agree to never listen to people who voluntarily use (let alone develop) PHP software talk about "vulnerabilities". They're right alongside "health experts" who abuse hard drugs.