I'm not sure what the laws are at Google's new location, but here in Connecticut business property is taxed in two different ways.
I don't know the law in Google's new location, either, but you seem to presume that all States are personal property tax States, like Connecticut. That's a false presumption. In fact, your neighbor, New York State, has no personal property tax.
California is, it happens, a personal property tax State, but it's not at all clear to me that the tax is applicable to personal property on federal enclaves. I'd think not.
The local government does not have a beef here. The deal is between NASA and Google and the local authorities have nothing to say about it. They lack jurisdiction. Period. End of story.
So it's the responsibility of the employees (and the other country residents) to make up for Google not paying taxes? That's crap.
No, what you're spouting is crap. "Make up for?" What's to "make up for?" It's completely between NASA and Goodle. Say, how about if Google changes their minds due to the bad attitude of Santa Clara County and calls it off? What's to make up for then? How about NASA rents space to Google at another federal facility in another State? What's to make up for, then? And what would Santa Clara County have to say about that? Or how about if Google gets tired of fuckwits like you and just shuts down? Santa Clara County has no claim on Google just as it has no claim on me, and what goes on on federal property is just none of Santa Clara County's business.
The federal government, much less NASA, doesn't get local tax exemptions
No, you don't get it. The federal government doesn't get tax exemptions from local government -- federal property is simply not subject in any way to State or local tax jurisdiction. That means that federal property is not taxable by State or local authorities and operations conducted on federal property by the federal government, such as, say, a supermarket for federal personnel, owe no sales or income tax to the city, county or State. Fairness has nothing to do with it. Tax exemptions have nothing to do with it.
Good thing the city didn't promise the money to loan sharks.
I think it would be better if they had promised it to loan sharks. At least then there would be a good chance the fuckwitted local gummint officials would get their legs broken, or worse.
Hey! Maybe this could be a workable way to control local expenditures! Require that local gummints borrow their money from and lodge their pensions with the Mafia. Then it becomes a self-limiting process, since the local officials only have so many legs to be broken and heads to be put in paint shakers.
Sales/use taxes don't work like that. The taxable event occurs in the jurisdiction where the buyer takes possession of the goods. Anyone who buys over the counter and walks out with their goods is taking possession in the same jurisdiction where the store is located, hence sales tax is charged by the seller. Anyone who buys by any means for delivery to, say, their home in another State is not charged sales tax unless the seller also has a qualifying presence in the buyer's State. If no such sales tax is charged, then the buyer is generally liable for paying Use Tax to the State where he accepts delivery. Nowhere in sales/use tax law or principle is there anything that would make the location of the server significant in any way. The "transaction" does not take place on the server. The taxable event occurs where the goods are delivered. Use taxes are usually impractical to enforce against individuals because the taxing State has little or no handle on the transactions except for large and obvious items like cars, boats, planes, etc. In such cases the State presumes that the car you register is taxable unless there is a provision to reduce the tax by the sales tax you may have paid in the other State where you drove the car off the lot.
these days coding has become gui but has lost its first requirement of making something which will do the job
Quite so. I know of a case in which a Java weenie group was called in to make an attractive and usable front end for a Wang VS mainframe app. Their starting point was, "We don't know anything about your mainframe so you'll have to export your data every night and stuff it into an Oracle database so we can access it." OK, that wasn't great, but the client went along. The Java weenies proceeded to burn up months of calendar time and six figures of fees, after which they turned over something purporting to be a functional applet front end supported by their server back end.
On first connection, a user was presented with a dire warning message in English, not the language of many of the client's remote users. Ignoring the warning and proceeding, the user was treated to a multi-megabyte download, never mind that many of the users were on dialup connections in third world countries.
If and when the applet finally got to run, it presented a spreadsheet-like arrangement of the data with incorrectly sized columns. In the view of the Java weenies the user could just drag the column dividers around to suit, but on every new connection it initially came up wrong and always had to be manually adjusted just to see the data.
But the real hoot was that when the user dragged the column dividers around, the screen blinked multiple times like a strobe. The Java weenies blamed that effect on the version of Windows the client had selected as the corporate standard. That was proven to be a lie when the client's people traveled and made use of every known type of platform and OS in airport lounges and found the strobe effect to be universal.
The project was terminated and the client called me for a one-day onsite consultation. In that one day I showed them how to manage HTTP sessions in the Web server on their Wang VS mainframe and in one additional day made a minor change to the Web server to provide a small missing piece necessary to completely support session control.
In the couple of months following that consultation the client easily implemented exactly what they had originally wanted, entirely in CGI, at a tiny fraction of the cost of the failed Java project, and went on to implement credit card payments and clearing house authorization in the same mainframe. They suppported their user interface in real time from live data and didn't have to support another box and database or do nightly file transfers to work around the ignorance of the Java weenies and serve up stale data. They were completely satisfied with their fully integrated solution.
My point is that some of the weenies running around pushing trendy new technologies aren't even capable of implementing what they're selling. Even when they can, their solutions are unlikely to be integrated, as they don't want to dirty their hands or minds with proper interfacing to existing technologies. Proper integration, though, may produce far better results without the new technologies than what the anti-mainframe weenies are peddling.
Re:IBM is trying the save a piece of his bizness
on
Keeping the Lights On
·
· Score: 1
I'm a taker. I'd like to see what the applications are written in. We're replacing legacy Wang VS mainframes with a virtualized VS that is 100% binary compatible with the original. The Wang VS metaphor is the easiest mainframe metaphor to work with, in programming, operation and use. The New VS offers twice the processing/user capacity of the largest, fastest Wang VS made (the 1999 VS18950) and with all the hardware virtualized it is much nicer to work with. Most things that were agonzing hardware decisions in the legacy world are mere matters of virtual configuration in the New VS. Want to have 50 or 100 virtual disk drives? Just carve them out of RAID and initialize them. Want to support 500-1000 users? That's easy.
That's the beauty of the Wang VS mainframe... unlike IBM's model, where CICS was the workaround for getting a batch OS to handle interactive stuff, Wang COBOL is built on an interactive OS and has integrated workstation I/O. Screens can be defined inline, each screen being just one COBOL statement, or they can be kept in copybooks. When you compile this way you get your screen-related errors as compile errors, not runtime errors. And transaction processing is integrated at the OS/filesystem level with rollback and rollforward recovery. Host Language Interface for the PACE database supports RPG and COBOL 74/85, so database metastatements are standard. The PACE subsystem even generates skeleton COBOL database programs at the touch of a key.
Back when I was just a wee young'un, back in ought-60-something, I hated the very idea of COBOL. Later, when I came to my senses, I discovered that COBOL is very nice indeed for business data processing, including interactive apps. It's the verbosity that makes it readable, and with proper tools nobody actually types all that stuff... one uses boilerplate, one uses copybooks (=includes), one copies sections of code and modifies them, one duplicates lines, etc.
Even before the Internet? Gosh, son, the Internet is quite new on my calendar. How about before integrated circuits? How about before transistor logic? How about before large parts of rural America had electricity?
Re:the bad part abt this argument is
on
Keeping the Lights On
·
· Score: 2, Insightful
No, the problem isn't that new guys can't have a chance if old guys are not shitcanned like yesterday's newspapers. Both can work side by side. That should be the natural way of things... the new guys come in and learn from the old guys how things work. Gradually, over time, the old guys retire or die off and the new guys become the old guys. Technologies advance along the way in a rational manner.
The problem today is that business managers don't understand that IT is not the same as plumbing or electrical stuff. The enterprise computing system is not like the office copier. Combine that with a preoccupation on following IT fashion trends and you get insane shops where solid systems are replaced by tinkertoy houses of cards that become unmaintainable and lose key personnel before they are even completed. DP is fundamentally DP no matter what pretty front end one may try to put on it. To think that DP is well handled with new tools like OO stuff is to miss the point: the business of business is expressed entirely in ordinary characters making up fields making up records making up files. Even with the fanciest user interface on it it's still all about simple characters. Building the business processing in C or C++ has to be one of the most stupid trends ever to have developed in IT. Using databases where the main "benefit" is an open door to endlessly complicate the straightforward business of business is not too bright, either.
I blame a lot of it on the ascension of the "professional manager." You know them... they are proud of their ignorance of all things technical. They hold status meetings that consist of going through last week's list of open items, checking where each item stands, closing items, opening new ones, adjusting expected completion dates, and adjusting responsibilities. A monkey could do that. If anything remotely technical creeps into the discussion of the open items, their eyes glaze over with an audible crunching sound.
I blame another big part of it on the ascension of the bean counters. Back when business ran pretty well, the bean counters were hidden somewhere in the back, wearing green visors, keeping track of where the company had been. An old friend once likened accounting and bookkeeping to the view out the back window of a car. If you steer looking out the back window, you'll wind up in a ditch. Now that we have CFOs with a voice in running companies, a lot of companies are being steered by the view out the back window and are running into ditches.
The problem pointed out in TFA is a result of the new Clueless Management Suit Culture (CMSC). Management today in many businesses is too stupid to understand the value of experienced people. Large computer operations, whether mainframe or server farms, are indeed rocket science, but management views IT like they view their plumbing and electrical systems -- just call someone in when it needs attention.
I've lived through the changes that the last 40 years have brought in IT, which used to be called DP, MIS, ADP, etc. There have always been knowledgeable, hard working people on the front lines but over the years the bean counter and professional manager culture has taken over at management and executive levels, with disastrous results. There are no words adequate to express the contempt in which I hold modern business management. In the last 10-15 years I have seen more utterly stupid and wasteful decisions and policies than I would ever have imagined possible in my worst nightmares.
It seems that IT today is determined more by IT fashion trends than anything rational. Executives and managers micromanage IT while understaffing it and creating environments that result in 50-80% annual turnover of IT personnel. At one client location I was the only person to provide continuity over the course of 4-1/2 years during which every other IT position was vacated and later filled with someone who knew nothing about the site, the technology or the application. That included the IT Director, all the programmers and all the operators.
A word about documentation, since it has crept into this topic: Management is responsible for it being impossible to have documentation. Through the 1970s the custom in most shops was to document the plan with design and functional specs, then document the resulting work upon completing something. What evolved in the 1980s and 90s was that new things were pushed onto our plates faster and faster, making it impossible to document anything. With the loss of documentation, the people became more crucial to the organization, but the same suits who made it impossible to document anything also regarded people as thoroughly expendable and not worthy of paychecks sufficient to retain them for the long haul. So the suits screwed themselves coming and going. It's a wonder some of them manage to stay in business at all.
In the 1970s I had the pleasure of working for Scantlin Electronics (later renamed Quotron Systems), a company that had very low turnover. Two of us who left during that time returned and were welcomed back. In general, people there were paid just a bit more than the going rate, not by any stated policy but by the culture created by the engineer founder of the company, Jack Scantlin. Everyone gets upset from time to time and looks for a "better" job. But if one is already well-paid, such searches rarely produce anything interesting. And if the environment is very good to begin with, the result is low turnover and high continuity. It doesn't matter so much whether or not things are well documented if the people never leave. All the same, in the 1970s we documented our work.
Low turnover and a sane environment lead to something else that today's suits don't understand at all: the efficiency of small-team development. We never had more than an average of six programmers but we consistently beat competing shops that had scores of mediocre programmers. We could complete each others' sentences and get things done almost as quickly as it took to formulate designs and think them through. One time we built and installed a complete customer system from scratch -- no OS and no app boilerplate -- in three weeks. Not only did we design it and write the code in that time, the system never had a single bug reported against it in its multiyear lifetime.
I know of another place, a civil service IT department, where the same 5-6 people have been there forever. They have built a repository of 50,000 COBOL programs. A recent audit found tha
This does not, however, cover the "Spontaneous" part of Spontaneous Combustion, which I thought was a rather large oversight.
But that was covered in the piece for TV. On examination of the facts of the cases there was a source of ignition in each case. A cigarette in one, a candle in another, etc. Traditionally the sources of ignition have been discounted because they would normally be expected to cause a traditional fire. In the older accounts such as in the "Fact Stranger than Fiction" paperbacks of years ago the likely sources of ignition simply weren't mentioned. Falling over dead while carrying a candle isn't common but apparently it has happened now and again. Smoking in bed is well known as a cause of fire. In some rare cases of death or disablement in the presence of a source of ignition, if the fire gets started in the clothing instead of the bedding or other surroundings and proceeds just right and the person can't wake up for one reason or another the wick effect can come into play and result in an apparent case of SHC.
If leaping to conclusions were an Olympic event, Slashdot would be the home of a large number of gold medal holders.
When I was in Jr. High School I had an insulated synthetic jacket made of some material like nylon or rayon. One day the elevator in my apartment building was painted with some goopy paint with texture thingies in it. Afteward I noticed that I was sometimes shocked when touching the metal door to leave at my destination floor. I put two and two together and figured it must be my jacket touching the elevator walls. The elevator was quite small and it was difficult to be in it in a bulky jacket without the jacket touching anything.
So I slid along the wall, rubbing the jacket against the paint, then touched the metal control panel. (SNAP!) Ouch! I got out my keys and tried it again, using a key to touch the panel. I still felt it in my hand but it was no longer actually painful.
This became a game for the rest of the winter on my departures in the morning to go to school and my arrivals back from school in the afternoons. I tried to see how big a spark I could generate from the tip of the key to the elevator panel.
I didn't carry a ruler but I'd estimate the largest sparks were a good quarter-inch, and they were very hot. The color was white and they made a loud SNAP. Discharging one through a finger was wayyyyy painful.
The point is... while I have no idea what really happened in the incident reported in the article, all the people here claiming one or more wild-assed theories why a jacket couldn't be involved in generating significant static charge are talking through their assholes. I had a jacket that produced very painful static discharges and for all I know the combination of materials in the jacket and the elevator paint may not even have been optimal for generating such charges.
If I still had the jacket and the elevator I'd offer to demonstrate serious static jacket charge by discharging it to the corneas of the ignorant skeptics. That would be a hoot... "(rub-rub-rub) OK, look closely at this key..." SNAP! "YEOW-ow-ow-ow-ow-ow-ow-ow-ow-ow-ow-ow-ow!"
See the show. The researchers reproduced SHC with a rather large pig, possibly making it SPC (Spontaneous Porcine Combustion) or RIPC (Researcher Induced Porcine Combustion). Pigs don't normally wear clothes but this one was draped for the occasion. Only parts of the body burn because only parts are covered with a wick (cloth). It burns without damaging nearby objects because it burns with a very low flame. Convection disperses the heat throughout the room. If you look at reports of SHC you'll find that there is always a source of combustion involved but it's always dismissed because the whole place didn't burn down. The experiment even resulted in bones that powdered at a touch, another characteristic of SHC. As it happens, horse shit has nothing whatsoever to do with it.
To the fuckwitted moderator who assigned "Troll" to my reply to the arrogant "recruiter:" This was in no way a troll. It was commentary on the arrogance of the self-styled recruiter. I make my own jobs. I don't send out CVs to anyone, ever. So the recruiter's opinions and viewpoint have no effect on me or on anything I do. He/she has no control whatsoever over my opportunities to work. On the contrary, I make decisions about whom to hire and with whom I will associate, and my criteria are vastly different than those determined by the current corporate suit mentality. Nor am I the only one in this position. Even in the past, when I did work for other people, I never went through recruiters or personnel departments, so they had no effect on my work possibilities then, either.
FWIW, I place no stock in certifications and have nothing but contempt for those who do.
Can you tell us a little about BOINC and the history behind it?
Sure. We ran into certain limits in the original SETI@Home project and wanted to broaden our, uh, horizons while finding an excuse for spending more time drinking microbeer, wine, and eating cheese.
Besides SETI@home and Climateprediction.net, what other projects are using BOINC?
We're evaluating some candidates, including the Find-A-Valid-Credit-Card-Number project, the Lottery Prediction project, and the PI Generator project. You know, the limits of pi have only begun to be explored. Personally I get all tingly over that one.
What would you say are the main goals and principles behind the design of BOINC?
What we're really about it exploring the limits of low availability. I mean, anyone can keep a server or network up nearly 24 x 7. The real trick is to keep millions of people on the hook while taking a system down for a few hours or a few weeks.
Can you tell us what the main hurdles, technical and otherwise, were in developing BOINC?
It's really, really hard to write consistently unpredictable code and to make networks just stop functioning. Sure, anyone can pull a network cable but how many people can make a network just
slow down or stop routing and switching while everything is plugged in and running? Betcha never thought of it that way, didja?
One would expect that dealing with so many platforms and operating systems would be challenging. How do you handle it?
Oh, that's easy. We don't. We get to things when we get to them. Sometimes we giggle about the zillions of people trying to upload results and pulling their hair out while we have the server running video games.
What are the major security concerns, and how are you addressing them?
Our biggest concern is that too many results might be uploaded and too many new work units handed out. I mean, the more data we process without finding ET, the sooner our funding might dry up, right?
We're hearing a lot about various forms of distributed computing these days, such as grid, utility, on-demand, and SOA (service-oriented architecture). What's your take on these approaches, and how do they relate to volunteer computing?
All that stuff is a bunch of crap. Volunteer computing works because all those stupid people out there with a thousand times a 1960s mainframe on their desks need a life -- they need to feel useful. So we give it to them. They also need to be punished, and we do that, too. Everyone is happy.
Following on that, where's the intersection (if any) between volunteer computing and such familiar technologies as clustering and SMP (symmetric multiprocessing)?
I don't see any. Clustering is still very much a private activity as far as I know (which isn't much, believe me!), and isn't SMP still illegal in some states? I don't have much interest in the kinky stuff. My wife and I... oh, never mind.
What forces do you feel led to the rise of volunteer-donated distributed computing for applications such as SETI@home?
Uh, too much money, too much free time, and a general sense of uselessness that put people in search of ways to justify their existence and their overblown desktop computers. Er, I mean, altruism and a widespread desire to expand human knowledge and understanding of the universe. Yeah, that's the answer.
Where is BOINC headed over the next few years?
Oh, gosh, there is
so much work to do to reproduce the inconsistencies and bugs in the original SETI software on a massively distributed, multiproject scale. We're working on innovative ways to cross fertilize the projects. I mean, wouldn't it be neat if the prote
Am I the only one that stopped participating once they switched to this new client they use now? I couldn't get it to work on either my work or home computers...
I saved myself the grief: I stopped while still using the old client, because the bunch that ran the old system so abysmally poorly couldn't be counted on to run the new system any better. They had chronic problems with their network, with their feeds, with the servers that were supposed to accept results, and with their forums. What use is the science if the people running the implementation are such utter morons? For that matter, who can trust the science if the operators can't even run a network and a few servers?
Would that be the same broken eBay Search that inexplicably alters the search string in some cases, that can't find items clearly up for auction, and that fails to find items clearly up for sale by a seller but that can't list them when pulling up all the auctions for the same seller's ID?
Offering to open up that stuff strikes me like Saddam offering to open-source his blueprint for better government.
You seem to be confusing the founding principles of the United States with European-style popular democracy. The nature of our constitutional republic is that the majority doesn't get its way if what it wants contravenes constitutional restrictions on the power of government or the relatively unbounded natural rights secured by the constitution.
Yes, well, ah, the point was humor, including unpronounceable abbreviations, not to use a few existing terms. The accepted terms you quote are almost humorous and would server, but news announcers might actually be able to pronounce the acronyms.
There's another class of such terms where the acronym is silly or satiric. One I came up with for a satire of some corporate documentation many years ago come to mind:
Peripheral Inertially Navigated Halo-Effect Administrative Device (PINHEAD). This allowed me to make reference to management PINHEADs.
Slashdot Mirror
I don't know the law in Google's new location, either, but you seem to presume that all States are personal property tax States, like Connecticut. That's a false presumption. In fact, your neighbor, New York State, has no personal property tax.
California is, it happens, a personal property tax State, but it's not at all clear to me that the tax is applicable to personal property on federal enclaves. I'd think not.
The local government does not have a beef here. The deal is between NASA and Google and the local authorities have nothing to say about it. They lack jurisdiction. Period. End of story.
No, what you're spouting is crap. "Make up for?" What's to "make up for?" It's completely between NASA and Goodle. Say, how about if Google changes their minds due to the bad attitude of Santa Clara County and calls it off? What's to make up for then? How about NASA rents space to Google at another federal facility in another State? What's to make up for, then? And what would Santa Clara County have to say about that? Or how about if Google gets tired of fuckwits like you and just shuts down? Santa Clara County has no claim on Google just as it has no claim on me, and what goes on on federal property is just none of Santa Clara County's business.
No, you don't get it. The federal government doesn't get tax exemptions from local government -- federal property is simply not subject in any way to State or local tax jurisdiction. That means that federal property is not taxable by State or local authorities and operations conducted on federal property by the federal government, such as, say, a supermarket for federal personnel, owe no sales or income tax to the city, county or State. Fairness has nothing to do with it. Tax exemptions have nothing to do with it.
I think it would be better if they had promised it to loan sharks. At least then there would be a good chance the fuckwitted local gummint officials would get their legs broken, or worse.
Hey! Maybe this could be a workable way to control local expenditures! Require that local gummints borrow their money from and lodge their pensions with the Mafia. Then it becomes a self-limiting process, since the local officials only have so many legs to be broken and heads to be put in paint shakers.
Sales/use taxes don't work like that. The taxable event occurs in the jurisdiction where the buyer takes possession of the goods. Anyone who buys over the counter and walks out with their goods is taking possession in the same jurisdiction where the store is located, hence sales tax is charged by the seller. Anyone who buys by any means for delivery to, say, their home in another State is not charged sales tax unless the seller also has a qualifying presence in the buyer's State. If no such sales tax is charged, then the buyer is generally liable for paying Use Tax to the State where he accepts delivery. Nowhere in sales/use tax law or principle is there anything that would make the location of the server significant in any way. The "transaction" does not take place on the server. The taxable event occurs where the goods are delivered. Use taxes are usually impractical to enforce against individuals because the taxing State has little or no handle on the transactions except for large and obvious items like cars, boats, planes, etc. In such cases the State presumes that the car you register is taxable unless there is a provision to reduce the tax by the sales tax you may have paid in the other State where you drove the car off the lot.
Quite so. I know of a case in which a Java weenie group was called in to make an attractive and usable front end for a Wang VS mainframe app. Their starting point was, "We don't know anything about your mainframe so you'll have to export your data every night and stuff it into an Oracle database so we can access it." OK, that wasn't great, but the client went along. The Java weenies proceeded to burn up months of calendar time and six figures of fees, after which they turned over something purporting to be a functional applet front end supported by their server back end.
On first connection, a user was presented with a dire warning message in English, not the language of many of the client's remote users. Ignoring the warning and proceeding, the user was treated to a multi-megabyte download, never mind that many of the users were on dialup connections in third world countries.
If and when the applet finally got to run, it presented a spreadsheet-like arrangement of the data with incorrectly sized columns. In the view of the Java weenies the user could just drag the column dividers around to suit, but on every new connection it initially came up wrong and always had to be manually adjusted just to see the data.
But the real hoot was that when the user dragged the column dividers around, the screen blinked multiple times like a strobe. The Java weenies blamed that effect on the version of Windows the client had selected as the corporate standard. That was proven to be a lie when the client's people traveled and made use of every known type of platform and OS in airport lounges and found the strobe effect to be universal.
The project was terminated and the client called me for a one-day onsite consultation. In that one day I showed them how to manage HTTP sessions in the Web server on their Wang VS mainframe and in one additional day made a minor change to the Web server to provide a small missing piece necessary to completely support session control.
In the couple of months following that consultation the client easily implemented exactly what they had originally wanted, entirely in CGI, at a tiny fraction of the cost of the failed Java project, and went on to implement credit card payments and clearing house authorization in the same mainframe. They suppported their user interface in real time from live data and didn't have to support another box and database or do nightly file transfers to work around the ignorance of the Java weenies and serve up stale data. They were completely satisfied with their fully integrated solution.
My point is that some of the weenies running around pushing trendy new technologies aren't even capable of implementing what they're selling. Even when they can, their solutions are unlikely to be integrated, as they don't want to dirty their hands or minds with proper interfacing to existing technologies. Proper integration, though, may produce far better results without the new technologies than what the anti-mainframe weenies are peddling.
I'm a taker. I'd like to see what the applications are written in. We're replacing legacy Wang VS mainframes with a virtualized VS that is 100% binary compatible with the original. The Wang VS metaphor is the easiest mainframe metaphor to work with, in programming, operation and use. The New VS offers twice the processing/user capacity of the largest, fastest Wang VS made (the 1999 VS18950) and with all the hardware virtualized it is much nicer to work with. Most things that were agonzing hardware decisions in the legacy world are mere matters of virtual configuration in the New VS. Want to have 50 or 100 virtual disk drives? Just carve them out of RAID and initialize them. Want to support 500-1000 users? That's easy.
That's the beauty of the Wang VS mainframe... unlike IBM's model, where CICS was the workaround for getting a batch OS to handle interactive stuff, Wang COBOL is built on an interactive OS and has integrated workstation I/O. Screens can be defined inline, each screen being just one COBOL statement, or they can be kept in copybooks. When you compile this way you get your screen-related errors as compile errors, not runtime errors. And transaction processing is integrated at the OS/filesystem level with rollback and rollforward recovery. Host Language Interface for the PACE database supports RPG and COBOL 74/85, so database metastatements are standard. The PACE subsystem even generates skeleton COBOL database programs at the touch of a key.
Back when I was just a wee young'un, back in ought-60-something, I hated the very idea of COBOL. Later, when I came to my senses, I discovered that COBOL is very nice indeed for business data processing, including interactive apps. It's the verbosity that makes it readable, and with proper tools nobody actually types all that stuff... one uses boilerplate, one uses copybooks (=includes), one copies sections of code and modifies them, one duplicates lines, etc.
Even before the Internet? Gosh, son, the Internet is quite new on my calendar. How about before integrated circuits? How about before transistor logic? How about before large parts of rural America had electricity?
No, the problem isn't that new guys can't have a chance if old guys are not shitcanned like yesterday's newspapers. Both can work side by side. That should be the natural way of things... the new guys come in and learn from the old guys how things work. Gradually, over time, the old guys retire or die off and the new guys become the old guys. Technologies advance along the way in a rational manner.
The problem today is that business managers don't understand that IT is not the same as plumbing or electrical stuff. The enterprise computing system is not like the office copier. Combine that with a preoccupation on following IT fashion trends and you get insane shops where solid systems are replaced by tinkertoy houses of cards that become unmaintainable and lose key personnel before they are even completed. DP is fundamentally DP no matter what pretty front end one may try to put on it. To think that DP is well handled with new tools like OO stuff is to miss the point: the business of business is expressed entirely in ordinary characters making up fields making up records making up files. Even with the fanciest user interface on it it's still all about simple characters. Building the business processing in C or C++ has to be one of the most stupid trends ever to have developed in IT. Using databases where the main "benefit" is an open door to endlessly complicate the straightforward business of business is not too bright, either.
I blame a lot of it on the ascension of the "professional manager." You know them... they are proud of their ignorance of all things technical. They hold status meetings that consist of going through last week's list of open items, checking where each item stands, closing items, opening new ones, adjusting expected completion dates, and adjusting responsibilities. A monkey could do that. If anything remotely technical creeps into the discussion of the open items, their eyes glaze over with an audible crunching sound.
I blame another big part of it on the ascension of the bean counters. Back when business ran pretty well, the bean counters were hidden somewhere in the back, wearing green visors, keeping track of where the company had been. An old friend once likened accounting and bookkeeping to the view out the back window of a car. If you steer looking out the back window, you'll wind up in a ditch. Now that we have CFOs with a voice in running companies, a lot of companies are being steered by the view out the back window and are running into ditches.
The problem pointed out in TFA is a result of the new Clueless Management Suit Culture (CMSC). Management today in many businesses is too stupid to understand the value of experienced people. Large computer operations, whether mainframe or server farms, are indeed rocket science, but management views IT like they view their plumbing and electrical systems -- just call someone in when it needs attention.
I've lived through the changes that the last 40 years have brought in IT, which used to be called DP, MIS, ADP, etc. There have always been knowledgeable, hard working people on the front lines but over the years the bean counter and professional manager culture has taken over at management and executive levels, with disastrous results. There are no words adequate to express the contempt in which I hold modern business management. In the last 10-15 years I have seen more utterly stupid and wasteful decisions and policies than I would ever have imagined possible in my worst nightmares.
It seems that IT today is determined more by IT fashion trends than anything rational. Executives and managers micromanage IT while understaffing it and creating environments that result in 50-80% annual turnover of IT personnel. At one client location I was the only person to provide continuity over the course of 4-1/2 years during which every other IT position was vacated and later filled with someone who knew nothing about the site, the technology or the application. That included the IT Director, all the programmers and all the operators.
A word about documentation, since it has crept into this topic: Management is responsible for it being impossible to have documentation. Through the 1970s the custom in most shops was to document the plan with design and functional specs, then document the resulting work upon completing something. What evolved in the 1980s and 90s was that new things were pushed onto our plates faster and faster, making it impossible to document anything. With the loss of documentation, the people became more crucial to the organization, but the same suits who made it impossible to document anything also regarded people as thoroughly expendable and not worthy of paychecks sufficient to retain them for the long haul. So the suits screwed themselves coming and going. It's a wonder some of them manage to stay in business at all.
In the 1970s I had the pleasure of working for Scantlin Electronics (later renamed Quotron Systems), a company that had very low turnover. Two of us who left during that time returned and were welcomed back. In general, people there were paid just a bit more than the going rate, not by any stated policy but by the culture created by the engineer founder of the company, Jack Scantlin. Everyone gets upset from time to time and looks for a "better" job. But if one is already well-paid, such searches rarely produce anything interesting. And if the environment is very good to begin with, the result is low turnover and high continuity. It doesn't matter so much whether or not things are well documented if the people never leave. All the same, in the 1970s we documented our work.
Low turnover and a sane environment lead to something else that today's suits don't understand at all: the efficiency of small-team development. We never had more than an average of six programmers but we consistently beat competing shops that had scores of mediocre programmers. We could complete each others' sentences and get things done almost as quickly as it took to formulate designs and think them through. One time we built and installed a complete customer system from scratch -- no OS and no app boilerplate -- in three weeks. Not only did we design it and write the code in that time, the system never had a single bug reported against it in its multiyear lifetime.
I know of another place, a civil service IT department, where the same 5-6 people have been there forever. They have built a repository of 50,000 COBOL programs. A recent audit found tha
But that was covered in the piece for TV. On examination of the facts of the cases there was a source of ignition in each case. A cigarette in one, a candle in another, etc. Traditionally the sources of ignition have been discounted because they would normally be expected to cause a traditional fire. In the older accounts such as in the "Fact Stranger than Fiction" paperbacks of years ago the likely sources of ignition simply weren't mentioned. Falling over dead while carrying a candle isn't common but apparently it has happened now and again. Smoking in bed is well known as a cause of fire. In some rare cases of death or disablement in the presence of a source of ignition, if the fire gets started in the clothing instead of the bedding or other surroundings and proceeds just right and the person can't wake up for one reason or another the wick effect can come into play and result in an apparent case of SHC.
If leaping to conclusions were an Olympic event, Slashdot would be the home of a large number of gold medal holders.
When I was in Jr. High School I had an insulated synthetic jacket made of some material like nylon or rayon. One day the elevator in my apartment building was painted with some goopy paint with texture thingies in it. Afteward I noticed that I was sometimes shocked when touching the metal door to leave at my destination floor. I put two and two together and figured it must be my jacket touching the elevator walls. The elevator was quite small and it was difficult to be in it in a bulky jacket without the jacket touching anything.
So I slid along the wall, rubbing the jacket against the paint, then touched the metal control panel. (SNAP!) Ouch! I got out my keys and tried it again, using a key to touch the panel. I still felt it in my hand but it was no longer actually painful.
This became a game for the rest of the winter on my departures in the morning to go to school and my arrivals back from school in the afternoons. I tried to see how big a spark I could generate from the tip of the key to the elevator panel.
I didn't carry a ruler but I'd estimate the largest sparks were a good quarter-inch, and they were very hot. The color was white and they made a loud SNAP. Discharging one through a finger was wayyyyy painful.
The point is... while I have no idea what really happened in the incident reported in the article, all the people here claiming one or more wild-assed theories why a jacket couldn't be involved in generating significant static charge are talking through their assholes. I had a jacket that produced very painful static discharges and for all I know the combination of materials in the jacket and the elevator paint may not even have been optimal for generating such charges.
If I still had the jacket and the elevator I'd offer to demonstrate serious static jacket charge by discharging it to the corneas of the ignorant skeptics. That would be a hoot... "(rub-rub-rub) OK, look closely at this key..." SNAP! "YEOW-ow-ow-ow-ow-ow-ow-ow-ow-ow-ow-ow-ow!"
See the show. The researchers reproduced SHC with a rather large pig, possibly making it SPC (Spontaneous Porcine Combustion) or RIPC (Researcher Induced Porcine Combustion). Pigs don't normally wear clothes but this one was draped for the occasion. Only parts of the body burn because only parts are covered with a wick (cloth). It burns without damaging nearby objects because it burns with a very low flame. Convection disperses the heat throughout the room. If you look at reports of SHC you'll find that there is always a source of combustion involved but it's always dismissed because the whole place didn't burn down. The experiment even resulted in bones that powdered at a touch, another characteristic of SHC. As it happens, horse shit has nothing whatsoever to do with it.
Really cheap glow-in-the-dark glass, just in time for Halloween decorations!
http://www.anuslaptops.com/
To the fuckwitted moderator who assigned "Troll" to my reply to the arrogant "recruiter:" This was in no way a troll. It was commentary on the arrogance of the self-styled recruiter. I make my own jobs. I don't send out CVs to anyone, ever. So the recruiter's opinions and viewpoint have no effect on me or on anything I do. He/she has no control whatsoever over my opportunities to work. On the contrary, I make decisions about whom to hire and with whom I will associate, and my criteria are vastly different than those determined by the current corporate suit mentality. Nor am I the only one in this position. Even in the past, when I did work for other people, I never went through recruiters or personnel departments, so they had no effect on my work possibilities then, either.
FWIW, I place no stock in certifications and have nothing but contempt for those who do.
You may be a recruiter, but my CV doesn't land on your desk. Ever.
I saved myself the grief: I stopped while still using the old client, because the bunch that ran the old system so abysmally poorly couldn't be counted on to run the new system any better. They had chronic problems with their network, with their feeds, with the servers that were supposed to accept results, and with their forums. What use is the science if the people running the implementation are such utter morons? For that matter, who can trust the science if the operators can't even run a network and a few servers?
Would that be the same broken eBay Search that inexplicably alters the search string in some cases, that can't find items clearly up for auction, and that fails to find items clearly up for sale by a seller but that can't list them when pulling up all the auctions for the same seller's ID?
Offering to open up that stuff strikes me like Saddam offering to open-source his blueprint for better government.
You seem to be confusing the founding principles of the United States with European-style popular democracy. The nature of our constitutional republic is that the majority doesn't get its way if what it wants contravenes constitutional restrictions on the power of government or the relatively unbounded natural rights secured by the constitution.
Yes, well, ah, the point was humor, including unpronounceable abbreviations, not to use a few existing terms. The accepted terms you quote are almost humorous and would server, but news announcers might actually be able to pronounce the acronyms.
There's another class of such terms where the acronym is silly or satiric. One I came up with for a satire of some corporate documentation many years ago come to mind:
Peripheral Inertially Navigated Halo-Effect Administrative Device (PINHEAD). This allowed me to make reference to management PINHEADs.You don't have to dare... please feel free to make a complete fool of yourself here anytime.