How does Wikipedia handle topics (like certain forms of proprietary technology) where the only published data sources might only exist in non-public forms (e.g., vendor manuals), or may not exist in published form at all anymore (e.g., out of print vendor manuals)?
Those are the reasons for the "failure" of Linux, OS/2, BeOS, and any number of other alternative operating systems.
Each has its own set of other contributing factors, of course, but the combination in the subject line is more than enough, by itself, to kill any competition.
Folks don't like having to make choices, they're more comfortable sticking what what they already know, and they won't start looking for something else as long as the software they're using works well enough most of the time.
6. BEOS - A competitor in the overcrowded consumer OS market. The Execs tried to push Apple for waaaay more than they were worth, and the rest is history. A history of the triumphant return of Steve Jobs, and Apple riding OS X and the iPod to great success, making BEOS irrelevant.
Overcrowded? When BeOS for the x86 platform was released in 1998, Linux was just starting to be a viable desktop, and OS/2 was already on its way out, so there was really only Windows (9x and NT) competing seriously with BeOS.
Doesn't sound overcrowded to me even if you added MacOS (which ran on different hardware).
My wife and I had Tracfones (nice Nokia models) when I was enemployed a few years ago, and they worked very well. I usually bought a 1-year activation card during one of their double-minutes bonus specials.
Its reception was a **LOT** better than the POS Cingular (excuse me, AT&T) phone I have now (which doesn't get any service at home unless I'm on the 2nd floor).
I spent three years as a senior editor at InfoWorld, and I certainly have a lot of criticisms to offer about the tech trade media industry. But I can say, with absolute certainty, that when trade media outlets like InfoWorld disappear you will all be sorry.
It depends. Tech trade media outlets tend to provide three basic services:
News related to products and the industry.
Product reviews.
Editorial content.
While it's possible that the trace rags are the source for some of the news information we find these days on the web, I think there is little question that items #2 and #3 above are being handled very well by sites like Tom's Hardware, Anandtech, and various and sundry product-specific news a/o blog sites out there.
Yeah, you heard me right. Is the media industry going to shit? Corporate media is on the blame list, for sure. But first on the list is you. Have you ever written your Congressman? Probably not. But even if you have, it's probably futile to ask that you write to your favorite media outlets and ask -- even beg -- them to cover real news, and not just fluff pieces and fake stories.
I spent 15 years writing letters and comments via both paper letters and the provided online forums (I was fairly active in places like InfoWorld Electric before Sandy trashed the place, on Extreme Tech before management replaced the good forum software with a piece of crap, etc.), trying to let publications know as a Mac and OS/2 user (and more recently as an OS/2 and Linux user) that I did not appreciate the Windows-centric nature of most of their articles, and that I did not like their tendency to review inferior software from a few select large vendors instead of also including smaller (but often more capable) solutions from the freeware and shareware worlds.
I got nowhere, and I eventually got sick of it, so I now have ZERO subscriptions to printed tech media. Zero.
Technology media went to shit in the early 1990's. To hell with them.
OS/2's multithreading is certainly on par with anyones, including BeOS. I think a number of folks on Slashdot are simply too young to remember that this sort of technology has been around a little longer then they think it has (as far as I'm concerned the real OS/2 was first released in 1992 (OS/2 2.0) -- all of those 1.x releases were an older 16-bit variant that was less than useful).
It isn't that alternative OSes do things well. It's more like Microsoft's OSes don't even provide a baseline level of functionality. Multithreaded multi-processor OSes are so mid-1960's.:-)
I have heard this argument many times about 'Microsoft breaking OS/2 windows support', some of these updates are known as... Win32s, vxd drivers etc.
Mostly Win32s updates, actually. Windows 3.1 support was almost totally complete in OS/2 2.1 and later due to IBM having the actual source to Windows 3.1 through an agreement with Microsoft (the WinOS2 subsystem is a tweaked and recompiled version of the real Windows 3.1 code), but every few months a Win32s update would be released which changed various aspects of Windows' behavior. Since many software makers decided to use the latest and greatest WIN32S.DLL in their products whether or not they actually used the new features, this presented a moving target to OS/2 users.
IBM kept up with Microsoft's changes for a surprisingly long time, but Win32S 1.30 actually changed the virtual machine size and used very high memory locations by default, breaking support in OS/2.
Microsoft made Windows evolve. Could Microsoft have made 32bit support and a whole new driver framework that would work with OS/2? Well, perhaps, but it would of required investing a lot into a system that wouldn't work that
well.
OS/2 Warp 4 actually has a sizable amount of support for the real 32-bit Win32 API, mainly intended to ease the porting of Windows software to OS/2. The Odin project takes advantage of those libraries (formally called DAX and then DAPIE before finally being called Open32).
It's hard to move anywhere when you have tightly intertwined applications. It's also hard to move software if it talks to a lot of other systems, since each incoming or outgoing datafeed can represent multiple opportunities to shoot yourself in the head, foot, etc.:-(
Separating integrated applications like you describe would be an interesting undertaking, I think. Fortunately, the one we might be porting soon is a standalone app.
There are still some cases where platform tie-in exists, including your situation (apparently), but I suspect those cases are becoming much fewer in number as more and more of those shops have already moved their dated applications to more open platforms.
I work in the airline industry. We happen to use mainframe hardware because it does what we need. In many cases we've moved smaller apps to other platforms, but there's a lot of core stuff that will probably never move off the larger machines. It can't, at least until a viable alternative exists.
I know little about IBM mainframe development practices (I'm a Unisys guy), but sound software development practices are not platform-specific. If we can write modular MASM and F66 code, you guys can write modular COBOL...
I guess I'm not all that familiar with the AS/400's capabilities, so I'll accept your argument. Maybe that server line is similar to the Unisys MCP-powered Clearpath line in that it scales a fair distance on both the high and low ends of the spectrum.
Unisys 2200 mainframes tend to be more focused on fast transaction processing, not batch operations. Not all of us in the mainframe world bleed blue or worship the stunted capabilities and slow-as-molasses development culture that seems to surround IBM's big iron.:-)
A mainframe is very large server hardware that is specially designed for I/O throughput and reliable operation with a high level of recoverability and the ability to cluster efficiently.
It also usually comes with an OS (these days normally VM, z/OS, OS2200, or MCP) which is specialized in various ways to utilize that particular hardware efficiently. Most UNIX variants are quite simplistic in comparison -- they have a simplistic process scheduling and prioritizing model with no real separation of batch, real-time, and interactive tasks (OS2200 places each of those types of tasks into its own range of scheduling priorities), and UNIX also tends to use a fairly course security model instead of a more sophisticated permissions bitmask or equivalent.
VAXen were not mainframes (superminis at best), but had many of the right ideas. IBM z\boxes are mainframes, as are Unisys Clearpath servers, and they are larger than the UNIX boxes you're likely to see.
Supercomputers focus on CPU bandwidth. Mainframes focus on I/O bandwidth. Very different focus.
You typically don't see real "mainframes" outside of large financial institutions, government agencies, and airline operations. Those types of operations tend to have a need for ultra-reliable large-scale systems with very low response times.
One of the reasons is that in many mainframe organisations, it was nearly impossible to start up customer demanded projects.
Sounds like a process/culture issue. In the group I was in at a major airline, we could create a new transaction for someone in the user community and have it up and running in a matter of days or weeks at most, assuming it wasn't very complex. Changes and new features were fast, too, although sometimes funding or available time was an issue.
One of my former bosses told me about this. They wanted something, the CIO of mainframe would stipulate a project cost and time that was not feasible, so many things got cancelled. That is the reason that people switched to PC's.
A standalone solution on a PC with no external support infrastrucute is often far easier to design and implement than a well-supported redundant solution in a more controlled environmment. The support infrastructure required is a large part of the time cost. Without knowing more, it's hard to say who was right in the above situation...
If the mainframe people had more of a hacker culture, where you can start with something small that does the job, and then provided guidance and expertise to provide what users wanted, I think mainframe like environments would have more marketshare.
We do that here, and we did it at my previous employer. Perhaps that's one of the differences between Sperry/Unisys mainframe culture and IBM mainframe culture -- we tend to like small flexible teams of vertical experts, while IBM software development seems bogged down in procedural minutae.
The whole point of a mainframe is to provide a controlled, centralized, efficient, and highly recoverable machine (or a cluster of such machines) on which to perform company-critical tasks.
Some organizations use a mainframe as a virtual server cluster running dozens of virtual machines, while others use the same mainframe hardware as a single large dedicated transaction system.
It all depends on the organization and the specific application.
2200/600 boxes were large and relatively slow. We ran 2200/400's at the Unisys ADSC, which were nicer boxes from what I'm told, and we also ran 2200/500's (CMOS versions of the 2200/900, I think) at NWA, which were also nice boxes at the time. I think we might've had a 2200/600 there as well (a 624, I think).
Transaction systems tend to consist of a resident transaction monitor and dozens (or thousands) of small quick programs that perform individual tasks.
The monitor sees input from the user, determines what that input might be (usually based on the first few characters of the message, called the "transaction code"), and kicks off the program or programs associated with that particular trancode.
The transaction program starts, does its thing, and terminates. In and out, very fast.
A lot of commonly used smaller flat files are kept resident in memory for performance purposes, and each user typically has a memory storage area associated with their sign-in session where programs can temporarily store data related to that specific session. That enables programs to enforce transactions sequences and create directed "conversations" of functions, something which is quite useful when performing complex tasks involving multiple screens.
It's a text-based web, in a way, and it's had 40+ years to be refined (at least in the case of TIP, the Unisys transaction environment I play in).
Thousands of companies also depend on trucks to haul freight, and those trucks might do a very good job at hauling freight in their own context, but that doesn't make those trucks a freight train.:-)
Re:Not to mention things non-mainframes don't atte
on
The Mainframe Still Lives!
·
· Score: 2, Informative
That's news to me, and it would surely surprise my current and multiple former employers (all of which still heavily use either current OS2200 or current MCP mainframes from Unisys).
Slashdot Mirror
That's true. Just because a source isn't widely available doesn't mean it can't be cited. :-)
How does Wikipedia handle topics (like certain forms of proprietary technology) where the only published data sources might only exist in non-public forms (e.g., vendor manuals), or may not exist in published form at all anymore (e.g., out of print vendor manuals)?
Those are the reasons for the "failure" of Linux, OS/2, BeOS, and any number of other alternative operating systems.
Each has its own set of other contributing factors, of course, but the combination in the subject line is more than enough, by itself, to kill any competition.
Folks don't like having to make choices, they're more comfortable sticking what what they already know, and they won't start looking for something else as long as the software they're using works well enough most of the time.
I use Firefox 1.5.x on a PPro/200 with 192MB, and it runs just fine. No memory issues.
Overcrowded? When BeOS for the x86 platform was released in 1998, Linux was just starting to be a viable desktop, and OS/2 was already on its way out, so there was really only Windows (9x and NT) competing seriously with BeOS.
Doesn't sound overcrowded to me even if you added MacOS (which ran on different hardware).
My wife and I had Tracfones (nice Nokia models) when I was enemployed a few years ago, and they worked very well. I usually bought a 1-year activation card during one of their double-minutes bonus specials.
Its reception was a **LOT** better than the POS Cingular (excuse me, AT&T) phone I have now (which doesn't get any service at home unless I'm on the 2nd floor).
It depends. Tech trade media outlets tend to provide three basic services:
- News related to products and the industry.
- Product reviews.
- Editorial content.
While it's possible that the trace rags are the source for some of the news information we find these days on the web, I think there is little question that items #2 and #3 above are being handled very well by sites like Tom's Hardware, Anandtech, and various and sundry product-specific news a/o blog sites out there.I spent 15 years writing letters and comments via both paper letters and the provided online forums (I was fairly active in places like InfoWorld Electric before Sandy trashed the place, on Extreme Tech before management replaced the good forum software with a piece of crap, etc.), trying to let publications know as a Mac and OS/2 user (and more recently as an OS/2 and Linux user) that I did not appreciate the Windows-centric nature of most of their articles, and that I did not like their tendency to review inferior software from a few select large vendors instead of also including smaller (but often more capable) solutions from the freeware and shareware worlds.
I got nowhere, and I eventually got sick of it, so I now have ZERO subscriptions to printed tech media. Zero.
Technology media went to shit in the early 1990's. To hell with them.
OS/2's multithreading is certainly on par with anyones, including BeOS. I think a number of folks on Slashdot are simply too young to remember that this sort of technology has been around a little longer then they think it has (as far as I'm concerned the real OS/2 was first released in 1992 (OS/2 2.0) -- all of those 1.x releases were an older 16-bit variant that was less than useful).
:-)
It isn't that alternative OSes do things well. It's more like Microsoft's OSes don't even provide a baseline level of functionality. Multithreaded multi-processor OSes are so mid-1960's.
Mostly Win32s updates, actually. Windows 3.1 support was almost totally complete in OS/2 2.1 and later due to IBM having the actual source to Windows 3.1 through an agreement with Microsoft (the WinOS2 subsystem is a tweaked and recompiled version of the real Windows 3.1 code), but every few months a Win32s update would be released which changed various aspects of Windows' behavior. Since many software makers decided to use the latest and greatest WIN32S.DLL in their products whether or not they actually used the new features, this presented a moving target to OS/2 users.
IBM kept up with Microsoft's changes for a surprisingly long time, but Win32S 1.30 actually changed the virtual machine size and used very high memory locations by default, breaking support in OS/2.
OS/2 Warp 4 actually has a sizable amount of support for the real 32-bit Win32 API, mainly intended to ease the porting of Windows software to OS/2. The Odin project takes advantage of those libraries (formally called DAX and then DAPIE before finally being called Open32).
What does the GPL have to do with usage? It's a source license.
It's hard to move anywhere when you have tightly intertwined applications. It's also hard to move software if it talks to a lot of other systems, since each incoming or outgoing datafeed can represent multiple opportunities to shoot yourself in the head, foot, etc. :-(
Separating integrated applications like you describe would be an interesting undertaking, I think. Fortunately, the one we might be porting soon is a standalone app.
There are still some cases where platform tie-in exists, including your situation (apparently), but I suspect those cases are becoming much fewer in number as more and more of those shops have already moved their dated applications to more open platforms.
I work in the airline industry. We happen to use mainframe hardware because it does what we need. In many cases we've moved smaller apps to other platforms, but there's a lot of core stuff that will probably never move off the larger machines. It can't, at least until a viable alternative exists.
Try writing your code in a modular manner. :-)
I know little about IBM mainframe development practices (I'm a Unisys guy), but sound software development practices are not platform-specific. If we can write modular MASM and F66 code, you guys can write modular COBOL...
I guess I'm not all that familiar with the AS/400's capabilities, so I'll accept your argument. Maybe that server line is similar to the Unisys MCP-powered Clearpath line in that it scales a fair distance on both the high and low ends of the spectrum.
Unisys 2200 mainframes tend to be more focused on fast transaction processing, not batch operations. Not all of us in the mainframe world bleed blue or worship the stunted capabilities and slow-as-molasses development culture that seems to surround IBM's big iron. :-)
A mainframe is very large server hardware that is specially designed for I/O throughput and reliable operation with a high level of recoverability and the ability to cluster efficiently.
It also usually comes with an OS (these days normally VM, z/OS, OS2200, or MCP) which is specialized in various ways to utilize that particular hardware efficiently. Most UNIX variants are quite simplistic in comparison -- they have a simplistic process scheduling and prioritizing model with no real separation of batch, real-time, and interactive tasks (OS2200 places each of those types of tasks into its own range of scheduling priorities), and UNIX also tends to use a fairly course security model instead of a more sophisticated permissions bitmask or equivalent.
VAXen were not mainframes (superminis at best), but had many of the right ideas. IBM z\boxes are mainframes, as are Unisys Clearpath servers, and they are larger than the UNIX boxes you're likely to see.
Supercomputers focus on CPU bandwidth. Mainframes focus on I/O bandwidth. Very different focus.
You typically don't see real "mainframes" outside of large financial institutions, government agencies, and airline operations. Those types of operations tend to have a need for ultra-reliable large-scale systems with very low response times.
Sounds like a process/culture issue. In the group I was in at a major airline, we could create a new transaction for someone in the user community and have it up and running in a matter of days or weeks at most, assuming it wasn't very complex. Changes and new features were fast, too, although sometimes funding or available time was an issue.
A standalone solution on a PC with no external support infrastrucute is often far easier to design and implement than a well-supported redundant solution in a more controlled environmment. The support infrastructure required is a large part of the time cost. Without knowing more, it's hard to say who was right in the above situation...
We do that here, and we did it at my previous employer. Perhaps that's one of the differences between Sperry/Unisys mainframe culture and IBM mainframe culture -- we tend to like small flexible teams of vertical experts, while IBM software development seems bogged down in procedural minutae.
The whole point of a mainframe is to provide a controlled, centralized, efficient, and highly recoverable machine (or a cluster of such machines) on which to perform company-critical tasks.
Some organizations use a mainframe as a virtual server cluster running dozens of virtual machines, while others use the same mainframe hardware as a single large dedicated transaction system.
It all depends on the organization and the specific application.
2200/600 boxes were large and relatively slow. We ran 2200/400's at the Unisys ADSC, which were nicer boxes from what I'm told, and we also ran 2200/500's (CMOS versions of the 2200/900, I think) at NWA, which were also nice boxes at the time. I think we might've had a 2200/600 there as well (a 624, I think).
I think it's a bit of both.
Transaction systems tend to consist of a resident transaction monitor and dozens (or thousands) of small quick programs that perform individual tasks.
The monitor sees input from the user, determines what that input might be (usually based on the first few characters of the message, called the "transaction code"), and kicks off the program or programs associated with that particular trancode.
The transaction program starts, does its thing, and terminates. In and out, very fast.
A lot of commonly used smaller flat files are kept resident in memory for performance purposes, and each user typically has a memory storage area associated with their sign-in session where programs can temporarily store data related to that specific session. That enables programs to enforce transactions sequences and create directed "conversations" of functions, something which is quite useful when performing complex tasks involving multiple screens.
It's a text-based web, in a way, and it's had 40+ years to be refined (at least in the case of TIP, the Unisys transaction environment I play in).
We always used to call it Imperialism By Marketing.
Thousands of companies also depend on trucks to haul freight, and those trucks might do a very good job at hauling freight in their own context, but that doesn't make those trucks a freight train. :-)
That's news to me, and it would surely surprise my current and multiple former employers (all of which still heavily use either current OS2200 or current MCP mainframes from Unisys).
The Burroughs MCP is Tron MCP's friendly old granddaddy. :-)
Blind faith in the FSF? :-)
I know I wouldn't do it, but it seems many software authors have. It's their call, of course.