55 posts • joined Friday 27th April 2007 18:52 GMT
The Man Who Jumped On His Horse......
......And Rode Off In All Directions. HP needs a real strategy or they will be history in five years. In particular, they need to stop trying to develop "me too" Unix boxes and concentrate on NonStop Guardian, Pathway and SQL/MP as the lynchpin of their enterprise business. Their OSS direction just makes the NonStops into expensive and awkward Unix boxes. It's a blind alley and the exit is the dustbin.
The ITU Have A Certain Set Of Expectations
The old men at the ITU are stuck trying to adhere to their original charter, which was to produce secure and reliable communications systems with clearly defined API and protocols.
The progressive younger members don't even know what that means.
It was once said that the problem with guided evolution and eugenics was that a group of Gorillas would never work towards developing a human being. It would be beyond their conception.
Similarly, those who come from the modern mashup of Unix and Darpanet can't understand what those poor ancient bastards are still striving for at the ITU.
The Question Is The Answer
If the benefits of virtualization (or Service Oriented Architecture or any other Grand Solution) are not immediately obvious upon completion; then you've probably wasted a great deal of time and money following a fad. That the question is being asked at all, is the answer.
Choose Your Enemies
Mr. Palmisano would dearly love for all Enterprise system contests to be beween IBM and Oracle; because even if Oracle win the contract; they can't deliver.
Mr. Palmisano does not want people looking at a race beween HP NonStop and IBM.
When HP took over Compaq, HP also took over the NonStop systems, which remain the only workable threat to IBM's stranglehold on large corporate operational systems. Oracle can provide MIS wankers with eleventy-seven ways to mince a report; but the moneymakers still mostly have their systems of record on DB2, IMS and NoStopSQL/MP boxes.
As Mr . Palmisano alluded, it is fortunate for the Armonk Monster, that no head of HP has had a clue about what to do with Guardian; or how to invest in it's development. This utter cluelessness is perfectly represented by both Compaq and HP management ignoring a Tandem NonStop product (Pathway) perfectly positioned to take on the Internet transaction business, and instead investing in gutting their own architecture to poorly fake Apache on an imitation of Unix.
I will admit to having had sexual intercourse with a number of witty women; so I suppose I must accept the compliment. I'd hazard I know more about what happened between July 7, 1937 and September 2, 1945 than you do.The Germans were at least as awful as the Japanese in that war; yet the entire German nation was not depicted as less than human. So it doesn't have much to do with actual behavior. And neither incineration of enemy civilians, nor the 70,000 or so Frenchmen killed by their liberators, made the Allied nations sub-human. It was a useful racism to despise the Japanese as a people; a useful distinction to parse the difference between Nazis and ordinary Germans. The point I was making was that it was not a very clean war; contrary to what (the poster I replied to) claimed. War is an inherently ghastly business; all the worse when undertaken incompetently.
Assange Not News/WWII Plenty Dirty
First, Assange isn't telling us anything we shouldn't already know about the general course of the war. Anyone who has been paying attention the last seven years finds no surprises. What Assange does do is provide the kind of tactical details that gets people killed.
Second, WWII was not pretty. "The Good Guys" firebombed civillians by the hundreds of thousands. Hiroshima and Nagasaki, not nice. There's some reason to think Churchill let Coventry be destroyed to protect the Ultra secret. There's speculation that Churchill began bombing civilian German targets to suck the Luftwaffe into atacking London in 1940; saving the RAF fields and Chain Home from destruction. Most battlefield atrocities went unreported. Nobody investigated friendly fire incidents, it was bad for morale.The Japanese were painted as sub-human brutes, needing extermination. Propganda and lies were standard. You could look it up. As General Sherman said: "War is sheer cruelty. You cannot refine it".
It's All A Matter Of Money
Application shareware, like packages, only works if you can make your processes easily fit the systems. As a rule, the fewer users a company has, the more it makes sense to go "off the shelf" but as soon as you move up to middle to large sized operations, custom kit makes money sense.
Consider a shop with 500 people all using the same set of "off the shelf" applications. Each worker has a 2-inch thick 3-ring binder with all the manual procedures needed to fudge the systems to fit the process, and calculators to perform the math the system doesn't have the basic functions to handle. (Yes, really.)
Provide them with custom applications to fit their actual jobs, and you only need 200 of those people, which at an averaged burdened cost per position of $100k is an annual recurring savings of 30 million bucks. So if it costs you $5mm to develp, and $1mm per year to maintain, it's still a tidy bit you saved?
A secure OS would be nice. Certainly neither Unix nor Windows can qualify. Guardian and System 360(latest version) would be ok; except everybody runs a Unix partition on them now for web services. It's pretty bleak out there. All that said, I would argue that the more immediate problem is the great open door of web services and IP. Close that aperture and it becomes less critical to fix the rest. It would be nice to return to the days when our biggest fear was a disgruntled Assembler programmer bypassing internal controls.
Complexity Of Implementation Is A Problem
Given the complexity of RFC mash-ups like IPv4 or v6 and it's bloody difficult to "fully understand the implications" of turning it on. RFC 791 was issued nearly 30 years ago and most sysadmins still configure by rote, fingers crossed and praying powerfully. Much less Harry The Homeowner and his Open Zombie Wireless network. You can't fire-proof a paper house. If you want to have a secure network, you need a protocol that is secure by design, not by implementation. Produce a product for general use by the public, and it needs to default to safe settings and not require years of experience to configure safely. Especially when acquiring years of experience could be very painful and expensive. This is just more wanker-ware designed by people with too much time on their hands and no ability to take off those Unix/IP blinders. It would be insanely funny if it weren't so important.
Notice to HP Services Customers- Time To Leave
Cut staff, cut service. It's a pretty simple and proven rule. Time to shop around; although there isnt much competition left; not with IBM Global leading the crash dive race to the bottom.
Time to go back in-house people, it may not be cheaper but at least someone will answer the phone when you call.
It's Hard to Sell The Wrong Engineering
It doesn't matter how great the engineering is if it's the wrong product for the market. I've known a fair number of (now ex) Sun people over the years, and what they all had in common was a focus on products that were really cool and not what the business world needed. One of them once said to me "You know, these business guys drive me crazy. You lose a server in the middle of the day, and they act like it's the end of the world when they have to re-boot".
He didn't understand why I burst out laughing. Given that the Sparcs have no inherent advantages over other Unix capable hardware, there was no way to justify the premium prices Sun demanded. When money got tight, business was cured of that Sun-buying reflex action.
To be clear: Japan declared war on the USA first, in concert with bombing attacks on Pearl Harbor and the Phillipines (then a US colony). If you read the actual December 8, 1941 US declaration by FDR, it simply recognizes that a state of war already exists. Italy and then Germany carried out their treaty obligations to Japan and declared war on the USA on December 11, 1941. The USA then responded to those two declarations. So what's your point?
Brush Up Your CICS and COBOL
To put this in context, back in the early 1980's IBM realized that they faced real competition from DEC, Tandem and Wang. IBM created the PC and promoted client/server as an alternative to moving the database off System 360. It worked, and of those three companies, only Tandem survives in the form of the maimed and minimized NonStop division of HP. IBM always knew that the Unix and Microsoft boxes weren't real competition, and had it not been for Internet porn Sun and Oracle would have died off 10 years ago. IBM's only real competition now is Guardian NonStop running SQL/MP, but HP don't know what they have and are concentrating their resources on OSS and SQL/MX; which are a dead end. Soon, once again Dinosaurs shall rule the earth, and I will need to recall what above the line and below the line means. All Hail The Armonk Monster, The Once and Future King!
A lot of households and smalll offices buy one copy of Windows and then put it on two or three machines.
Keep customers from doing that, and Windows loses some cost advantage.
Those strapped for funds (or innately thrifty) will be more inclined to go to Linux, those with the money to burn will regard Apple more fondly.
Intuit's Turbo Tax, you may recall, shot a huge hole in their market share when they tighened up their piracy controls, and found themselves impelled to loosen up.
This could be yet another demonstration of the old Stock Market axiom: some days a Bull makes money, some days a Bear makes money, but a Pig, well a Pig always loses.
MSFT never were innovators- they have always been a re-packaging and marketing operation. The problem they have now is that people actually need the software to work reliably and consistently, and MSFT are running out of smoke and mirrors.
Yet Another Programming Language.
I once made a list of "programming languagesof the future" I've manged to avoid learning over the years. I think there were 15 of them. The list starts with ALGOL and PL1, continues through Pascal and ADA and ends with Python and Ruby.
Look people, if you're going to keep re-inventing the bloody wheel, at least make it round?
IBM, MSFT, History
MSFT didn't develop NT, they bought it from DEC, which is why NT always ran best on an Alpha chip.
IBM developed the PC because Wang Computers were eating the office automation market. The Armonk Monster did a little market research and realized most of their Selectric customers didn't want to spend the money for a mini-computer, but said customers fantasized a need for office automation. Which is why, despite the fact that it didn't network, IBM sold the original PC as a straight-up Selectric replacement that would automate your office like a Wang. It was all a lie, but it sold. Of course, once you had one PC you had two, and once you had two you wanted Susie and Janie to be able to trade docs back and forth, and is why initially most Network Admins (when networking became available) were typists.
How To Build A Single Point Of Failure
I first ran across the term "orchestration" being applied to IT in the mid-1980's, when IBM was trying to sell their concept of requestor/servor systems. The notion was that you had token ring networks of OS/2 PCs going through a TPF "orchestration layer" to a mix of IMS databases.
The design broke down in much the same way that all later attempts (eg 'web services" have. The orchestrator has to hold all context for a transaction; but cannot maintain simulataneous locks across across the various database systems. You can choose between creating a rich minefield of deadly embrace, or resign yourself to a large number of unresolved transactions.
What generally happens is fake orchestration, where specialized code is built to handle known issues with cross servor transactions at the orchestration layer, but each data base system operates it's function in isolation. If you are willing to abandon concurrency and reliabilty, you can give the appearance of orchestration.
Microsoft- The Devil Or The Deep Blue Sea?
Mivcrosoft's business strategy has been a series of opportunistic scams since the day they sold QDOS to IBM as an operating system. That strategy was always doomed long term; even Bernie Madoff got caught out eventually. The problem MSFT has now is threefold- first, how to backout of their architectural dead-end, second, how to maintain their existing base of users while doing it, and third, how to lock out competing OS from being able to run Windows applications better than Windows? That third concern is much of what drove Win95's design. Windows 3.11 applications ran better on OS2 than on Windows. Win95's abandonment of any modularity or layering put paid to OS2, but at great cost. If MSFT implements a rational OS with distinct and well defined interfaces, then they open themselves up to that level of competition again. If they don't fix their OS, then they continue to have a defective product that fewer and fewer people want to buy. The inertia of monopoly only can take you so far.
Let A Hundred Flowers Bloom, Let A Hundred Schools Of Thought Contend.
Tories in Mao Suits, who knew? Good luck with that.
I can't say how it is Ye Olde And Dampe Mother Country. On this side of the Atlantic my observation is that private companies can enforce the non-disclosure agreements their people sign; while Government entities have real watchdogs.
In other words, if it weren't in the interests of all the stakeholders in a private company to bulldoze over the giant stinking maggot-infested corpses of many of their "strategic projects" I rather doubt the public versus private record would look much different. It's just another tumescent adolescent fantasy of the savage market boys; who read the Clifts Notes on "Wealth of Nations" and got it ass-backwards and upside down.
Fire Resistant House
The old CCITT protocols X.25 and friends would be a good place to start.
If you're doing serious business, the call setup and session mangement made life easier and more secure. Consistent routing, packet checks at every hop, anyone tries to break into
the conversation and the session drops.
TCP/IP is a nightmare for transaction processing in comparison.
Lousy for surfing porn sites though; IP much better for that. So IP won.
The task of developing secure packet switching protocols was mostly done by the CCITT in the 1970's.
Somebody should just give Lockheed a copy of the X.25 and associated standards, and they would be pretty much there.
IP pushed out X.25 because it was free to cheap; and more suited to porn-site surfing, not because it was superior in relaibility, security or speed.
Not Where MSFT Will Really Block Them
it will be more like when you could theoretically run Windows 3.11 on top of DR DOS- except that you really couldn't, because these mysterious incompatibilities started showing up.
Most people never got past the initial "non-fatal error" warnings.
How about "Windows update detects possibly incompatible default browser! Make IE your default browser to be sure to get your essential updates".
"Are you sure your non-standard browser has all it's security patches? Make IE your default browser to secure your system!"
More than one way to keep a monopoly.
Faster Hardware Will Always Be Defeated
Having done my time in systems managment and performance, I always find it touching when I read articles about trying to squeeze the maximum from new fast hardware. It matters not what you do, faster hardware will always be defeated by application programmers (following the latest development method) and customer requirements (for senseless functions they fondly imagine to be "cutting edge".) Got to love the system guys though, they do keep trying..
Monkey See, Monkey Do?
Monkey See, Monkey Do, that's the basic argument for censorship. Given the number of people who can't discern between fact and fancy, I find it harder to dismiss every day. Perhaps there should be some sort of test to authorize you as not a credulous cretin before you can watch, read or listen to certain things. Of course that would put a lot of people out of business. In any case, I'd rather those imitating primates watch consensual cartoon sex than violent theft and murder. And yes, I am thinking of the children.
Seat Belts Don't Help
Seat belts don't help if car seats can break loose with the occupant strapped to it , the roof caves in or the vehicle bursts into flames. You can't just add seat belts to a deathtrap and make it safe. The problem isn't the user. The fundamental structures of the web are the problem. It's meant to be a method of displaying unsecured static documents for collaboration by scientists. It is horribly unfit for most of the uses made of it today. If we wish secure networks, then we need protocols and structures far more like the departed CCITT rules than any of the IP based networks. The people trying to figure out how to secure the Web are beat before they start, and they haven't a clue as to why. But you may as well try to fireproof a paper house.
Permeable By Design
Service Oriented Architectures (mash-ups by any other name) often leave huge holes that are exploited unintentionally by users. Because the services and orchestrators are written to be as context-free and reuseable as possible; they can often be called by naive client programs that don't realize the exposure that results. For example, in a hospital system a client that calls an Admission Discharge and Transfer module to tell Housekeeping and Maintenance which rooms to clean may give unintentional access to Admission Reason, preliminary diagnosis, AIDS. Which maybe you didn't want the janitor knowing?
Infinite Supplies of Hardware In The Sky
Everybody who runs a real business has a real hardware budget, and that budget is not infinite. Every sysadmin who configures an online system needs to configure it for a peak capacity; and throttle requests over that capacity or it won't make money. The big lie of online service bureaus (yes kiddies, that's the 1970's term for Clouded Computing; same concept new clothes) is that two customers can cover peak demand at the same time by occupying the same hardware at the same time. Guess what: that doesn't work. The only way shared resources work is if you can predict demand; the only reliable way to predict demand is if you run only batch or throttle traffic at peak. When I did system performance and configuration, I spent a lot of time making sure that resource hogs didn't knock down other apps. What this does is make it easy for one dumb piece of code to lock up everybody else. One clown can wreck the whole circus......
What Java On The Backend?
The majority of useful backend code I know of is in COBOL. The web server code is Java, but it's functionally a CGI pass-through that calls mainframe services.
Java is mainly use for middleware in much of the world. It's a pretty expensive scripting language for web servers. Use something besides Apache and it's spawn as your context-holding switch, and Jabba mostly goes away.
Maybe they could call it OAK again and use it for cable TV boxes. It's what the language was designed for.
Yes, they don't have much use do they? Neither do database with no hardware to run on.
Every large user of Sun equipment I've seen defaults to Oracle as their database.
My assumption was the main reason for Oracle to buy Sun is to preserve that premium part of their market. There's no money in Java or MySqueal.
If Oracle are selling Sun's hardware assets, then the acquisition looks like sheer idiocy to me.
Bush Hydrogen Highway Was A Fraud
The only reason Mr. Bush funded hydrogen research was so that he could pretend he was doing something constructive while still not disturbing the oil companies. This is not to say that hydrogen has no future as a power source; I really can't speak to that. What I can say is that, given the current art, hydrogen doesn't look practical to me as a personal vehicle power supply. Near term, it's a bust, which is why Mr. Bush was so fond of it.
Sun Goes Out
Been waiting 10 years to use that. Big problem for Oracle; before they could point at the OS or hardware when their products inhaled too many fumes from the fissure, now nowhere else to point the finger. I suppose they figured they had no real choice; without Sun, Oracle's market implodes. Any bets on what happens to MySQL?
Service Bureau Computing
Been there, done that. It's had a lot of different names over the decades, but the basic idea is to sell people more hardware capacity than you have. Which only works if a couple of them don't ask for it at the same time. So it works best with scheduled tasks, aka "Batch". Payroll and other back office functions. Just don't do it with real time transaction processing. Also works best for very small users; larger users generally find no real cost savings, and can get stuck with parasitic providers.
Eat A Bad Rat
We lose a lot of raptors and wild carnivores around here because people put out poison for pigeons and rats. Sun was always a brilliant scam; much like MSFT. Ten years ago I knew a couple of dozen people who worked for Sun; I told them all to sell their stock in 1999; none of them did, and none of them have jobs there anymore. IBM should be careful what carrion it feeds on. Perhaps Vulture Central could kindly offerThe Armonk Monster some expert advice?
Which Only Goes To Show
You-all don't know the real world runs on IBM and NonStop?
Which is what worries me.
Probably A Big Mistake
Not a reality-based world-view from what I've seen. Hope he doesn't try to put Social Security on Sparc servers...
Don't be Too Harsh...
From reading his articles, (I have not read his books) I find that Mr. Friedman suffers from a distorted set of assumptions that are accepted in most circles as common sense. Among these are the notion that a free market is an unregulated one, or that markets are not always artificial creations of entities powerful enough to enforce the market's rules. Heroically pushing his limits, Mr. Friedman is attempting to find a method of avoiding global suicide. If we think of this as an intellectual version of the Special Olympics, then he is indeed a winner.
Bell Labs Was An ARPA Shop...
Bell Labs flourished because (under the Vannevar Bush scheme) they were getting vast sums of Federal dollars. As did PARC Xerox, etc. When the Feds cut funding, they choked and died. Even more immediate, the people who built UNIX had started the effort as part of MULTICS, which was a DOD project, of which Bell had a piece. There are a lot of legends surrounding the birth of UNIX, but as far as I can tell it was not an official project funded by AT&T. UNIX was a bunch of guys at loose ends waiting for the next project who hacked something using software and hardware that had originally been bought for a different task. Not to demean their accomplishment; but it was never intended to be used for anything like what it is used for today.
By the way, MULTICS continued after Bell dropped out, and I hear the source is now in the public domain.
Free to Cheap, and Worth Every Penny
The question not asked is if most businesses would pay for Linux or any other Unix derivative if the actual cost were being recouped via sales? Given the implementation and support costs of Unix derived systems, I suspect that would be a big "no". Like DARPANet, if the development and deployment costs had not been inititially underwritten by those subsisting on government largesse, Unix and Linux would have gone nowhere.
Papering The Cracks?
When Windows95 was in development, IBM OS/2 ran Windows applications better than Windows 3.11. Microsoft chose to so closely integrate their applications and operating system that neither IBM nor anyone else could do that from WIN95 on. The problem with this approach is that you cannot produce a durable OS when applications can invoke each other directly and invade what should be restricted areas of memory. It was only a matter of time until MSFT reached the point where they would either have to deploy severely limited software or build an actual OS that applications run on top of rather than within. It appears they are going for the severely limited option; but at some point they will have to provide something that actually works and scales reliably and is capable of enhancement. I don't think that, as an organization, MSFT has the capacity. Mr. Gates said 10 years ago that if NT5 (later released as WIN2000) wasn't an "enterprise class" operating system; then Microsoft would lose momentum they could never recover. It wasn't , and they haven't. (Interestingly, right after WIN2000 was released is when Mr. Gates began selling larger quantities of stock and backing away from managment of MSFT.) MSFT is moving towards a future where it will be a client display device and game console, and little more.
Outsource The Processing, Outsource The Profit
IT has moved from backroom accounting and reporting to operational systems in just about every line of business. Outsource your operations and you are left with a management shell that has to pay the vendor his profit from yours.
The usual argument is that the outsource vendor can perform the function more efficiently and less expensively. Which the vendor can only accomplish by paying their people less and having less reserve capacity.
Do you really want your mission critical functions being run less qualified staff on bare-bones systems? You don't, so you will end up amending your agreement over time in ways that drive your costs up to where they were before, plus paying the vendor his profit.
Not to mention, once you have committed to an outsource vendor, the cost of breaking that agreement and returning the function inhouse can be prohibitive. It is common in my experience for the first contract to be quite reasonable, and then for the new term contract to be high enough to recoup the vendor loss on the first contract and then some.
"Once you pay the Danegeld, you will never be rid of the Dane." Those considering outsourcing would be wise to consider what became of Ethelred The Unready; (poor Ethered, who took advice from his era's top management consultants).
The only time it makes any sense to outsource a function is if you regard the function as having no possibility of profit, and as a fixed cost of supporting the profitable part of your business.
They'll code it in one of the 'C' derivatives and run it on Unix. Then we let our enemies steal it, and they implode. I'm still convinced the Soviet Union collapsed because they were stealing all our cutting edge software.
Sun Will Go Out
Sun's business model was to take a free to cheap product (unix based systems) tweak it and charge a premium for it. It was always an unsustainable grift; and now the only reason they still survive is habit and association with other products. Oracle users are probably the main reason Sun still is an independent entity; though it is unlikely that Mr. Ellison will ever pick them up. (If Oracle were supplying an integrated solution to customers, then they would have no one to blame for their software.) Sun's new model looks like a desperate attempt to continue to charge for what is being given away by others. In that light, picking up MySQL, legitimising it in many peoples eyes as an alternative to Oracle, makes a certain sense short term. As there is likely no long term for Sun, what really counts is fluffing for immediate returns.
Gets the Point; Then Drops It
The point is, Keep It Simple, Stupid. Java (and all OO) is inherently a complex way to implement most business applications. Most business objects are already abstractions of reality (money, deadlines, interest rates, taxes). Adding another level of abstraction is about as useful as learning to fart the Warsaw Concerto. Which is why you will always see OO examples of classes as something tangible- guns, fruit or books. Try doing payroll, instead, and COBOL suddenly looks very advanced and useful by comparison. Finally, after 26 years of this, my rule of thumb in code reuse for business applications is that if it doesn't substitute for a system routine (e.g. Date or Time) then it probably isn't worth coding as a separate routine or method. Just put inline.
MSFT System Patch Death Spiral?
The System Patch Death Spiral is often experienced in the applications world. (Particularly after repeated bouts of "systems integration" with various "turnkey solutions".) Briefly, it is the condition where your complex and taped-together implementation reaches the point where every fix engenders 1+nx problems; where n is a number greater than zero and x is a positive multiplier varying on just how absurd your assemblage of disparate parts is. Given that MSFT have implemented a system that doesn't know an app from an OS, and much of that implementation is bits screwed together like a poorly integrated set of applications; they may well have begun their downward course.