Any competent and well-informed programmer knows that the openness of C#/.NET is a total sham. Sure the core is open, but there's so many Windows-only extensions that it's virtually impossible to make cross-platform apps. Plus the fact that the Mono implementation is always waay behind Microsoft's.
But MS has been very clever. They know that it's only technical people who can see this; the rest will just get the subliminal message that ".NET is now also cross-platform, just as Java".
This is the real damage of Mono. Its existence provides the right excuse for PHB and clueless tech decision-makers to sway the decision towards.NET instead
of Java, because, "hey, Microsoft is also cross-platform now".
Just look at thre STREAM benchmark numbers and you'll see clearly that AMD has been way ahead of Intel
when it comes to RAM bandwidth. I just benchmarked a dual-Quad-Xeon myself (Dell 2900) and I could not believe
the poor results I got. One app running in the system can get up to around 3,500 MB/s. Put just two tasks
running together (taskset'ed to different chips), and they will each get around 2,600 MB/s. From there on, total aggregate bandwidth
tops at 5,200 MB/s and stays there, no matter how many simultaneous tasks you run (it will of course degrade if you run more than
eight tasks, you get the point).
Dual-socket Opteron machines from two years ago can get to 15,000 MB/s aggregate, easily.
So, I'd really like to know if Intel is planning to improve things in this department.
AMD is still way ahead of Intel when it comes to jobs which combine these two things:
floating point (general purpose, not just video-encoding primitives)
use of lots of RAM in "non-cache-friendly" ways
This is specially noticeable if you have a multi-core, multi-chip machine and start firing up several compute intensive jobs at the same time. If you don't believe me, try running several instances
of the STREAM benchmak and see for yourself. Or go to www.spec.org and look at the SPEC CFP2006 Rates numbers (see this for instance, and compare).
Barcelona is supposed to increase scalability even a bit more from the current Opterons. Let's see if Intel comes up with something in this department. So far they
have not, and that's why most scientific computing in the last 5 years is done on Opterons.
Someone had to mention his other famous interview.
The way I see C++ these days: it might be your only choice if you are building a mass-market "horizontal" app (like, say, mozilla), and even then I would consider alternatives such as Objective C or plain ANSI C. But for "enterprise" apps, it is absolutely dreadful! Like someone said, it is the language with the most error-inducing features.
I'm surprised nobody mentioned Sun Studio 12, which
just came out recently. This time, the Linux release comes (for the first time) with its own compilers,
instead of relying on gcc. It'll be interesting to see how they compare to Intel's, specially on AMD chips...
It's very useful to have some normalized way of measuring watts/performance, as they try to do in this article.
But at least they could have used a more general and useful benchmark, like those offered by www.spec.org.
I wish the mod system could go over 5 because the parent post is +20 Insightful++.
Sometimes I think that if people in other engineering disciplines could understand what's been going on
in the computing business, then they would desperately cry and ask for prosecution. At least the people who
designed and the industries who pushed these broken languages/libraries should be
indicted for careless negligence (or whatever the legal term for this is).
For all this talk about (digital information) compression, not many people seem to realize that dynamic range compression is typically waaay worse these days.
Yes, it's a whole different kind of compression we're talking about here.
And it affects the mastering almost all newer CDs, which is what we all use as the source for rips and (digital) compression. Regarding this matter, I found the writings of Bob Katz to be quite clear and enlightening.
ExtremeTech has a plethora of application and synthetic benchmarks on QuadFX, including gaming and media-encoding tests."
Bleh. The benchmarks I'd really like to see are the ones geared towards scientific computing, like STREAMS and SPEC. Nowadays the Intel chips seem to score better on those "gaming" and "media-encoding" benchmarks,
but that doesn't neccessarily mean that Intel FPUs are better for general scientic computing. (in fact, experience so far shows the opposite)
Until these things are able to do double-precision, their applicability to general HPC problems remains very limited.
Make them do DP arithmetic, and benchmark with SPEC and McAlpine's STREAMS benchmarks, and then we'll see. Oh and BTW, make a Fortran-90/95 compiler available.
Mod parent +20 insightful (since almost no one else so far seems to have noticed this).
That Cialdini book is a gem, by the way. I read it this summer and it was one of the best "soft-sciences"-type books I've ever read, by far. Highly recommendable.
I beg to differ. Unix offers many IPC methods, and RPC (in whatever incarnation) is widely acknowledged as the least desirable of them, in the Unix tradition. BSD sockets are probably the most useful and flexible. Sure, using sockets forces you to come up with some text-based protocol to "marshall/unmarshall" the data you pass among your software components. But this is good, since it forces you to use a loosely coupled architecture.
In terms of security, XP should completly out-class Linux/Unix in every metric of measurement.
Although I can think of many areas in which XP can outclass Unix/Linux, security is not even remotely one of them. I do agree with the rest of your argument (default settings being so insecure), but that statement above is so preposterous I could not let it go by unchallenged.
Like antdude said above, the real problem with this is that the exploit affects something which is actually a
feature of WMF files. A feature which is used by certain apps.
I have witnessed first hand how Guilfanov's unofficial patch will break some legaccy apps. The one in question was a 16-bit app (based on Access 2.0). After applying the patch, it was impossible to print some forms (we received an error). Sure, we uninstalled the patch and printing was OK again.
So therefore the interesting thing about the upcoming Microsoft patch is, how are they going to patch the hole without breaking the legitimate uses of the affected gdi functions???
...at least with 1.1, we never had any problems whatsoever. Both W2000 or W2003 as Terminal Servers (don't know about Citrix). Just install the base installation with "-net", then let each user perform the "user" (or "workstation") installation part themselves. In latest 1.1 versions, this "user" installation wizard would automatically start upon the user logging in.
They even give specific examples of how to use it in combination with OpenVPN.
Moreover, this technique looks like it should work with any kind of NAT, whether
full-cone, restricted-cone, or symmetric. On the other hand, the "third-node" (mediator) technique
will not work with symmetric NAT.
It looks like an udp-based, ssl-based VPN, only that it uses the "third server" trick to get NAT-to-NAT traversal. From the site:
How Hamachi Works
Hamachi is a UDP-based virtual private networking system. Its peers utilize the help of a 3rd node called mediation server to locate each other and to boot strap the connection between themselves. The connection itself is direct and once it's established no traffic flows through our servers.
Looks nice, but nothing spectacularly new. It might be handy if you need to set up a VPN through NAT-to-NAT, but I'm sure there are many other (open source) systems which achieve the NAT-to-NAT thing.
Since I don't need NAT-to-NAT, my ssl VPN of choice is OpenVPN. Moreover, it can be used over udp or tcp.
Except that older sshd don't have the ability to honor requests to forward to any random port on-the-fly, AFAIK. You specify which ports you're gonna forward at connection time.
Precisely, I think he was saying that you cannot recover from segfaults when using threads, and that
this is yet one more reason why threads are a bad idea in Unix (for user apps). In any case, it is common wisdom that SysV IPC methods and threads do not mix well at all.
Slashdot Mirror
Any competent and well-informed programmer knows that the openness of C#/.NET is a total sham. Sure the core is open, but there's so many Windows-only extensions that it's virtually impossible to make cross-platform apps. Plus the fact that the Mono implementation is always waay behind Microsoft's.
But MS has been very clever. They know that it's only technical people who can see this; the rest will just get the subliminal message that ".NET is now also cross-platform, just as Java".
This is the real damage of Mono. Its existence provides the right excuse for PHB and clueless tech decision-makers to sway the decision towards .NET instead
of Java, because, "hey, Microsoft is also cross-platform now".
It's hard to make the average person understand just how useless this is when you hit the memory wall.
However, it is fair to say that IBM still build machines whose memory subsystems scale waaay better that anything in PC-land.
Just look at thre STREAM benchmark numbers and you'll see clearly that AMD has been way ahead of Intel when it comes to RAM bandwidth. I just benchmarked a dual-Quad-Xeon myself (Dell 2900) and I could not believe the poor results I got. One app running in the system can get up to around 3,500 MB/s. Put just two tasks running together (taskset'ed to different chips), and they will each get around 2,600 MB/s. From there on, total aggregate bandwidth tops at 5,200 MB/s and stays there, no matter how many simultaneous tasks you run (it will of course degrade if you run more than eight tasks, you get the point).
Dual-socket Opteron machines from two years ago can get to 15,000 MB/s aggregate, easily.
So, I'd really like to know if Intel is planning to improve things in this department.
AMD is still way ahead of Intel when it comes to jobs which combine these two things:
- floating point (general purpose, not just video-encoding primitives)
- use of lots of RAM in "non-cache-friendly" ways
This is specially noticeable if you have a multi-core, multi-chip machine and start firing up several compute intensive jobs at the same time. If you don't believe me, try running several instances of the STREAM benchmak and see for yourself. Or go to www.spec.org and look at the SPEC CFP2006 Rates numbers (see this for instance, and compare).Barcelona is supposed to increase scalability even a bit more from the current Opterons. Let's see if Intel comes up with something in this department. So far they have not, and that's why most scientific computing in the last 5 years is done on Opterons.
Someone had to mention his other famous interview.
The way I see C++ these days: it might be your only choice if you are building a mass-market "horizontal" app (like, say, mozilla), and even then I would consider alternatives such as Objective C or plain ANSI C. But for "enterprise" apps, it is absolutely dreadful! Like someone said, it is the language with the most error-inducing features.
This blogpost talks about OpenMP vs TBB: Threading Building Blocks: Solution Looking for a Problem?
I'm surprised nobody mentioned Sun Studio 12, which just came out recently. This time, the Linux release comes (for the first time) with its own compilers, instead of relying on gcc. It'll be interesting to see how they compare to Intel's, specially on AMD chips...
It's very useful to have some normalized way of measuring watts/performance, as they try to do in this article. But at least they could have used a more general and useful benchmark, like those offered by www.spec.org.
I wish the mod system could go over 5 because the parent post is +20 Insightful++.
Sometimes I think that if people in other engineering disciplines could understand what's been going on in the computing business, then they would desperately cry and ask for prosecution. At least the people who designed and the industries who pushed these broken languages/libraries should be indicted for careless negligence (or whatever the legal term for this is).
After all these years, I have my doubts this interview was really a hoax.
For all this talk about (digital information) compression, not many people seem to realize that dynamic range compression is typically waaay worse these days. Yes, it's a whole different kind of compression we're talking about here. And it affects the mastering almost all newer CDs, which is what we all use as the source for rips and (digital) compression. Regarding this matter, I found the writings of Bob Katz to be quite clear and enlightening.
Bleh. The benchmarks I'd really like to see are the ones geared towards scientific computing, like STREAMS and SPEC . Nowadays the Intel chips seem to score better on those "gaming" and "media-encoding" benchmarks, but that doesn't neccessarily mean that Intel FPUs are better for general scientic computing. (in fact, experience so far shows the opposite)
Until these things are able to do double-precision, their applicability to general HPC problems remains very limited. Make them do DP arithmetic, and benchmark with SPEC and McAlpine's STREAMS benchmarks, and then we'll see. Oh and BTW, make a Fortran-90/95 compiler available.
Mod parent +20 insightful (since almost no one else so far seems to have noticed this).
That Cialdini book is a gem, by the way. I read it this summer and it was one of the best "soft-sciences"-type books I've ever read, by far.
Highly recommendable.
...it is free only if your time is free.
Well, if you mean for technical academic prose, here's a little gem from NASA (it's an oldie):
I beg to differ. Unix offers many IPC methods, and RPC (in whatever incarnation) is widely acknowledged as the least desirable of them, in the Unix tradition. BSD sockets are probably the most useful and flexible. Sure, using sockets forces you to come up with some text-based protocol to "marshall/unmarshall" the data you pass among your software components. But this is good, since it forces you to use a loosely coupled architecture.
Although I can think of many areas in which XP can outclass Unix/Linux, security is not even remotely one of them.
I do agree with the rest of your argument (default settings being so insecure), but that statement above is so preposterous
I could not let it go by unchallenged.
FAT is such a technical piece of crap that I would have thought nobody would want to patent it, out of pure
embarrassment.
For non-technical people who don't grok filesystems, there's a good story about FAT here: CyberSnare.
I have witnessed first hand how Guilfanov's unofficial patch will break some legaccy apps. The one in question was a 16-bit app (based on Access 2.0). After applying the patch, it was impossible to print some forms (we received an error). Sure, we uninstalled the patch and printing was OK again.
So therefore the interesting thing about the upcoming Microsoft patch is, how are they going to patch the hole without breaking the legitimate uses of the affected gdi functions???
...at least with 1.1, we never had any problems whatsoever. Both W2000 or W2003 as Terminal Servers (don't know about Citrix). Just install the base installation with "-net", then let each user perform the "user" (or "workstation") installation part themselves. In latest 1.1 versions, this "user" installation wizard would automatically start upon the user logging in.
Moreover, this technique looks like it should work with any kind of NAT, whether full-cone, restricted-cone, or symmetric. On the other hand, the "third-node" (mediator) technique will not work with symmetric NAT.
Looks nice, but nothing spectacularly new. It might be handy if you need to set up a VPN through NAT-to-NAT, but I'm sure there are many other (open source) systems which achieve the NAT-to-NAT thing.
Since I don't need NAT-to-NAT, my ssl VPN of choice is OpenVPN. Moreover, it can be used over udp or tcp.
Except that older sshd don't have the ability to honor requests to forward to any random port on-the-fly, AFAIK. You specify which ports you're gonna forward at connection time.
Precisely, I think he was saying that you cannot recover from segfaults when using threads, and that this is yet one more reason why threads are a bad idea in Unix (for user apps). In any case, it is common wisdom that SysV IPC methods and threads do not mix well at all.