Slashdot Mirror
Munich Spurns Steve Ballmer's Software Rebates
Kurt Pfeifle writes "Steve Ballmer's recent trip to Munich to offer up to
90% rebates for the Microsoft Software Assurance and
Licenses was in vain. The ruling party of Germans biggest city and self-proclaimed 'technology capital' now decided
to migrate 14.000 workstations to Linux and an OSS
office suite. A study comparing the alternatives had
assigned 6218 (out of 10.000) points to Linux/OSS,
while the MS Windows platform only scored 5293. Babelfish translation of the latest newsticker story."
I've looked at several books to see how persistent server threads are used/designed/implemented in .NET and there isn't any that I can find. Of course this doesn't mean there isn't. It just means I can't find any. What I'm testing is the feasibility of using the default Thread or ThreadPool class in .NET to build a persistent "daemon like" service. I want to be able to manage things on IIS intelligently because the application has to handle real transactions that require sync calls to ADO. This is necessary because doing it in an async fashion would be more expensive, because it only delays the sync process. The service has to get data updates constantly from different sources and update a shared memory pool. The transaction absolutely have to have accurate data. A few seconds delay is not acceptable in this particular case. The responsiveness of the service has to update the shared data in sub 100 milisecond range.
From my tests using 2 separate service threads, getting access to those threads can take several seconds. It doesn't matter if the updates are managed by another thread, or the data objects themselves subscribes to MSMQ. In both cases, getting access to the service threads takes considerably time and therefore makes it inappropriate. Consider this, if the order of data updates have to happen as they come in, it requires the sync access to those threads. that means, the delegate has to join the service thread. If the requirements allowed async updates it would be a piece of cake, but that's not the case. Doing sync calls on an existing thread appears to be an order of magnitude slower than Java in this particular case. I haven't even bothered to try more than two threads, since two threads is already too much for .NET.
If you don't agree with my statements, feel free to prove me wrong with real facts.
This really sucks for the American economy. Software exports are one of the shining stars in our trade balance.
Oh, well. We'll just gloss over the typical Slashdot bitching about jobs going to India. Now, the slashdotters gloat when American software companies lose sales. See? You really can have it both ways.
Note: Mod this as a troll AND flamebait. I've been karma whoring and am feeling pretty bad about the whole damned affair.
"If you want to improve, be content to be thought foolish and stupid." - Epictetus
This is Germany... their culture is beer, pretzels, and soccer.
Black and grey are both shades of white.
So what does that say about boxed versions of Redhat, Mandrake, Suse, blah blah blah?
So stop using the most ubiquitous storage medium there is?
Telling the user to either save the file twice or use a different storage medium doesn't solve the underlying problem. Because text data is not stored as text, it becomes incredibly difficult to retrieve partial text data when the underlying medium is damaged. All media can become corrupt and damaged, floppy, hd, and yes even cdroms. Storing text data as anything other than text adds a layer of complexity to the recovery process.
It also makes it more difficult to view the file in another program. If I don't have something that can read a word 2000 file, I can always pop open any text editor and get the data without the formatting.
If I don't have a program that can read an openoffice file, I first have to know what compression is used, find a program that can uncompress it, then open it in a text editor. Again, that's completely unnecessary. I have yet to see a justifiable reason for compressing the data. My two little "I like to read slashdot" files came in at 4.5 kb for Open Office and 9 kb for word 2000. That's not enough difference to justify the space saving.
Many thanks to Dubia and Co. without their 1333t diplomatic slizzz where would Germany be now.
Steel
There are none as blind as those who will not see.. (unknown)