Thanks - I was going to reply but you got there first. Map reduce and big table, etc - old technologies found again. A must when you have to match arbitrary queries - SQL (actually relational databases but in many minds same?) just doesn't do it, something what was know, forgotten and slowly acknowledged again.
That was it! I tried to remember, I honestly might find one somewhere in our old stuff but probably lost now. Yes - it was analog with potentiometers and I actually adapted one to drive my radio - search stations, turn the volume, too lazy to get up but then everyone tripped to the line, not good..
Maybe not scared to death but concerned. Mostly, of course, for financial reasons but there also are some very bright people who would like to make computing more efficient.
Now - multiple processors / cores is nothing new, I hit those in 70's and loved them. Unfortunately the education and training didn't follow - more geared to basics, algorithms, structures, languages, etc than what, how and why? And it is even worse today - a product specialization and certificates are what pays - not performance, architecture, design, security, whatever!
Almost any computer problem can be broken to parallel solutions and execution - when was the last time that was in job requirements, you know those things which make you employed?
Right, except it's not always just I/O. I'm not much Windows fan but (XP at least) can be efficient. It is the bad application - I designed a comm. subsystem, queuing, en/decryption, image translation, key management, etc, tested it in 1,2,4,8 core systems (emulating the application) and could drive all cores to 100% busy, almost linear throughput increase. Now - add an application to top of that - 1-2 cores, 20%, 2-4 cores none and 8 cores -%10 throughput?
Took three months to fight the application developers (and they still don't get it?) - total misuse of threadpools in C#! And they were supposed to be the C#/.NET specialist - I'm just an OS guy (mainly MVS/Unix/Linux?) And I had a very good team writing the services for that subsystem but no saying anything about the application design?
The problem I see is that Windows is so much easier to write bad applications - the subsystem actually (excluding auditing) runs under Wine in Linux and, just for fun, I tested it. Same results, very near same throughput.
And please, if running in Intel, test your hyper-threading - not good for everything!
It is funny - I'm loosing my points by answering but this has to be explained to the rest of the world. We in Finland, Sweden and Norway have had this friendly companionship over hundreds of years (as long as it doesn't touch sport, talking about hockey between Finland and Sweden in a bar in California got everybody alarmed!) Or when Sweden occupied Finland a couple of times, actually good times in history but they speak a weird language so we got rid of them BUT not the language, the second official language in Finland - heh! Besides, Sweden is good keeping Russia in shack - they scared some submarines with red stars very well a couple of years ago - it was funny! Of course, Norwegians are the best dancers and may have the best home made beer but they don't have Absolut or Finlandia!
Finland democratic? Sorry, thought to give the funny rating but not many wouldn't have got it. Try to play with politicians and politics in Finland and you start understanding that many parties can play the same game as two. Thanks anyway - I needed something funny today..
How can this be a troll? It just states the legal situation, in most countries, except giving the work to "public domain" still keeps the rights with the creator. Has nothing to do with communism or any other political or even business, whatever system. I agree, benefiting the society is not communism - are any benefits coming out for the public from US government communism? I don't think so and I don't think the politicians would like that definition either! But maybe the tax payback from GWB was a mark of communism, or enhancing the roads, or having FCC, FMA, etc? Do you think so, do you really think that it is that simple? Off topic, of course.
This makes more sense than what we do have to our house - 5 cables! Started with XXXX back in 90's, did go through all the Ameritech, SBC, AT&T, etc and every time they changed owner/name - a new line? Actually the CLEC (and the connection, we have only one coming to town) has always been the same but they just insist installing a new line every time and there is nobody to take the old lines away? The funny thing - a storm took all the lines down and, guess what, SBC (or whoever..) did put all of them back - only one active of course? Must cost a bunch? The price has actually gone down over years, the speed has increased, stays up 24x7, no caps (as far as I know), so can't complain too much.
As would I, not that it matters.. You take, point by point, Edward Demings list and compare it to any software company practices! What do you get - a total mismatch, because it would break the management structure (and lower the next quarter profits - maybe?)
Part of blame goes to the consumer! There was a time when I was able to get an answer and often a fix in 12 hours from vendor. And they better - otherwise our ($1 million in 70's) monthly license payments somehow created the same problems, got lost, whatever. Of course you are holding you license payments today as long as there are obvious, not fixed problems in product?
Later, moving to vendor side, I was told not to hurry, we have more important things to do, as another week of meetings how to have better quality (I learned a lot of new acronyms and abbreviations, mostly made for inside use by some managers?), or told that actually it is a feature caused by "cost savings" and already in plans to change, maybe? And the customers, most of them, seemed happy with those answers, of course a little edited for customer use! And they bought the line how difficult and expensive it is to fix so it takes time - sorry?
Of course a customer is different, try that with your own management - I'm looking the problem, it takes time to analyze, to schedule the change to my workload, to find a good and correct solution, to develop and to test it, to figure how to incorporate it and the new documentation to the product and then to deploy it? Should work, if not, learn marketing and sales tactics!
For some answers which seem to assume that a person in assembly line, developers, etc, can do anything to change the process - go and get a job, maybe after a while you are not any more so sure how the current world works?
You are so right! IT today is not creating but using - unfortunately (or fortunately if you take it that way) even huge software (don't know so much about hardware) companies don't develop, they buy! And the results are not always nice because they did see a nice product but can't / don't know what to with it? Of course it is nice for some who take the pain to develop (new) something and (may) get bought out, so no wonder that people are not any more interested to work in IT - it is a consumer trade and industry today.
Keeping the same title.. Be careful - titles have an inflation today, yesterdays operators are now administrators, administrators are managers, programmers are developers, developers are architects, and so on. You are on right track, using marketing terms as Web 2.0, etc which don't even have definitions will take you up - just try to get your title changed. Looking a new job - the first screening is the job title! Should not be difficult, companies give titles rather than pay more, the Dilbert principle, but it works.
About IT being boring - after 30+ years I still think there are no boring jobs but there are very boring tasks! A huge difference - any job in IT can be interesting if you are allowed to do it right, as you have found out. Again, be careful, even in best companies it doesn't last, you get new management, new visions, new whatever and you will be limited and without a title (the magical words) can't even get out, you have to start all over again.
Had to comment, the reference to Jim Gray was a little weird? I was lucky to work with Jim and we were often talking about technology changes and enhancements. Now - see what for example Tandem did call "massively parallel" database! The system was already built to allow several cpus and several nodes to interconnect transparently, Jim did see how that could be used and how the database optimizer really could work. Of course making direct access to any disc faster will help, especially now when the SDD's are getting bigger but the theory is nothing new. Even SQLite can show you that and think systems where you have 32, 128 or even 256 bit flat, memory speed but storage backed world - will change the picture, or? But be careful, we have already gone through many iterations making part of the system faster, as fixed head disks and even indexing in solid state, and found that it may (will) create other problems, not always seen upfront (except by JG!)
I don't know about _anyone_ but it seems to be on right ballpark - measured! Also, the difference in memory usage seems to be huge - not as much but almost. And the code - using intelligent, configuration based build and delivery of messages only needs one common API to build a message, one common API to send a message and one event entry point to receive a message, always looks same, no playing with arguments, flags, whatever. And, of course, language, platform and communication/transport method agnostic, optionally encrypted / decrypted even in rest, transaction / retry / reroute / audit / etc support without special coding, and so on.
Yes, systems as these already exist but unfortunately the code is still proprietary even the methods are 30+ years old. Maybe because some of those methods seem get patented lately or whatever, who wants (and have resources) to fight years in courts?
I think you are right. Now, as in some systems I know they follow the rules, every initiation of a program or transaction is based on authorization of the initiator AND program/transaction (authentication is already done by default - the program is already starting). The execution rights, the database access on field level, the network access, etc are also based on same authorization. Might not help if the person granting the authorizations is totally clueless but might help when the OS asks the permissions for an unknown (to the user) program to access an unknown (to the user) node in network or asks if it is allowed to read your documents, overwrite or rename a program or a library, turn the microphone or the camera on, read or modify the register, to change to supervisory (sorry, root) access, to use a service, to create an executable, to install a hook, etc. If the warnings would be written in clear (and polite) language I think most users would think twice before allowing all that. And once one of the privileges would be disallowed, all the privileges could be taken away from that program or process.
Honestly, I think MS tried that with Vista but took shortcuts and didn't think the whole picture but did it in piecemeal - will not work, too many places, too many products, not very clear warnings, etc, the authorization functionality has to be deeper in OS, totally independent of any program or application. Linux may have an edge but even SELinux, etc are immature, too complicated for a "normal" user. OSX is friendlier but not perfect, needs something like Little Snitch and other add-ons for more control.
Yes, VMS is nice and hardware definitely more resilient than in Tandem, it is just the OS (and a little hw thinking) which makes Tandem a transaction system. Replace z9 with HP? Probably not, depends a little what kind of applications. If you need more data processing than cpu power, nothing beats mainframes even today. Yes, nice, fast cpus can have a lot of cycles, nice raids can have fast access times but when it comes to processing massive amounts of data in a small (funny, smaller than most racks) box - good luck. And I still miss my sub-second response times, the easy to use and program, the predictable performance and capacity, etc in those boxes.
Well, yes.. I have had those as you, not many but. At one time I was supporting 20+ installations, and one was like that, a global stock broker system. I like Tandem but learned to hate that installation, anything and everything which can go wrong, did! Nice IT department but the management was useless or our salesmen were too good - I don't know which one? No capacity planning!
Now, Tandem isn't and has never been a "mainframe", they are totally different beasts. Tandems were (are) built to handle transactions and do that well. Yes, you can build clusters, HA's, whatever but to guarantee transactions in a world where one millisecond timestamp difference may mean millions lost or won is different. Choses I know, Tandem or mainframes (maybe Stratus?) - and in that world the cost of your backbone is really not the most important factor. Some places have learned that a hard way. You can replicate the transaction support Tandem does in any system but why? - it will not be cheap or easy, may have tried!
More to the topic, Tandem applications have a long time been hardware, OS version or protocol agnostic, well written requesters and servers from 80's will run happily in todays systems. I don't know many but there are some..
Yes, Tandems are amazing. It is not that components can't fail, they do, but the system as whole stays up crunching happily. And if you have a remote site, even one site down can't take the system down, the remote takes over. Tandem has been doing this since -76. In my time we had nodes in 110+ countries, all interconnected, supportable from other side of world, etc.
Now, the most interesting bugger I have seen was a Data-Saab (later Ericsson) manufacturing system, way before Tandem. Had the OS written in Cobol, supported failsafe takeover between two cpu's, etc. Round -84 in an iron mill and I was told that it had run 14 years, never stopping, never down, and never touched, under a layer of dust, just doing it's job. Military grade, I would say.
My personal oldest software running today is an utility program written -74. What I hear they will keep it running every night as long as the system will support 24bit mode - right, in IBM 360..390 systems. An assembler program, my fame/shame, there is not enough money I would touch that program, tried once years later and gave up, unmaintainable!
Having installed computer centers.. It is scary, it is not so much that a bend cable (fiber?) cost but do you have a spare? Are you sure that the electricity is connect correctly? Will the cooling work? Hopefully it doesn't include the fire extinguisher system installation - a scary thought! Did you remember to secure the raised floor? Did you label everything - correctly? And so on..
We used to do that over weekends in very large installations but it was scary every time. Too many things which could have gone wrong and have catastrophic results.
I halfway agree. Parallelism (tasks,attach,etc) is often more useful and easier to handle. By the way, parallelism was available in single core systems, I wrote those before we got systems with more than one cpu - a long time ago. Can be useful even in one core if they do I/O, as you said, or there is for example an attached vector processor.
Now - threading can be useful. I just designed a system where the system itself controls the threads. Let's say the image convert on message path is slow and slows down the whole messaging because of serialization. They systems checks if more cores are available, if there is cpu / memory resources and if so, starts a new image process. It is also very handy way to start a new thread but with different arguments, dynamic configuration, and signal the old thread to exit once it has done the current processing. Or, if the audit process fails or gets an fatal error from SQL server and server has to be restarted, which takes time, the system starts another audit server temporarily saving messages somewhere else. Makes coding these processes much easier - no recovery code or queuing in process itself, can even swapped to use totally different SQL system in flight, etc. Or a new "line" is configured to system, just start a new TCP/IP thread for it, nothing else have to change.
You are absolutely right, no programming system which stops the flow at any time has no place in systems which need continuous flow! It is (was?) called systems design. Not in education any more? Definitely not in many requirements any more!
Yes, I see that a management problem, can't blame programmers so much - you do what is told. But a real pain if it gets to production. And trying to argue that more cores and processors don't help in those cases because everything still gets locked. Or that increasing threads / threadpool sizes only usually makes it worse. Add more memory for message buffers(?) - even higher peeks once they get flowing again and latency, timing problems go out of the roof sometimes ending to total meltdown where the system doesn't do anything else but tries to manage itself!
It seems that programming has gone back to batch days, read input, process, output, repeat instead of keeping the flow going. Or even worse, polling the inputs, still happening on application layers.
You are right - as I have said many times over, I'm not a C (derivates) fan and don't know much about C# but wasting my and company time to find the memory problems (as the lead - i.e. the problem solver) and then teaching C# "specialists" how to code was painful. And yes, in C++, you have to really understand what's happening behind your back, sometimes you get lucky but sometimes.. These languages are made for simple, straight information / data management, not for writing anything where you have to control the system so they have their places. Another problem they have common, when a vendor library changes (gets fixed?), you may have problems - not pointing fingers but Java versions,.NET versions, etc are responsible of a couple of my gray hairs. None of core C in these systems hasn't changed a long time except some inefficiencies corrected.
I'm not a C fan but would someone specify why it is supposed to be difficult to write multi-threaded, multi-core, multi-node, whatever code in C. I see this coming up time to time. Now, I have written C 20+ years and never had any problems, running from 1 to xx cores (where available). Yes, I would prefer even lower level control or a powerful Algol type language as TAL in Tandem but not often available. C++ and C# - ouch, the nights I have used fixing either bad code or problems in libraries for threading, locking problems, stack overflows and lost memory - I want to forget! No language replaces thinking.
No, not all compilers are written in C. And actually Yaztromo is right, there are languages which can bootstrap themselves, some LISPs I like especially, no limits how much to expand the language just by definitions and let it recompile itself. And it also happens to be very safe language, just not easy to read sometimes. NetREXX is nice too, way undervalued for some things.
Languages are like dresses, one is fashionable now and then comes the next fashion. Unfortunately often based on marketing and not facts but that's business.
Just have to comment your comment. It is refreshing to see that Sun, on which I have worked since 80's and seen sometimes going this way and sometimes going that way, is getting back to where the good "engineering" is more important for business than the car salesman talk. Sun is (has been) a weird company, they made some very good enhancements for computing and then retracted? Many times - want the manuals? Now, I don't really like Java as a system, Java as a language is decent, but the number of API's, or in OO language the methods, is ridiculous. When I ask a developer how they would implement one thing they start putting down a lot of objects and methods when in reality it would need just a couple of "old fashioned" calls? Short and simple is forgotten in Java (and C++/C# is no better). Maybe just my ignorance but sometimes fixing the code gets to you when the developers have left the company and there is a mess.
Great and dandy (I'm in bad mood today) but hardware is different than software! You can open the interface to your hardware, no matter what IP (intellectual property - define it - in no formal definition!) they use in hardware. It is either unwillingness or they just don't understand? Or maybe they have some contracts with closed systems where they promise not to let others to play? I don't know and it is up to them but sometimes a pain. Weird - you can get the specs from IBM, SUN, NAS, TI, etc for their hardware, actually free, and much more valuable than graphics cards, so it doesn't make sense?
A good answer. I have no idea where I'm as a listener - no games but I need my music, mainly on my a couple hundred bucks headphones using professional sound gear (my sons!) but then, sometimes I really like the commercial, modified for enjoyment sound? Definitely NOT when playing Ella or classical (you want all you can get) and something which has been recorded / saved without compression (old or new) but, just for background music. The funny thing, old Turtle Beach seems to work best when I don't have access to some nice, external Firewire gear - a couple sound cards in box but lately, maybe getting old, Turtle Beach has been sitting in my work computer. Each their own!
Slashdot Mirror
Thanks - I was going to reply but you got there first. Map reduce and big table, etc - old technologies found again. A must when you have to match arbitrary queries - SQL (actually relational databases but in many minds same?) just doesn't do it, something what was know, forgotten and slowly acknowledged again.
That was it! I tried to remember, I honestly might find one somewhere in our old stuff but probably lost now. Yes - it was analog with potentiometers and I actually adapted one to drive my radio - search stations, turn the volume, too lazy to get up but then everyone tripped to the line, not good..
Maybe not scared to death but concerned. Mostly, of course, for financial reasons but there also are some very bright people who would like to make computing more efficient.
Now - multiple processors / cores is nothing new, I hit those in 70's and loved them. Unfortunately the education and training didn't follow - more geared to basics, algorithms, structures, languages, etc than what, how and why? And it is even worse today - a product specialization and certificates are what pays - not performance, architecture, design, security, whatever!
Almost any computer problem can be broken to parallel solutions and execution - when was the last time that was in job requirements, you know those things which make you employed?
Right, except it's not always just I/O. I'm not much Windows fan but (XP at least) can be efficient. It is the bad application - I designed a comm. subsystem, queuing, en/decryption, image translation, key management, etc, tested it in 1,2,4,8 core systems (emulating the application) and could drive all cores to 100% busy, almost linear throughput increase. Now - add an application to top of that - 1-2 cores, 20%, 2-4 cores none and 8 cores -%10 throughput?
Took three months to fight the application developers (and they still don't get it?) - total misuse of threadpools in C#! And they were supposed to be the C#/.NET specialist - I'm just an OS guy (mainly MVS/Unix/Linux?) And I had a very good team writing the services for that subsystem but no saying anything about the application design?
The problem I see is that Windows is so much easier to write bad applications - the subsystem actually (excluding auditing) runs under Wine in Linux and, just for fun, I tested it. Same results, very near same throughput.
And please, if running in Intel, test your hyper-threading - not good for everything!
It is funny - I'm loosing my points by answering but this has to be explained to the rest of the world. We in Finland, Sweden and Norway have had this friendly companionship over hundreds of years (as long as it doesn't touch sport, talking about hockey between Finland and Sweden in a bar in California got everybody alarmed!) Or when Sweden occupied Finland a couple of times, actually good times in history but they speak a weird language so we got rid of them BUT not the language, the second official language in Finland - heh! Besides, Sweden is good keeping Russia in shack - they scared some submarines with red stars very well a couple of years ago - it was funny! Of course, Norwegians are the best dancers and may have the best home made beer but they don't have Absolut or Finlandia!
Finland democratic? Sorry, thought to give the funny rating but not many wouldn't have got it. Try to play with politicians and politics in Finland and you start understanding that many parties can play the same game as two. Thanks anyway - I needed something funny today..
How can this be a troll? It just states the legal situation, in most countries, except giving the work to "public domain" still keeps the rights with the creator. Has nothing to do with communism or any other political or even business, whatever system. I agree, benefiting the society is not communism - are any benefits coming out for the public from US government communism? I don't think so and I don't think the politicians would like that definition either! But maybe the tax payback from GWB was a mark of communism, or enhancing the roads, or having FCC, FMA, etc? Do you think so, do you really think that it is that simple? Off topic, of course.
This makes more sense than what we do have to our house - 5 cables! Started with XXXX back in 90's, did go through all the Ameritech, SBC, AT&T, etc and every time they changed owner/name - a new line? Actually the CLEC (and the connection, we have only one coming to town) has always been the same but they just insist installing a new line every time and there is nobody to take the old lines away? The funny thing - a storm took all the lines down and, guess what, SBC (or whoever..) did put all of them back - only one active of course? Must cost a bunch? The price has actually gone down over years, the speed has increased, stays up 24x7, no caps (as far as I know), so can't complain too much.
As would I, not that it matters.. You take, point by point, Edward Demings list and compare it to any software company practices! What do you get - a total mismatch, because it would break the management structure (and lower the next quarter profits - maybe?)
Part of blame goes to the consumer! There was a time when I was able to get an answer and often a fix in 12 hours from vendor. And they better - otherwise our ($1 million in 70's) monthly license payments somehow created the same problems, got lost, whatever. Of course you are holding you license payments today as long as there are obvious, not fixed problems in product?
Later, moving to vendor side, I was told not to hurry, we have more important things to do, as another week of meetings how to have better quality (I learned a lot of new acronyms and abbreviations, mostly made for inside use by some managers?), or told that actually it is a feature caused by "cost savings" and already in plans to change, maybe? And the customers, most of them, seemed happy with those answers, of course a little edited for customer use! And they bought the line how difficult and expensive it is to fix so it takes time - sorry?
Of course a customer is different, try that with your own management - I'm looking the problem, it takes time to analyze, to schedule the change to my workload, to find a good and correct solution, to develop and to test it, to figure how to incorporate it and the new documentation to the product and then to deploy it? Should work, if not, learn marketing and sales tactics!
For some answers which seem to assume that a person in assembly line, developers, etc, can do anything to change the process - go and get a job, maybe after a while you are not any more so sure how the current world works?
You are so right! IT today is not creating but using - unfortunately (or fortunately if you take it that way) even huge software (don't know so much about hardware) companies don't develop, they buy! And the results are not always nice because they did see a nice product but can't / don't know what to with it? Of course it is nice for some who take the pain to develop (new) something and (may) get bought out, so no wonder that people are not any more interested to work in IT - it is a consumer trade and industry today.
Keeping the same title.. Be careful - titles have an inflation today, yesterdays operators are now administrators, administrators are managers, programmers are developers, developers are architects, and so on. You are on right track, using marketing terms as Web 2.0, etc which don't even have definitions will take you up - just try to get your title changed. Looking a new job - the first screening is the job title! Should not be difficult, companies give titles rather than pay more, the Dilbert principle, but it works.
About IT being boring - after 30+ years I still think there are no boring jobs but there are very boring tasks! A huge difference - any job in IT can be interesting if you are allowed to do it right, as you have found out. Again, be careful, even in best companies it doesn't last, you get new management, new visions, new whatever and you will be limited and without a title (the magical words) can't even get out, you have to start all over again.
Had to comment, the reference to Jim Gray was a little weird? I was lucky to work with Jim and we were often talking about technology changes and enhancements. Now - see what for example Tandem did call "massively parallel" database! The system was already built to allow several cpus and several nodes to interconnect transparently, Jim did see how that could be used and how the database optimizer really could work. Of course making direct access to any disc faster will help, especially now when the SDD's are getting bigger but the theory is nothing new. Even SQLite can show you that and think systems where you have 32, 128 or even 256 bit flat, memory speed but storage backed world - will change the picture, or? But be careful, we have already gone through many iterations making part of the system faster, as fixed head disks and even indexing in solid state, and found that it may (will) create other problems, not always seen upfront (except by JG!)
I don't know about _anyone_ but it seems to be on right ballpark - measured! Also, the difference in memory usage seems to be huge - not as much but almost. And the code - using intelligent, configuration based build and delivery of messages only needs one common API to build a message, one common API to send a message and one event entry point to receive a message, always looks same, no playing with arguments, flags, whatever. And, of course, language, platform and communication/transport method agnostic, optionally encrypted / decrypted even in rest, transaction / retry / reroute / audit / etc support without special coding, and so on.
Yes, systems as these already exist but unfortunately the code is still proprietary even the methods are 30+ years old. Maybe because some of those methods seem get patented lately or whatever, who wants (and have resources) to fight years in courts?
I think you are right. Now, as in some systems I know they follow the rules, every initiation of a program or transaction is based on authorization of the initiator AND program/transaction (authentication is already done by default - the program is already starting). The execution rights, the database access on field level, the network access, etc are also based on same authorization. Might not help if the person granting the authorizations is totally clueless but might help when the OS asks the permissions for an unknown (to the user) program to access an unknown (to the user) node in network or asks if it is allowed to read your documents, overwrite or rename a program or a library, turn the microphone or the camera on, read or modify the register, to change to supervisory (sorry, root) access, to use a service, to create an executable, to install a hook, etc. If the warnings would be written in clear (and polite) language I think most users would think twice before allowing all that. And once one of the privileges would be disallowed, all the privileges could be taken away from that program or process.
Honestly, I think MS tried that with Vista but took shortcuts and didn't think the whole picture but did it in piecemeal - will not work, too many places, too many products, not very clear warnings, etc, the authorization functionality has to be deeper in OS, totally independent of any program or application. Linux may have an edge but even SELinux, etc are immature, too complicated for a "normal" user. OSX is friendlier but not perfect, needs something like Little Snitch and other add-ons for more control.
Yes, VMS is nice and hardware definitely more resilient than in Tandem, it is just the OS (and a little hw thinking) which makes Tandem a transaction system. Replace z9 with HP? Probably not, depends a little what kind of applications. If you need more data processing than cpu power, nothing beats mainframes even today. Yes, nice, fast cpus can have a lot of cycles, nice raids can have fast access times but when it comes to processing massive amounts of data in a small (funny, smaller than most racks) box - good luck.
And I still miss my sub-second response times, the easy to use and program, the predictable performance and capacity, etc in those boxes.
Well, yes.. I have had those as you, not many but. At one time I was supporting 20+ installations, and one was like that, a global stock broker system. I like Tandem but learned to hate that installation, anything and everything which can go wrong, did! Nice IT department but the management was useless or our salesmen were too good - I don't know which one? No capacity planning!
Now, Tandem isn't and has never been a "mainframe", they are totally different beasts. Tandems were (are) built to handle transactions and do that well. Yes, you can build clusters, HA's, whatever but to guarantee transactions in a world where one millisecond timestamp difference may mean millions lost or won is different. Choses I know, Tandem or mainframes (maybe Stratus?) - and in that world the cost of your backbone is really not the most important factor. Some places have learned that a hard way. You can replicate the transaction support Tandem does in any system but why? - it will not be cheap or easy, may have tried!
More to the topic, Tandem applications have a long time been hardware, OS version or protocol agnostic, well written requesters and servers from 80's will run happily in todays systems. I don't know many but there are some..
Yes, Tandems are amazing. It is not that components can't fail, they do, but the system as whole stays up crunching happily. And if you have a remote site, even one site down can't take the system down, the remote takes over. Tandem has been doing this since -76. In my time we had nodes in 110+ countries, all interconnected, supportable from other side of world, etc.
Now, the most interesting bugger I have seen was a Data-Saab (later Ericsson) manufacturing system, way before Tandem. Had the OS written in Cobol, supported failsafe takeover between two cpu's, etc. Round -84 in an iron mill and I was told that it had run 14 years, never stopping, never down, and never touched, under a layer of dust, just doing it's job. Military grade, I would say.
My personal oldest software running today is an utility program written -74. What I hear they will keep it running every night as long as the system will support 24bit mode - right, in IBM 360..390 systems. An assembler program, my fame/shame, there is not enough money I would touch that program, tried once years later and gave up, unmaintainable!
Having installed computer centers.. It is scary, it is not so much that a bend cable (fiber?) cost but do you have a spare? Are you sure that the electricity is connect correctly? Will the cooling work? Hopefully it doesn't include the fire extinguisher system installation - a scary thought! Did you remember to secure the raised floor? Did you label everything - correctly? And so on..
We used to do that over weekends in very large installations but it was scary every time. Too many things which could have gone wrong and have catastrophic results.
I halfway agree. Parallelism (tasks,attach,etc) is often more useful and easier to handle. By the way, parallelism was available in single core systems, I wrote those before we got systems with more than one cpu - a long time ago. Can be useful even in one core if they do I/O, as you said, or there is for example an attached vector processor.
Now - threading can be useful. I just designed a system where the system itself controls the threads. Let's say the image convert on message path is slow and slows down the whole messaging because of serialization. They systems checks if more cores are available, if there is cpu / memory resources and if so, starts a new image process. It is also very handy way to start a new thread but with different arguments, dynamic configuration, and signal the old thread to exit once it has done the current processing. Or, if the audit process fails or gets an fatal error from SQL server and server has to be restarted, which takes time, the system starts another audit server temporarily saving messages somewhere else. Makes coding these processes much easier - no recovery code or queuing in process itself, can even swapped to use totally different SQL system in flight, etc. Or a new "line" is configured to system, just start a new TCP/IP thread for it, nothing else have to change.
You are absolutely right, no programming system which stops the flow at any time has no place in systems which need continuous flow! It is (was?) called systems design. Not in education any more? Definitely not in many requirements any more!
Yes, I see that a management problem, can't blame programmers so much - you do what is told. But a real pain if it gets to production. And trying to argue that more cores and processors don't help in those cases because everything still gets locked. Or that increasing threads / threadpool sizes only usually makes it worse. Add more memory for message buffers(?) - even higher peeks once they get flowing again and latency, timing problems go out of the roof sometimes ending to total meltdown where the system doesn't do anything else but tries to manage itself!
It seems that programming has gone back to batch days, read input, process, output, repeat instead of keeping the flow going. Or even worse, polling the inputs, still happening on application layers.
You are right - as I have said many times over, I'm not a C (derivates) fan and don't know much about C# but wasting my and company time to find the memory problems (as the lead - i.e. the problem solver) and then teaching C# "specialists" how to code was painful. And yes, in C++, you have to really understand what's happening behind your back, sometimes you get lucky but sometimes.. These languages are made for simple, straight information / data management, not for writing anything where you have to control the system so they have their places. Another problem they have common, when a vendor library changes (gets fixed?), you may have problems - not pointing fingers but Java versions, .NET versions, etc are responsible of a couple of my gray hairs. None of core C in these systems hasn't changed a long time except some inefficiencies corrected.
I'm not a C fan but would someone specify why it is supposed to be difficult to write multi-threaded, multi-core, multi-node, whatever code in C. I see this coming up time to time. Now, I have written C 20+ years and never had any problems, running from 1 to xx cores (where available). Yes, I would prefer even lower level control or a powerful Algol type language as TAL in Tandem but not often available. C++ and C# - ouch, the nights I have used fixing either bad code or problems in libraries for threading, locking problems, stack overflows and lost memory - I want to forget! No language replaces thinking.
No, not all compilers are written in C. And actually Yaztromo is right, there are languages which can bootstrap themselves, some LISPs I like especially, no limits how much to expand the language just by definitions and let it recompile itself. And it also happens to be very safe language, just not easy to read sometimes. NetREXX is nice too, way undervalued for some things.
Languages are like dresses, one is fashionable now and then comes the next fashion. Unfortunately often based on marketing and not facts but that's business.
Just have to comment your comment. It is refreshing to see that Sun, on which I have worked since 80's and seen sometimes going this way and sometimes going that way, is getting back to where the good "engineering" is more important for business than the car salesman talk.
Sun is (has been) a weird company, they made some very good enhancements for computing and then retracted? Many times - want the manuals?
Now, I don't really like Java as a system, Java as a language is decent, but the number of API's, or in OO language the methods, is ridiculous. When I ask a developer how they would implement one thing they start putting down a lot of objects and methods when in reality it would need just a couple of "old fashioned" calls? Short and simple is forgotten in Java (and C++/C# is no better). Maybe just my ignorance but sometimes fixing the code gets to you when the developers have left the company and there is a mess.
Great and dandy (I'm in bad mood today) but hardware is different than software! You can open the interface to your hardware, no matter what IP (intellectual property - define it - in no formal definition!) they use in hardware. It is either unwillingness or they just don't understand? Or maybe they have some contracts with closed systems where they promise not to let others to play? I don't know and it is up to them but sometimes a pain. Weird - you can get the specs from IBM, SUN, NAS, TI, etc for their hardware, actually free, and much more valuable than graphics cards, so it doesn't make sense?
A good answer. I have no idea where I'm as a listener - no games but I need my music, mainly on my a couple hundred bucks headphones using professional sound gear (my sons!) but then, sometimes I really like the commercial, modified for enjoyment sound? Definitely NOT when playing Ella or classical (you want all you can get) and something which has been recorded / saved without compression (old or new) but, just for background music. The funny thing, old Turtle Beach seems to work best when I don't have access to some nice, external Firewire gear - a couple sound cards in box but lately, maybe getting old, Turtle Beach has been sitting in my work computer. Each their own!