Wrong - a crashing thread doesn't kill the main or any other threads. Now - you can code that way if you want but why would you? It is very common to restart crashed threads in 24x7 systems, of course controlling the restarts not going to die / restart loops. Any decent system does that, all the time.
Wrong - thread programming is not hard and nothing new. Designing threaded system is a little harder but nothing new. Same complains I got in 70's when teaching design and development for multitasking systems! Learn to think a system - who cares of one thread, program, process, whatever. If the system is designed for threading it is easy, especially in modern languages, we are not talking assembler or are we? And even in assembler it is just a discipline. And remember to write re-entrant code, oops, thread safe code for your DLLs, libraries, whatever.. Or doesn't your "clever, managed" language do that for you?
Correct. I sometimes wonder how many/. readers are really developers? Mapreduce is old, old technology, Google just made it famous and, maybe, documented. It is not always useful in all cases but never worse than any other method in throughput. If you have to "map" information and the more they are unbalanced, the better it gets.
Actually the question about developers came because a lot of replies are talking about API - if you code, write your own, it is very easy once you understand the principle. And I can tell, multiple cpus, parallel processing and mapreduce method was known already in 70's when I had to write data collections for whatever reason.
And yes, BigTable is a (almost) totally different issue but even that is not new, just used by Google in this scale maybe first time. Not sure even of that - huge government systems do sometimes grazy things but don't tell anybody how.
If the business model is to allow indiscriminate access to data - what can you do? Nothing. I'm totally amazed that it happens, all systems allow at least user but some even role based access restrictions to some of information. No matter who you are! It's a very old technology and even before that we designed systems that way - had to! Also, the statistical limitations or at least alerting is old - you access some information more than normally someone gets alerted. A normal procedure in many business a long time, from insurance to government systems. So - some of the excuses today are kind of lame, not technical but management problems!
The ideas in "Kick-Ass Parallel Machine" are interesting - to some! Of course, we are still talking about "toy" processors / processing - to some! MIPS, micro-parallelism are great to some jobs, not all. Of course the enhancements in one part can later be applied to larger systems but it takes time and sometimes is not so easy. I also could argue that clock-less (no ticks) system would be more efficient, no wasted cycles, easy to optimize by load, whatever.
Agreed, multi-threading today is flawed, how about multi-tasking, much easier! And even doing vector processing, a very old technology in big systems, only solves some specific problems. Handy in small scale, todays systems don't get even near to what the huge vector processors did 20 yeras ago, but a beast to write a compiler for that. I fell in love of that when young - several thousand time performance (execution time) enhancement going from scalar mode to vector mode in one weather simulation program and only took one week to tune the program and the compiler right, pure luck!
And even otherwise - did my graduate work -70 based on US radar data processing - non-classified 128 path parallel processing to feed the computers, sorting, filtering etc. I'm sure the classified performance was much better even then. So - we need new ideas?
Well - "Shame on anyone.." Maybe but I once developed a statistical system to monitor the terminal users - actually to optimize inputs and outputs, running out of bandwidth! After a while the management realized that it could be used to grade the users (spying has always been easy if you control the system!) No way - took a lot of explanations and fighting to prevent that - you just can't statistically grade users by speed, errors, mistakes, retries, etc - too many other variables which are not known! I got almost fired going against it but later on a lot of thanks for preventing them to make that mistake. And of course we would have had full union fight in our hands or a lot of people would have just left if it would have been implemented. Not a bad idea in itself if it could be done but very shortsighted.
Thank you for that picture link - I haven't seen good meat in 30 years! Used to be common when I was young - now, forget it, but I'm still looking. When was last time you got a rare (of course) filet mignon, cut with a fork? Mostly sashimi today - easier to find and, actually, no very expensive in some places.
Correct but often misunderstood. I'm just a little amazed that an article can make these mistakes? And I love sashimi except not so much the less common, but not unusual, sashimi with vegetarian ingredients items such as yuba (bean curd skin) or raw red meats, such as beef or horse.
Looks decent and maybe useful for more than kids. Now - why to think kids are stupid or something. I'm not talking about XP, I can see it running in such machine. Of course Linux gives much more with much less money but a computer is just a computer? My kids have used (my) computers since they were three, never broke anything, boys built their own at age of 8, have no problems whatever OS they have to use, even the one who doesn't care about computers but cars (you know how many separate computers can be in a modern car like new Porches?) And the computers when they were 3 were not PCs - two terminals hanging on two X.25 lines to several big systems, other toys came later.
Kids and computers are like kids and languages - they have no problems at pre-school age to learn 3 or 4 foreign languages in a couple of months in right environment just for fun - seen that! Try that when over 20. Same with computers - if they find it fun, they can learn anything. And most kids never break things, they are just (maybe) a little more accident prone and schools up to college are a harsh environment, more than most workplaces - heh! I wonder if this would tolerate the adults, leaving the notebook top of the car, driving over it or sometimes even shooting the damn computer?
Monoculture is always bad, not just in reliability. I have seen even NonStop systems going haywire after one year up-time, Murphy playing with hardware. Fortunately, in one very big case the customer had anticipated that, we had built a full switchover capability, needed just a flip of a switch and the backup systems took over - no data loss. Yes, a little more costly but not much if done right.
DR - tell that to a couple of my (late) bosses, it was always "someone else's problem". Even a VP, a know-it-all hacker from -80's, who's responsibility was just that because he was the "specialist", was always saying it and didn't plan for it. After the inevitable failure, loss of data, blamed first the vendor and then the developers. Vendor first because the warm backup takeover lost some data, developers because they didn't journal the data - he had forbidden it for "performance" reasons? Funny, because after I hacked (to the live system) the journaling, the throughput did go up about %30 - better parallelism!
When you talk about reliability, security, capacity, etc - there is no such thing as "someone else's problem"! The "someone else" is the company / corporate.
Right, have seen that in many fields and companies. It is not just sales or whatever - once you build a customer relationship it follows you no matter how or what a company wants or thinks. A company is clever if it handles it right, friendly persuasion (money?) or whatever. In all cases when they try to play hardball - both sides lose and the customers go somewhere else. I also have seen companies go down and never recover from that.
Back to subject - didn't they have his contact list already? Didn't they have their own system where he could could manage the contacts? And million other questions - I have (tried to) managed sales people, not easy, a pain, but doable. I don't know details about this case but it seems that the company really didn't know how to run a business - is that that a case for courts, maybe or maybe not?
Good for your company! Yes, I came over to US 25+ years ago from Europe, not as a student but it was a company in Cupertino, CA and we also didn't discriminate between anyone who wanted to work with / for us. Supported a lot of domestic and foreign students and had relationship with schools / universities round the world. Never had problems with INS when taking students, they actually were very supportive. Of course, rules are rules and they had to go back to wait a permanent visa if we liked to hire them - or maybe to work for us in their own country.
Two points - hiring interns has gone worse, they want to get paid a lot instead looking the experience they can get - a big mistake. But then, I have seen corporations also avoiding interns because in interview some managers found them knowing more about the modern systems than they did - weird or maybe not?
Second, your interview tactics are a little uncommon, lunch for an intern? Good for you - a relaxing lunch is a perfect place to find out about a person, just a forgotten skill.. - we used to go for a beer if they accepted that! The answer you gave to "why" is a little weird but maybe cultural?
Funny, why flamebait? If I could vote in US I would vote for a democrat %50 of time, or maybe a little less, there still are more parties than two? Doesn't everybody vote a person by merits, not by (business) connections?
Anyway, an interesting reaction from moderators. And if what I see about moderation, I go with anonymous "Kind like voters?"
Back to topic, interesting - I was one of those in college, not life threatening but the tests were a little difficult when not feeling too well in the morning. Good that I can blame my DNA - fortunately it doesn't seem to go to the next generation, even as adult they often say "thank you" for telling us your shortcomings so we don't have to learn them the hard way. Maybe it skips generations but that's their problem - heh!
There has been a lot of comments that one manufacturer would be bad. Yes, but only as long as the one is government(s) protected the world has shown many times that it just doesn't work for long - for the manufacturer. If it is a lucrative business and not protected by some stupid laws, someone invents a (perhaps) better way. At least until today every and each company having a "monopoly" has stagnated and taken over by competition as long as it hasn't been given privileges by local laws in which case it only takes longer. The public may be slow and very tolerant for a while but when they see what's happening behind the fence they want that also. And computers, if anything, are a world wide thing, see where the Asia is going. Some replies mentioned US car manufacturing, a good example even the government has tried to protect them many times, it just doesn't work. Look steel, paper, sugar, meat, cheese, whatever everyday products - more politics than real world and sooner or later people get tired of that when they realize how much the restrictions hurt them.
Just as mainframes used to be in 70's, a good systems programmer was able to take care of problems and in hard cases just call friends to help - very useful and time saver often..
But - there is an obvious problem as found at that time, fix the system and deviate too much of the main stream - good luck when the next version comes out, your "fixes" will probably not work. Many corporations did go to that trap. I used a lot of long, sleepless night to help them out of "home made fixes and enhancements" which just didn't work in next SW/HW releases.
Yes, it would work IF the corporations would feed the fixes back to the public - do you know (m)any which do? We did but some didn't and later on created nice consulting opportunities which cost the companies a lot! Still needs changes to current corporate / business culture and I'm not holding my breath!
Well said. Neither I am defending or not even a fan of MS but there must be some overnighs going on. The unfortunate thing is that, know some bright people in MS, this is not new but ignored by management(?). And of course they don't talk about it - they are a company to make money and.. MS talks about agile, etc - they still are a total matrix organization, you do what you are told and if you have some bright ideas, keep them and don't bother me - have now met too many managers there maybe?
Motivation, punish? Sorry, I know enough bright people in MS who can/could address this kind of problems given an initiative. It just is not in current MS management culture. With MS resources (and very good developers) they should be the first ones to bring these (old) exploit mechanisms out. But, fortunately, I hear rumors that they try to change, it just takes time in a huge company.
You got it right, thanks. That's the mainframe philosophy - I can kill myself by stupidity or whatever and that's it, everything else keeps running, etc. Or I can try to affect others and get killed - the business goes on. The problem comes a lot from MS (still?) thinking that there is only one user or program per system.
Now, there are rumors that MS is planning next generation, virtual containers, etc (partitions, regions, VMs,..) and it is good if true. Sandbox is NOT a "virtual container", it doesn't have the properties needed to fully control it's load. Better than nothing but..
And actually to all bashing the user - why don't you have a secure server where from the users can install what they need - easy to make work with whatever authentication and security measures you use? If it's not there, check it, secure it, put it there. Ouch - I just realized that all this "business" needs scripts, SQL and even executable code WITH data? Really? I used to keep that kind of server and everybody loved it - local 100Mbit to install anything they needed, up to date, no viruses, even a documentation available, any local configuration already done, get a local e-mail of a new version, get notes when someone found problems, etc.
And, I hope that MS doesn't try to trademark "virtual container" as Dell tried with "cloud computing". I have designed "virtual containers" in three products, once in 70's, once in 80's and last product design in 92. And, actually got the term from airlines 72. So..
Right and known a long, long time - always created nightmares to OS/security. Not long ago, moving AIX and Linux systems from G5 to G6, weird errors. Now there is a hardware stack protection, actually found by Sun much earlier but some "very clever" developer in our Unix product had taken some "shortcuts" - I hate those, sometimes not so easy to find and I had to change a lot of code just because..
Yes - it is the OS and HW working together, no system, not even mainframes, is safe if the basic safeguards in OS are forgotten. And even then, with enough authority, root, admin, supervisor, AND the system AA failing - any system is vulnerable. The computer just executes what it is told (if the hardware allows) - no magic involved.
You can have the best data and code separation but if you can trick the system to load something it assumes is code, the execution is easy. Now - if the "code" is build dynamically, no security program can detect it, no signature, nothing.
I actually have used this technology in two OSs to simplify the transitions between user and OS space, for good purposes, of course. It can be used to cut the extra crap what the OS has to do when trying to secure and control the programs, processes, partitions, regions, memory, interrupts, etc - just don't let anyone else to use your methods!
I just answered to MBGMorden under your comment, take a peek, you make a Perl script to calculate salaries in one day (or in one month, whatever) in real world and you can retire next week and maybe buy Microsoft if that's in your interests. COBOL has nothing to do with this, it just is a precise and clear language for business functions and a excuse for many things.
Yes - I agree, the politics and, unfortunately often, the IT management egos / incompetence are the problem, not the languages or even the operating systems - he should step aside!
Yes - it must have been a joke, all the databases since early -70 had utilities do to the same and more, much more.
As that example - you are right OR someone really had much more simple environment than I have ever seen. Actually salary calculations are kind of art - past and future, contracts, exceptions, ever changing tax rules based on whatever (location, job description, hours accumulated, etc, sometimes prorated), currency (with ever changing rates), age and credits, employment and/or partnership status, shift, prepayments, deductions, allowances, sharing options, sick and vacation days, insurance rates, pensions, and so on - a long, long list. And don't even think about the distribution of payments, it has it's own nightmare, where and when, from what account and for what part, pre or post taxed, law or court ordered splits, currency conversations again with allowed amounts and local/foreign tax withholds, foreign bank transfers, printing, posting, transferring or giving cash or checks from offices - a long, long list again. And of course remember to audit / report all that the regulated way, required by local / foreign laws and rules.
I honestly sometimes wonder in which world the/. people live, don't they ever write anything for a business? And trust me - payroll is simple compared to some other business/IT problems.
In such COBOL programs that I have seen, written and fixed (except that has been the reason to fix those), I have never seen hard coded any of the business rules - all based on tables / databases, which can and do change daily or even several times a day.
The whole COBOL thing is weird, in business environment the languages don't really matter much but good configuration management / source control, database design, layering, etc. COBOL as a language is anyway so simple that any(?) programmer can pick it up in a day or two. And avoid the language based security problems, miscalculations, have a nice, language based error control without catches, tries, throws, whatever.
The main problem is that people who don't know COBOL but have read opinions are repeating what they read. What - no subroutines, functions, etc - I then wonder why our date, etc calculation routines written in assembler still kept working in CICS, IMS and batch programs written in COBOL? How my PL/I print routines worked even in on-line systems written in COBOL. And the statistical Fortran functions gave the same answers when used from on-line (written in COBOL) giving nice (not graphical!) tables to old green terminals (or actually mostly amber in Europe). Or why moving from "home grown" direct access database (on magnetic strips) to VSAM and IMS/DB and relational databases needed no changes in on-line programs facing 100K+ screens. Or why changing a a database structure to accommodate the (stupid) one byte company ID to 32bit only needed one command in CM/SC to compile 18K programs to support it (one weekend though!) Or - how the Data-Saab two cpu, redundant, fail over manufacturing control system ever run with an OS written in COBOL. Maybe people should take a look a Burroughs OS - Algol, what's that?
And I might have agreed a long time ago that COBOL is wordy but after seeing some "new" systems - give me a break, it always seems that everything is invented again in every program - is there a reason for that except inexperience?
Actually - in 70's they IBM was fully open, you got all the source, modified it what ever way you wanted. Then came this IP (intellectual property, not the protocol) which said that you have to hide or to patent it, forced by government - IBM adapted. Forget the punch cards and PC's - supporting thousands of online users in system under one second response time in systems with 4-8MB memory - can you do it today? MVS made that possible. Yes, the displays were not fancy graphics, some color, but for a business - do you really need nice pictures? The graphics did look just the same as today and if you needed some more graphical, attach a Tektronix terminal or maybe a channel attached CAD workstation.
The problem is not the technology, it takes care of itself, but the marketing, sales, profits, etc - and the uneducated/inexperienced users - corporates.
Now - MS free desktop, why not? I actually like some what MS has done but thinking of business - what does it to give me more than what I can get otherwise? Today - the Word documents, everything else I can do faster, with less resources, etc using OS X, Linux, Solaris, BSD, whatever - running in the same system!
So - in long run, no one can dominate, IBM or MS or.., otherwise we all would be running in Univac - EXEC8 or maybe GCOS in Honeywell or perhaps the Burroughs (check your OO!) - brilliant systems but..
I wasn't going to participate but this is one I did a while ago - C# (and.NET) applications running and communicating with other Windows (Win32) and other systems,J ava, comms running in AIX and Linux, XXX number of foreign DLLs and libraries, Tk/Tcl, Python, common management systems for all, etc.
Define (abstract) interfaces! Any time you have different architectures, the easiest is to make interfaces to work for you. Not difficult but when one side is "managed" (what an oxymoron!) and other side is also managed but by you, when you have different platforms, big/small endian, 32 and 64 bits, etc mixed - an interface is your friend.
Many benefits - you can model it easily, you can build prototypes fast when the business processing is separated from application logic, etc. And if the performance is not an issue you can always find a lot of interfacing already defined in all those systems. Now, if you need performance you also have to think the physical side of delivering messages, etc - a little more work, forget XML, etc. Doesn't happen often but especially on network / communication side it usually is a rule. Many other benefits, for example it is very easy to build a recovery, queuing, filtering, security, whatever to an interface, no need for each application and/or service to do that.
How you can be a CSO if you already don't know what this book describes? This book is more like wannabe CSO handbook.
Now - I don't blame the book, it is good (IMHO), but it states facts that have been know 30+ years? Maybe forgotten? But for CxOs or even security managers - how the heck did they get their jobs if they don't already know this?
That seems to be the problem today, the basics! For example security never was, isn't and never will be technology - it is a business fact, much bigger than IT, securing whatever you don't want to be misused or what you want to keep secure/secret/safe. Methods and implementations change day by day but basics don't! New vulnerabilities are found and not all them have anythig to do with IT and can not be prevented by some "miracle" tool or toy but by strategy, planning, design, etc.
Slashdot Mirror
Wrong - a crashing thread doesn't kill the main or any other threads. Now - you can code that way if you want but why would you? It is very common to restart crashed threads in 24x7 systems, of course controlling the restarts not going to die / restart loops. Any decent system does that, all the time.
Wrong - thread programming is not hard and nothing new. Designing threaded system is a little harder but nothing new. Same complains I got in 70's when teaching design and development for multitasking systems! Learn to think a system - who cares of one thread, program, process, whatever. If the system is designed for threading it is easy, especially in modern languages, we are not talking assembler or are we? And even in assembler it is just a discipline. And remember to write re-entrant code, oops, thread safe code for your DLLs, libraries, whatever.. Or doesn't your "clever, managed" language do that for you?
Correct. I sometimes wonder how many /. readers are really developers? Mapreduce is old, old technology, Google just made it famous and, maybe, documented. It is not always useful in all cases but never worse than any other method in throughput. If you have to "map" information and the more they are unbalanced, the better it gets.
Actually the question about developers came because a lot of replies are talking about API - if you code, write your own, it is very easy once you understand the principle. And I can tell, multiple cpus, parallel processing and mapreduce method was known already in 70's when I had to write data collections for whatever reason.
And yes, BigTable is a (almost) totally different issue but even that is not new, just used by Google in this scale maybe first time. Not sure even of that - huge government systems do sometimes grazy things but don't tell anybody how.
If the business model is to allow indiscriminate access to data - what can you do? Nothing. I'm totally amazed that it happens, all systems allow at least user but some even role based access restrictions to some of information. No matter who you are! It's a very old technology and even before that we designed systems that way - had to! Also, the statistical limitations or at least alerting is old - you access some information more than normally someone gets alerted. A normal procedure in many business a long time, from insurance to government systems. So - some of the excuses today are kind of lame, not technical but management problems!
The ideas in "Kick-Ass Parallel Machine" are interesting - to some! Of course, we are still talking about "toy" processors / processing - to some! MIPS, micro-parallelism are great to some jobs, not all. Of course the enhancements in one part can later be applied to larger systems but it takes time and sometimes is not so easy. I also could argue that clock-less (no ticks) system would be more efficient, no wasted cycles, easy to optimize by load, whatever.
Agreed, multi-threading today is flawed, how about multi-tasking, much easier! And even doing vector processing, a very old technology in big systems, only solves some specific problems. Handy in small scale, todays systems don't get even near to what the huge vector processors did 20 yeras ago, but a beast to write a compiler for that. I fell in love of that when young - several thousand time performance (execution time) enhancement going from scalar mode to vector mode in one weather simulation program and only took one week to tune the program and the compiler right, pure luck!
And even otherwise - did my graduate work -70 based on US radar data processing - non-classified 128 path parallel processing to feed the computers, sorting, filtering etc. I'm sure the classified performance was much better even then. So - we need new ideas?
Well - "Shame on anyone.." Maybe but I once developed a statistical system to monitor the terminal users - actually to optimize inputs and outputs, running out of bandwidth! After a while the management realized that it could be used to grade the users (spying has always been easy if you control the system!) No way - took a lot of explanations and fighting to prevent that - you just can't statistically grade users by speed, errors, mistakes, retries, etc - too many other variables which are not known! I got almost fired going against it but later on a lot of thanks for preventing them to make that mistake. And of course we would have had full union fight in our hands or a lot of people would have just left if it would have been implemented. Not a bad idea in itself if it could be done but very shortsighted.
Well - there are other ways, remember Portugal 1974? A hint : http://en.wikipedia.org/wiki/Carnation_Revolution. Who knows - army is not always your enemy!
Thank you for that picture link - I haven't seen good meat in 30 years! Used to be common when I was young - now, forget it, but I'm still looking. When was last time you got a rare (of course) filet mignon, cut with a fork? Mostly sashimi today - easier to find and, actually, no very expensive in some places.
Correct but often misunderstood. I'm just a little amazed that an article can make these mistakes? And I love sashimi except not so much the less common, but not unusual, sashimi with vegetarian ingredients items such as yuba (bean curd skin) or raw red meats, such as beef or horse.
Looks decent and maybe useful for more than kids. Now - why to think kids are stupid or something. I'm not talking about XP, I can see it running in such machine. Of course Linux gives much more with much less money but a computer is just a computer? My kids have used (my) computers since they were three, never broke anything, boys built their own at age of 8, have no problems whatever OS they have to use, even the one who doesn't care about computers but cars (you know how many separate computers can be in a modern car like new Porches?) And the computers when they were 3 were not PCs - two terminals hanging on two X.25 lines to several big systems, other toys came later.
Kids and computers are like kids and languages - they have no problems at pre-school age to learn 3 or 4 foreign languages in a couple of months in right environment just for fun - seen that! Try that when over 20. Same with computers - if they find it fun, they can learn anything. And most kids never break things, they are just (maybe) a little more accident prone and schools up to college are a harsh environment, more than most workplaces - heh! I wonder if this would tolerate the adults, leaving the notebook top of the car, driving over it or sometimes even shooting the damn computer?
Monoculture is always bad, not just in reliability. I have seen even NonStop systems going haywire after one year up-time, Murphy playing with hardware. Fortunately, in one very big case the customer had anticipated that, we had built a full switchover capability, needed just a flip of a switch and the backup systems took over - no data loss. Yes, a little more costly but not much if done right.
DR - tell that to a couple of my (late) bosses, it was always "someone else's problem". Even a VP, a know-it-all hacker from -80's, who's responsibility was just that because he was the "specialist", was always saying it and didn't plan for it. After the inevitable failure, loss of data, blamed first the vendor and then the developers. Vendor first because the warm backup takeover lost some data, developers because they didn't journal the data - he had forbidden it for "performance" reasons? Funny, because after I hacked (to the live system) the journaling, the throughput did go up about %30 - better parallelism!
When you talk about reliability, security, capacity, etc - there is no such thing as "someone else's problem"! The "someone else" is the company / corporate.
Right, have seen that in many fields and companies. It is not just sales or whatever - once you build a customer relationship it follows you no matter how or what a company wants or thinks. A company is clever if it handles it right, friendly persuasion (money?) or whatever. In all cases when they try to play hardball - both sides lose and the customers go somewhere else. I also have seen companies go down and never recover from that.
Back to subject - didn't they have his contact list already? Didn't they have their own system where he could could manage the contacts? And million other questions - I have (tried to) managed sales people, not easy, a pain, but doable. I don't know details about this case but it seems that the company really didn't know how to run a business - is that that a case for courts, maybe or maybe not?
Good for your company! Yes, I came over to US 25+ years ago from Europe, not as a student but it was a company in Cupertino, CA and we also didn't discriminate between anyone who wanted to work with / for us. Supported a lot of domestic and foreign students and had relationship with schools / universities round the world. Never had problems with INS when taking students, they actually were very supportive. Of course, rules are rules and they had to go back to wait a permanent visa if we liked to hire them - or maybe to work for us in their own country.
Two points - hiring interns has gone worse, they want to get paid a lot instead looking the experience they can get - a big mistake. But then, I have seen corporations also avoiding interns because in interview some managers found them knowing more about the modern systems than they did - weird or maybe not?
Second, your interview tactics are a little uncommon, lunch for an intern? Good for you - a relaxing lunch is a perfect place to find out about a person, just a forgotten skill.. - we used to go for a beer if they accepted that! The answer you gave to "why" is a little weird but maybe cultural?
Funny, why flamebait? If I could vote in US I would vote for a democrat %50 of time, or maybe a little less, there still are more parties than two? Doesn't everybody vote a person by merits, not by (business) connections?
Anyway, an interesting reaction from moderators. And if what I see about moderation, I go with anonymous "Kind like voters?"
Back to topic, interesting - I was one of those in college, not life threatening but the tests were a little difficult when not feeling too well in the morning. Good that I can blame my DNA - fortunately it doesn't seem to go to the next generation, even as adult they often say "thank you" for telling us your shortcomings so we don't have to learn them the hard way. Maybe it skips generations but that's their problem - heh!
There has been a lot of comments that one manufacturer would be bad. Yes, but only as long as the one is government(s) protected the world has shown many times that it just doesn't work for long - for the manufacturer. If it is a lucrative business and not protected by some stupid laws, someone invents a (perhaps) better way. At least until today every and each company having a "monopoly" has stagnated and taken over by competition as long as it hasn't been given privileges by local laws in which case it only takes longer. The public may be slow and very tolerant for a while but when they see what's happening behind the fence they want that also. And computers, if anything, are a world wide thing, see where the Asia is going. Some replies mentioned US car manufacturing, a good example even the government has tried to protect them many times, it just doesn't work. Look steel, paper, sugar, meat, cheese, whatever everyday products - more politics than real world and sooner or later people get tired of that when they realize how much the restrictions hurt them.
Just as mainframes used to be in 70's, a good systems programmer was able to take care of problems and in hard cases just call friends to help - very useful and time saver often..
But - there is an obvious problem as found at that time, fix the system and deviate too much of the main stream - good luck when the next version comes out, your "fixes" will probably not work. Many corporations did go to that trap. I used a lot of long, sleepless night to help them out of "home made fixes and enhancements" which just didn't work in next SW/HW releases.
Yes, it would work IF the corporations would feed the fixes back to the public - do you know (m)any which do? We did but some didn't and later on created nice consulting opportunities which cost the companies a lot! Still needs changes to current corporate / business culture and I'm not holding my breath!
Well said. Neither I am defending or not even a fan of MS but there must be some overnighs going on. The unfortunate thing is that, know some bright people in MS, this is not new but ignored by management(?). And of course they don't talk about it - they are a company to make money and.. MS talks about agile, etc - they still are a total matrix organization, you do what you are told and if you have some bright ideas, keep them and don't bother me - have now met too many managers there maybe?
Motivation, punish? Sorry, I know enough bright people in MS who can/could address this kind of problems given an initiative. It just is not in current MS management culture. With MS resources (and very good developers) they should be the first ones to bring these (old) exploit mechanisms out. But, fortunately, I hear rumors that they try to change, it just takes time in a huge company.
You got it right, thanks. That's the mainframe philosophy - I can kill myself by stupidity or whatever and that's it, everything else keeps running, etc. Or I can try to affect others and get killed - the business goes on. The problem comes a lot from MS (still?) thinking that there is only one user or program per system.
Now, there are rumors that MS is planning next generation, virtual containers, etc (partitions, regions, VMs,..) and it is good if true. Sandbox is NOT a "virtual container", it doesn't have the properties needed to fully control it's load. Better than nothing but..
And actually to all bashing the user - why don't you have a secure server where from the users can install what they need - easy to make work with whatever authentication and security measures you use? If it's not there, check it, secure it, put it there. Ouch - I just realized that all this "business" needs scripts, SQL and even executable code WITH data? Really? I used to keep that kind of server and everybody loved it - local 100Mbit to install anything they needed, up to date, no viruses, even a documentation available, any local configuration already done, get a local e-mail of a new version, get notes when someone found problems, etc.
And, I hope that MS doesn't try to trademark "virtual container" as Dell tried with "cloud computing". I have designed "virtual containers" in three products, once in 70's, once in 80's and last product design in 92. And, actually got the term from airlines 72. So..
Right and known a long, long time - always created nightmares to OS/security. Not long ago, moving AIX and Linux systems from G5 to G6, weird errors. Now there is a hardware stack protection, actually found by Sun much earlier but some "very clever" developer in our Unix product had taken some "shortcuts" - I hate those, sometimes not so easy to find and I had to change a lot of code just because..
Yes - it is the OS and HW working together, no system, not even mainframes, is safe if the basic safeguards in OS are forgotten. And even then, with enough authority, root, admin, supervisor, AND the system AA failing - any system is vulnerable. The computer just executes what it is told (if the hardware allows) - no magic involved.
You can have the best data and code separation but if you can trick the system to load something it assumes is code, the execution is easy. Now - if the "code" is build dynamically, no security program can detect it, no signature, nothing.
I actually have used this technology in two OSs to simplify the transitions between user and OS space, for good purposes, of course. It can be used to cut the extra crap what the OS has to do when trying to secure and control the programs, processes, partitions, regions, memory, interrupts, etc - just don't let anyone else to use your methods!
I just answered to MBGMorden under your comment, take a peek, you make a Perl script to calculate salaries in one day (or in one month, whatever) in real world and you can retire next week and maybe buy Microsoft if that's in your interests. COBOL has nothing to do with this, it just is a precise and clear language for business functions and a excuse for many things.
Yes - I agree, the politics and, unfortunately often, the IT management egos / incompetence are the problem, not the languages or even the operating systems - he should step aside!
Yes - it must have been a joke, all the databases since early -70 had utilities do to the same and more, much more.
As that example - you are right OR someone really had much more simple environment than I have ever seen. Actually salary calculations are kind of art - past and future, contracts, exceptions, ever changing tax rules based on whatever (location, job description, hours accumulated, etc, sometimes prorated), currency (with ever changing rates), age and credits, employment and/or partnership status, shift, prepayments, deductions, allowances, sharing options, sick and vacation days, insurance rates, pensions, and so on - a long, long list. And don't even think about the distribution of payments, it has it's own nightmare, where and when, from what account and for what part, pre or post taxed, law or court ordered splits, currency conversations again with allowed amounts and local/foreign tax withholds, foreign bank transfers, printing, posting, transferring or giving cash or checks from offices - a long, long list again. And of course remember to audit / report all that the regulated way, required by local / foreign laws and rules.
I honestly sometimes wonder in which world the /. people live, don't they ever write anything for a business? And trust me - payroll is simple compared to some other business/IT problems.
In such COBOL programs that I have seen, written and fixed (except that has been the reason to fix those), I have never seen hard coded any of the business rules - all based on tables / databases, which can and do change daily or even several times a day.
The whole COBOL thing is weird, in business environment the languages don't really matter much but good configuration management / source control, database design, layering, etc. COBOL as a language is anyway so simple that any(?) programmer can pick it up in a day or two. And avoid the language based security problems, miscalculations, have a nice, language based error control without catches, tries, throws, whatever.
The main problem is that people who don't know COBOL but have read opinions are repeating what they read. What - no subroutines, functions, etc - I then wonder why our date, etc calculation routines written in assembler still kept working in CICS, IMS and batch programs written in COBOL? How my PL/I print routines worked even in on-line systems written in COBOL. And the statistical Fortran functions gave the same answers when used from on-line (written in COBOL) giving nice (not graphical!) tables to old green terminals (or actually mostly amber in Europe). Or why moving from "home grown" direct access database (on magnetic strips) to VSAM and IMS/DB and relational databases needed no changes in on-line programs facing 100K+ screens. Or why changing a a database structure to accommodate the (stupid) one byte company ID to 32bit only needed one command in CM/SC to compile 18K programs to support it (one weekend though!) Or - how the Data-Saab two cpu, redundant, fail over manufacturing control system ever run with an OS written in COBOL. Maybe people should take a look a Burroughs OS - Algol, what's that?
And I might have agreed a long time ago that COBOL is wordy but after seeing some "new" systems - give me a break, it always seems that everything is invented again in every program - is there a reason for that except inexperience?
Actually - in 70's they IBM was fully open, you got all the source, modified it what ever way you wanted. Then came this IP (intellectual property, not the protocol) which said that you have to hide or to patent it, forced by government - IBM adapted. Forget the punch cards and PC's - supporting thousands of online users in system under one second response time in systems with 4-8MB memory - can you do it today? MVS made that possible. Yes, the displays were not fancy graphics, some color, but for a business - do you really need nice pictures? The graphics did look just the same as today and if you needed some more graphical, attach a Tektronix terminal or maybe a channel attached CAD workstation.
The problem is not the technology, it takes care of itself, but the marketing, sales, profits, etc - and the uneducated/inexperienced users - corporates.
Now - MS free desktop, why not? I actually like some what MS has done but thinking of business - what does it to give me more than what I can get otherwise? Today - the Word documents, everything else I can do faster, with less resources, etc using OS X, Linux, Solaris, BSD, whatever - running in the same system!
So - in long run, no one can dominate, IBM or MS or .., otherwise we all would be running in Univac - EXEC8 or maybe GCOS in Honeywell or perhaps the Burroughs (check your OO!) - brilliant systems but..
I wasn't going to participate but this is one I did a while ago - C# (and .NET) applications running and communicating with other Windows (Win32) and other systems,J ava, comms running in AIX and Linux, XXX number of foreign DLLs and libraries, Tk/Tcl, Python, common management systems for all, etc.
Define (abstract) interfaces! Any time you have different architectures, the easiest is to make interfaces to work for you. Not difficult but when one side is "managed" (what an oxymoron!) and other side is also managed but by you, when you have different platforms, big/small endian, 32 and 64 bits, etc mixed - an interface is your friend.
Many benefits - you can model it easily, you can build prototypes fast when the business processing is separated from application logic, etc. And if the performance is not an issue you can always find a lot of interfacing already defined in all those systems. Now, if you need performance you also have to think the physical side of delivering messages, etc - a little more work, forget XML, etc. Doesn't happen often but especially on network / communication side it usually is a rule. Many other benefits, for example it is very easy to build a recovery, queuing, filtering, security, whatever to an interface, no need for each application and/or service to do that.
How you can be a CSO if you already don't know what this book describes? This book is more like wannabe CSO handbook.
Now - I don't blame the book, it is good (IMHO), but it states facts that have been know 30+ years? Maybe forgotten? But for CxOs or even security managers - how the heck did they get their jobs if they don't already know this?
That seems to be the problem today, the basics! For example security never was, isn't and never will be technology - it is a business fact, much bigger than IT, securing whatever you don't want to be misused or what you want to keep secure/secret/safe. Methods and implementations change day by day but basics don't! New vulnerabilities are found and not all them have anythig to do with IT and can not be prevented by some "miracle" tool or toy but by strategy, planning, design, etc.