If you're [sic] code is so labyrinthine that you can't keep track of your buffer sizes, you've got worse problems than memcpy().
That's exactly why this originated in Microsoft and not in GNU, BSD or Linux. People who can distinguish their ass from a pointer are fine with memcpy.
Which is fine if you don't use it. Disabling it just breaks existing code, not using it in the first place breaks nothing. Using the right code gets the right result. The same applies for almost all standard C functions for which the average (i.e. bad) programmer doesn't read the manpage.
Who do you think has to write those high level wrappers? memcpy is one of the most ridiculously popular functions in systems level C/C++ code, especially for copying arrays or sub-arrays, where it can be much faster than a hand-written loop. You can wrap it in a function for every type you need, but that's still a lot of memcpy you have to write properly. Fortunately it's easy and this whole argument is moot.
That's why anyone submitting their ideas should record them, maybe even prototype them in a similar open source system. If Microsoft even attempts to patent them, submitting the above as evidence will get their patent rejected or severely narrowed in claims. Sleep with a dog, get fleas.
You're much more likely to get the union of all three sets of bugs. I know I would much rather have all machines set up with few bugs, than with a great diversity of bugs that I could never hope to keep up with.
So it will not have a chance to pick up the virus which you ran during the day, and has already removed itself. Good job. Enjoy your false sense of security.
There's a much more important reason to use threads instead of processes + IPC, and that's that inter-thread communication is a sub-microsecond matter. Even the context switch between multiple threads (in the same process) is so cheap you can have way too many threads and still not see the overhead if you're also doing real work. In Linux much of inter-thread communication happens entirely in userland, so you don't even suffer the cost of a system call. You can go even further and use atomic operations to make data structures and algorithms that never need system calls to begin with, and that's about as fast as you can get with threading.
Why risk having security vulnerabilities on a tried and tested mission-critical system? They should have gone with Linux or BSD from the start and had virtually guaranteed upgrade compatibility from that point on, with plenty of commercial support options.
We can always keep adding more bandwidth - in the extreme case (as in TFS) by trunking together more of the same links. But latency is not really improving. Ethernet itself is very high-latency compared to e.g. Infiniband. But fundamental limits of latency are impossible to overcome, and the best you can do is get closer and closer, perhaps asymptotically so. Between our planet and another, any latency in hardware is going to be a rounding error compared to the latency in the electromagnetic waves themselves, which propagate at "only" the speed of light.
A much more reasonable limitation is no limitation. How is ANY netbook version of Windows for $25 reasonable when Linux can be had for free, with no restrictions on use or redistribution, and do just the same netbooky things Windows does, if not more?
You don't normally submit to search engines, they'll find your page via links at their own pace. There is a lot of sophistication in optimising this process already, but indeed it does not guarantee that the first page found is the first place its content was published.
The reason I like Oblivion is that problems like that are trivially patched away by installing an ESP into your Data directory. The simplest solution I've seen to the Oblivion problem is plus5always.esp, which just means you always get to pick +5 for each attribute if any skill was raised during that level. You still only get to raise 3 attributes, but at least you don't have to micro-manage the skills to do so. Do the math and you'll see you can max out your main attributes in about 10 levels (from ~50 starting to 100 max), and then the rest is for secondary attributes that still help game mechanics, and once those are maxed too, the rest goes into Luck at +1 per level.
Half the point of digital distribution is that prices can be set globally, and for the most part, companies can choose their per-unit profit and let the whole world deal with it. If that price ends up higher than a competitor, the competitor has a chance to get higher sales volume. That free market competition is in the spirit of capitalism.
You can't please everyone. Programmers in particular can be *really* picky about how their development environment and tools are set up. Anyone experienced enough with Eclipse to care about which version they use is virtually guaranteed to prefer a custom install anyway. Anyone inexperienced enough won't notice what version they're using.
Second to that, Eclipse 3.2 was the last version to support a visual editor for GUIs, so I can imagine the package maintainers wanting to stay with that until 3.4 has a working alternative. However that's not an excuse for not providing an alternative package for the 99% of people who don't care about a visual editor.
Nobody I know uses the Ubuntu Eclipse package anyway. Just unpack Eclipse from eclipse.org somewhere and make a launcher for it. I also prefer to use the real JDK rather than OpenJDK, at least as long as OpenJDK has Swing bugs.
Way ahead of you. I've been using old laptops as servers for years. They're small, quiet, have their own efficient UPS, and are very easy to stow in a corner and add to an established wireless network with OpenVPN. Most old ones will run on under 10W mains, which is less than many devices draw while turned "off".
I like Java and.NET. They have some very good technology even if a lot of their design decisions are stupid. That same technology is now giving us very good runtimes for superior languages like Python and Ruby. So I'd rather we evolve Java than kill it.
Fleeing the country at that age and with those limited resources is worse than suicide. The countries where it's reasonably safe to flee to, even with money, are extradition countries, so she'll be right back in the US in time for summer. And a lot of those non-extradition countries are inhospitable to a poor teenager, so she'll just die or end up a meth-addicted prostitute.
This glowing orb of positivity brought to you by perspective.
Sun didn't have to close the source to kill MySQL. Just forcing upon it a poor structure and community for continued development was enough to send away the lead developers. Nobody can say yet if any of the few forks will succeed.
If Sun can ruin MySQL, I'm sure Microsoft can ruin everything Sun has done as well. Imagine when Java is just an optional compatibility layer on top of.NET, never again to run on Linux or Solaris except via the (then deprecated) OpenJDK.
The slower models were bleeding edge back then too. Apart from the firmware updates nobody applies anyway and make little difference, old drives won't magically become more reliable. If anything I'd prefer newer drives as they likely have higher quality bearings.
KVM is in Linux mainline, so it'll be supported for as long as computers still exist. It's not even tied to a specific CPU architecture. Even if KVM somehow failed, QEMU is more than fast enough to virtualise the machine in question. Original poster can get a cheap desktop and a free Linux install and just migrate the virtual machine if and when the desktop fails.
Slashdot Mirror
If you're [sic] code is so labyrinthine that you can't keep track of your buffer sizes, you've got worse problems than memcpy().
That's exactly why this originated in Microsoft and not in GNU, BSD or Linux. People who can distinguish their ass from a pointer are fine with memcpy.
Which is fine if you don't use it. Disabling it just breaks existing code, not using it in the first place breaks nothing. Using the right code gets the right result. The same applies for almost all standard C functions for which the average (i.e. bad) programmer doesn't read the manpage.
Who do you think has to write those high level wrappers? memcpy is one of the most ridiculously popular functions in systems level C/C++ code, especially for copying arrays or sub-arrays, where it can be much faster than a hand-written loop. You can wrap it in a function for every type you need, but that's still a lot of memcpy you have to write properly. Fortunately it's easy and this whole argument is moot.
That's why anyone submitting their ideas should record them, maybe even prototype them in a similar open source system. If Microsoft even attempts to patent them, submitting the above as evidence will get their patent rejected or severely narrowed in claims. Sleep with a dog, get fleas.
You're much more likely to get the union of all three sets of bugs. I know I would much rather have all machines set up with few bugs, than with a great diversity of bugs that I could never hope to keep up with.
So it will not have a chance to pick up the virus which you ran during the day, and has already removed itself. Good job. Enjoy your false sense of security.
There's a much more important reason to use threads instead of processes + IPC, and that's that inter-thread communication is a sub-microsecond matter. Even the context switch between multiple threads (in the same process) is so cheap you can have way too many threads and still not see the overhead if you're also doing real work. In Linux much of inter-thread communication happens entirely in userland, so you don't even suffer the cost of a system call. You can go even further and use atomic operations to make data structures and algorithms that never need system calls to begin with, and that's about as fast as you can get with threading.
If the support contract doesn't include tested and managed security updates, it's not really support is it?
Why risk having security vulnerabilities on a tried and tested mission-critical system? They should have gone with Linux or BSD from the start and had virtually guaranteed upgrade compatibility from that point on, with plenty of commercial support options.
If you're on Linux anyway, why would you use proprietary TrueCrypt instead of Linux' built-in dm-crypt? Most installers even do it for you now.
We can always keep adding more bandwidth - in the extreme case (as in TFS) by trunking together more of the same links. But latency is not really improving. Ethernet itself is very high-latency compared to e.g. Infiniband. But fundamental limits of latency are impossible to overcome, and the best you can do is get closer and closer, perhaps asymptotically so. Between our planet and another, any latency in hardware is going to be a rounding error compared to the latency in the electromagnetic waves themselves, which propagate at "only" the speed of light.
A much more reasonable limitation is no limitation. How is ANY netbook version of Windows for $25 reasonable when Linux can be had for free, with no restrictions on use or redistribution, and do just the same netbooky things Windows does, if not more?
You don't normally submit to search engines, they'll find your page via links at their own pace. There is a lot of sophistication in optimising this process already, but indeed it does not guarantee that the first page found is the first place its content was published.
The reason I like Oblivion is that problems like that are trivially patched away by installing an ESP into your Data directory. The simplest solution I've seen to the Oblivion problem is plus5always.esp, which just means you always get to pick +5 for each attribute if any skill was raised during that level. You still only get to raise 3 attributes, but at least you don't have to micro-manage the skills to do so. Do the math and you'll see you can max out your main attributes in about 10 levels (from ~50 starting to 100 max), and then the rest is for secondary attributes that still help game mechanics, and once those are maxed too, the rest goes into Luck at +1 per level.
No more love for Elder Scrolls? I guess FPS will always win over RPG in raw popularity with Western audiences.
If the extra price is for safety and efficiency, it's probably well worth it. It could quickly pay for itself in savings and avoided liabilities.
Half the point of digital distribution is that prices can be set globally, and for the most part, companies can choose their per-unit profit and let the whole world deal with it. If that price ends up higher than a competitor, the competitor has a chance to get higher sales volume. That free market competition is in the spirit of capitalism.
You can't please everyone. Programmers in particular can be *really* picky about how their development environment and tools are set up. Anyone experienced enough with Eclipse to care about which version they use is virtually guaranteed to prefer a custom install anyway. Anyone inexperienced enough won't notice what version they're using.
Second to that, Eclipse 3.2 was the last version to support a visual editor for GUIs, so I can imagine the package maintainers wanting to stay with that until 3.4 has a working alternative. However that's not an excuse for not providing an alternative package for the 99% of people who don't care about a visual editor.
Nobody I know uses the Ubuntu Eclipse package anyway. Just unpack Eclipse from eclipse.org somewhere and make a launcher for it. I also prefer to use the real JDK rather than OpenJDK, at least as long as OpenJDK has Swing bugs.
Way ahead of you. I've been using old laptops as servers for years. They're small, quiet, have their own efficient UPS, and are very easy to stow in a corner and add to an established wireless network with OpenVPN. Most old ones will run on under 10W mains, which is less than many devices draw while turned "off".
I like Java and .NET. They have some very good technology even if a lot of their design decisions are stupid. That same technology is now giving us very good runtimes for superior languages like Python and Ruby. So I'd rather we evolve Java than kill it.
Fleeing the country at that age and with those limited resources is worse than suicide. The countries where it's reasonably safe to flee to, even with money, are extradition countries, so she'll be right back in the US in time for summer. And a lot of those non-extradition countries are inhospitable to a poor teenager, so she'll just die or end up a meth-addicted prostitute.
This glowing orb of positivity brought to you by perspective.
Sun didn't have to close the source to kill MySQL. Just forcing upon it a poor structure and community for continued development was enough to send away the lead developers. Nobody can say yet if any of the few forks will succeed.
If Sun can ruin MySQL, I'm sure Microsoft can ruin everything Sun has done as well. Imagine when Java is just an optional compatibility layer on top of .NET, never again to run on Linux or Solaris except via the (then deprecated) OpenJDK.
The slower models were bleeding edge back then too. Apart from the firmware updates nobody applies anyway and make little difference, old drives won't magically become more reliable. If anything I'd prefer newer drives as they likely have higher quality bearings.
KVM is in Linux mainline, so it'll be supported for as long as computers still exist. It's not even tied to a specific CPU architecture. Even if KVM somehow failed, QEMU is more than fast enough to virtualise the machine in question. Original poster can get a cheap desktop and a free Linux install and just migrate the virtual machine if and when the desktop fails.