Companies which are either headquartered there, were formed there, or had a huge presence there in the 1960's include 3M, Honeywell, ERA/UNIVAC/Sperry/Unisys, Control Data, Cray, etc.
The book _A Few Good Men From UNIVAC_ by David E. Lundstrom describes some of the happenings in the Twin Cities during that time period.
That depends on the certification processes in place for the software in question. In some industries, getting a patch certified is a 6-to-18-month process.
It's amazing how thorough application testing can be when you've had 10 or 15 years to develop a set of automated regression scripts, when the design of the application is modular, and when the basic environment in which the application is running has been relatively static.
All of those things are true in some mainframe environments. The Unisys 2200 EXEC, for example, is largely unchanged (from an application program's perspective) since the late 1960's. That removes a lot of variables related to the external environment that a Windows or Linux developer has to take into account, making the testing process a lot simpler.
Combine the above with a decent QA process and competent developers, and you can greatly reduce the number of bugs present in even very large/complex products on a mainframe.
You are failing to differentiate between known defects and unknown defects. Release with the former can be controlled to a large extent. The latter are inevitable in any complex system (as you say).
Defects in a product are inevitable. However, KNOWN defects are a different thing altogether.
In three different positions where I've written software for internal corporate consumption, I've never released code into production with known defects, and I don't see why the fact that a program happens to be shrinkwrapped should make any difference. Our stuff is millions of LOC also, and I'll bet our development times are shorter than most shrinkwrapped software vendors.
A lot of it comes down to (1) experience and (2) the use of effective processes.
When I worked at then Unisys Airline Center in the early 1990's, the defect count for the product we were working on (USAS*CGO, an air cargo airwaybill processing application) had to be down in the single digits before a new version of the product was released, and we delayed the release of USAS*CGO 11R2 for several weeks until that goal was accomplished.
Customers were also made aware of the outstanding issues, but in our case all customers also had the source code to the application (mainframe software in the airline industry worked a little but differently) so the relationship was a little closer than the typical developer/user relationship for shrinkwrapped software.
Except with the gazillon of different Linux distribution - featuring each different versions and alternative applications How the hell can you reach a *mono* culture ?
Given the mass disk imaging techniques currently in use at many corporate sites in lieu of traditional installations, and given the ability for Linux sysadmins to lock down end user boxes so that only the central admins could install software, I could certainly see a "monoculture" being a very real possibility at a given site even when running Linux in a corporate context.
Now, whether or not that monoculture represents the same kind of risk that a Windows monoculture does is a different question.:-) But there is still some risk.
I use the DOS version of F-Prot under OS/2. It detects a wide variety of Windows viruses and macro viruses, and I simply embed it in a batch file called UNZ.BAT which I use to unzip all f the ZIP files I download. Presto -- auto-scanning.:-)
Linux is a kernel, but the GNU runtime is equally worthless without such a kernel, and both are not as useful as a desktop OS without X, window managers, and various other things that are not provided by either party. The fact of the matter is, both Linux (the kernel) and GNU are important elements, but they are not the only important elements, and they might not even be the MOST important elements by some peoples' measures.
I think the whole "GNU/Linux" argument is asinine. Linux distros were called "Linux" back when I first booted SLS 0.98, and Stallman didn't care then, or if he did he wasn't saying anything. His place in history is ensured. So why engage in a purely semantic argument?
That includes various single-diskette distros as well. I always pull out the old Coyote Linux as a prime example. It uses busybox and uClibc, NOT the GNU equivalents....or are we being deliberately slow today?
On a related note: I would say that roughly 25% of the companies out there impose some sort of limit on the format that one can use when submitting a resume or a cover letter.
Some of them had a policy of only accepting resumes through their web site's fill-in form, meaning that a prospective employee had to fit his or her resume information into the format that the company had hard-coded into their web site. Some of those web sites only provided fairly small editing areas for each item (63 characters or less in at least one case I can remember), and some of them made no provision for cover letters at all.
Thankfully, there were also a number of well-designed web sites out there which either allowed attachments (so one could submit a preformatted cover letter and sometimes resume in PDF, RTF, ASCII, or DOC format), or which had flexible input fields which were large enough to hold the information and would also retain any formatted you wanted to use.
I tried to get around web web site on many occasions when it seemed on the surface that it was a hard requirement, contacting HR and asking if there was an address I could send a paper cover and resume letter to, and some companies were quitie receptive to that.
However, a surprising number of companies would ONLY accept resumes through their web site. No paper resumes were being considered, and that fact was stressed to me over the phone.
Thankfully, a certain percentage of companies were a bit old-fashioned and still accepted paper resumes sent via US Mail, and a few even required them and provided no electronic options, but those two groups represented well under half of the positions I dealt with.
That was over a year ago now, and I'm willing to bet the number of companies which accept traditional paper resumes is shrinking, not growing.
Some games have so many mods these days that I question whether or not it's even POSSIBLE to thoroughly experience them all. Quake 1, for example, covered everything from aircraft combat (via AirQuake) to Rally racing (via QuakeRally) to highly team-oriented stuff with multiple classes (TF) to very different multiclass deathmatch variants (FvF and/or GENClasses).
I still get a kick out of playing certain levels in Doom Legacy, actually.:-)
That's a very good question. That occurred to me on several occasions, as I'm sure it would to anyone who was running into an apparently endless series of stone walls.
Here's what I did. I ran a half-dozen versions of my typical resume and cover letters (ones which I had actually used to apply to positions) past a number of folks I know at various times during my period of joblessness. Two of them were hiring managers (not hiring techie folks at that time, unfortunately), and most of the others were working at headhunter or contracting firms and evaluated resumes as part of their jobs.
They liked my cover letters and attached custom resumes for the most part. FWIW, my initial resume was written while going through a local job placement firm's "job search preparation" course, and the instructor there asked for a copy of my first attempt at a resume to include with her examples for future classes.:-)
I typically used a "T-letter" format for the cover letter -- two sets of parallel bullet points that showed requirements for the published position on one side and my qualfications for each on the other.
In any case -- I got a lot of feedback over time and made adjustments, sometimes focusing a resume on specific technical stuff (e.g., my experience with SQL and relational databases), and sometimes glossing over tool specifics completely and stressing the nature of the products/processes I had used which were similar to those required for the position, and the resumes I was tossing out near the end was somewhat different from what I started with.
Sometimes I received conflicting opinions, too. Resume writing isn't an exact science by any means, and some folks will immediately reject something that another considers stellar.
It's possible those were an issue, but I also used a couple of formats that were written by other people, and those didn't work either. Who knows?
Vanilla X *runs* just fine at my house on several different PPro/200 systems with 4MB Matrox Milleniums. Remember those? The systems have 12MB VooDoo2 cards, also, but I don't use those cards with X.
I use XFree86 under various Linux distros, XFree86/2 under OS/2, and both HobLink X11 and Hummingbird eXceed under OS/2. Also MI/X under Windows 95.
All of them are quite fast on the above hardware.
Now, some window managers and desktop environment can slow things down a tad...
I've been there for quite a while.:-) No spyware, no viruses, and you can still use your trusty Firefox, Thunderbird, and (soon) OpenOffice 2.x as well.
Of course, if you want to do much else you have to be a little creative. But sometimes that can be fun. If you have the inclination and the time, anyway.
Too bad Lotus WordPro (formerly Samna Ami and then Samna Ami Pro) isn't available for Linux yet. It's a very nice word processor in its own right. Might run under Wine, though.
The freedom to fork the Linux kernel has resulted in varieties of Linux running on all sorts of platforms, including many that that the mainstream kernel development team has absolutely no interest in.
That's the beauty of being able to fork the code -- people can use it as the basis for scratching their own itch.
The freedom to fork Linux distributions has resulted in something that most markets identify as "competition", something which the x86 desktop OS market hasn't seen in some time.
In spite of Sun's touching concerns, this can actually be a healthy situation, and usually is.
Heh. The sign-on screen of the OS2200 box I'm playing on right now says "Exec Level 47R2A", so what does version numbering say about the maturity of mainframe OSes?:-)
Slashdot Mirror
Companies which are either headquartered there, were formed there, or had a huge presence there in the 1960's include 3M, Honeywell, ERA/UNIVAC/Sperry/Unisys, Control Data, Cray, etc.
The book _A Few Good Men From UNIVAC_ by David E. Lundstrom describes some of the happenings in the Twin Cities during that time period.
That depends on the certification processes in place for the software in question. In some industries, getting a patch certified is a 6-to-18-month process.
It's amazing how thorough application testing can be when you've had 10 or 15 years to develop a set of automated regression scripts, when the design of the application is modular, and when the basic environment in which the application is running has been relatively static.
All of those things are true in some mainframe environments. The Unisys 2200 EXEC, for example, is largely unchanged (from an application program's perspective) since the late 1960's. That removes a lot of variables related to the external environment that a Windows or Linux developer has to take into account, making the testing process a lot simpler.
Combine the above with a decent QA process and competent developers, and you can greatly reduce the number of bugs present in even very large/complex products on a mainframe.
You are failing to differentiate between known defects and unknown defects. Release with the former can be controlled to a large extent. The latter are inevitable in any complex system (as you say).
Defects in a product are inevitable. However, KNOWN defects are a different thing altogether.
In three different positions where I've written software for internal corporate consumption, I've never released code into production with known defects, and I don't see why the fact that a program happens to be shrinkwrapped should make any difference. Our stuff is millions of LOC also, and I'll bet our development times are shorter than most shrinkwrapped software vendors.
A lot of it comes down to (1) experience and (2) the use of effective processes.
When I worked at then Unisys Airline Center in the early 1990's, the defect count for the product we were working on (USAS*CGO, an air cargo airwaybill processing application) had to be down in the single digits before a new version of the product was released, and we delayed the release of USAS*CGO 11R2 for several weeks until that goal was accomplished.
Customers were also made aware of the outstanding issues, but in our case all customers also had the source code to the application (mainframe software in the airline industry worked a little but differently) so the relationship was a little closer than the typical developer/user relationship for shrinkwrapped software.
Given the mass disk imaging techniques currently in use at many corporate sites in lieu of traditional installations, and given the ability for Linux sysadmins to lock down end user boxes so that only the central admins could install software, I could certainly see a "monoculture" being a very real possibility at a given site even when running Linux in a corporate context.
Now, whether or not that monoculture represents the same kind of risk that a Windows monoculture does is a different question. :-) But there is still some risk.
Ah. It seems the FAQ is a lot more reasonable than the statements I tend to see being made by "GNU/Linux" proponents.
Thanks!
I use the DOS version of F-Prot under OS/2. It detects a wide variety of Windows viruses and macro viruses, and I simply embed it in a batch file called UNZ.BAT which I use to unzip all f the ZIP files I download. Presto -- auto-scanning. :-)
No, he (and others) mainly make the sweeping assertion that *all* Linux distros should be called GNU/Linux, and that is a false assertion IMSNSNhO.
:-)
If you want to qualify it further, I'll probably still disgree, but it's a more reasonable position to take.
Sorry... I meant it in jest, but forgot the smiley. :-) :-(
I agree completely.
Linux is a kernel, but the GNU runtime is equally worthless without such a kernel, and both are not as useful as a desktop OS without X, window managers, and various other things that are not provided by either party. The fact of the matter is, both Linux (the kernel) and GNU are important elements, but they are not the only important elements, and they might not even be the MOST important elements by some peoples' measures.
I think the whole "GNU/Linux" argument is asinine. Linux distros were called "Linux" back when I first booted SLS 0.98, and Stallman didn't care then, or if he did he wasn't saying anything. His place in history is ensured. So why engage in a purely semantic argument?
That includes various single-diskette distros as well. I always pull out the old Coyote Linux as a prime example. It uses busybox and uClibc, NOT the GNU equivalents. ...or are we being deliberately slow today?
By that measure, shouldn't FreeBSD be a GNU/BSD distro?
What Stallman calls GNU/Linux is what *some* Linux distributions distribute.
On the embedded side, there are more and more distro which are using replacements for the GNU tookchain and glibc like busybox and uClibc, thus avoiding many of the GNU tools you typically see in a Linux distro.
Stallman's generalization is mostly true, but not always true...
On a related note: I would say that roughly 25% of the companies out there impose some sort of limit on the format that one can use when submitting a resume or a cover letter.
Some of them had a policy of only accepting resumes through their web site's fill-in form, meaning that a prospective employee had to fit his or her resume information into the format that the company had hard-coded into their web site. Some of those web sites only provided fairly small editing areas for each item (63 characters or less in at least one case I can remember), and some of them made no provision for cover letters at all.
Thankfully, there were also a number of well-designed web sites out there which either allowed attachments (so one could submit a preformatted cover letter and sometimes resume in PDF, RTF, ASCII, or DOC format), or which had flexible input fields which were large enough to hold the information and would also retain any formatted you wanted to use.
I tried to get around web web site on many occasions when it seemed on the surface that it was a hard requirement, contacting HR and asking if there was an address I could send a paper cover and resume letter to, and some companies were quitie receptive to that.
However, a surprising number of companies would ONLY accept resumes through their web site. No paper resumes were being considered, and that fact was stressed to me over the phone.
Thankfully, a certain percentage of companies were a bit old-fashioned and still accepted paper resumes sent via US Mail, and a few even required them and provided no electronic options, but those two groups represented well under half of the positions I dealt with.
That was over a year ago now, and I'm willing to bet the number of companies which accept traditional paper resumes is shrinking, not growing.
Depends entirely on the game and the player.
:-)
Some games have so many mods these days that I question whether or not it's even POSSIBLE to thoroughly experience them all. Quake 1, for example, covered everything from aircraft combat (via AirQuake) to Rally racing (via QuakeRally) to highly team-oriented stuff with multiple classes (TF) to very different multiclass deathmatch variants (FvF and/or GENClasses).
I still get a kick out of playing certain levels in Doom Legacy, actually.
That's a very good question. That occurred to me on several occasions, as I'm sure it would to anyone who was running into an apparently endless series of stone walls.
:-)
Here's what I did. I ran a half-dozen versions of my typical resume and cover letters (ones which I had actually used to apply to positions) past a number of folks I know at various times during my period of joblessness. Two of them were hiring managers (not hiring techie folks at that time, unfortunately), and most of the others were working at headhunter or contracting firms and evaluated resumes as part of their jobs.
They liked my cover letters and attached custom resumes for the most part. FWIW, my initial resume was written while going through a local job placement firm's "job search preparation" course, and the instructor there asked for a copy of my first attempt at a resume to include with her examples for future classes.
I typically used a "T-letter" format for the cover letter -- two sets of parallel bullet points that showed requirements for the published position on one side and my qualfications for each on the other.
In any case -- I got a lot of feedback over time and made adjustments, sometimes focusing a resume on specific technical stuff (e.g., my experience with SQL and relational databases), and sometimes glossing over tool specifics completely and stressing the nature of the products/processes I had used which were similar to those required for the position, and the resumes I was tossing out near the end was somewhat different from what I started with.
Sometimes I received conflicting opinions, too. Resume writing isn't an exact science by any means, and some folks will immediately reject something that another considers stellar.
It's possible those were an issue, but I also used a couple of formats that were written by other people, and those didn't work either. Who knows?
I can accept that. :-)
Vanilla X *runs* just fine at my house on several different PPro/200 systems with 4MB Matrox Milleniums. Remember those? The systems have 12MB VooDoo2 cards, also, but I don't use those cards with X.
I use XFree86 under various Linux distros, XFree86/2 under OS/2, and both HobLink X11 and Hummingbird eXceed under OS/2. Also MI/X under Windows 95.
All of them are quite fast on the above hardware.
Now, some window managers and desktop environment can slow things down a tad...
If you say so...
I've been there for quite a while. :-) No spyware, no viruses, and you can still use your trusty Firefox, Thunderbird, and (soon) OpenOffice 2.x as well.
Of course, if you want to do much else you have to be a little creative. But sometimes that can be fun. If you have the inclination and the time, anyway.
Too bad Lotus WordPro (formerly Samna Ami and then Samna Ami Pro) isn't available for Linux yet. It's a very nice word processor in its own right. Might run under Wine, though.
The freedom to fork the Linux kernel has resulted in varieties of Linux running on all sorts of platforms, including many that that the mainstream kernel development team has absolutely no interest in.
That's the beauty of being able to fork the code -- people can use it as the basis for scratching their own itch.
The freedom to fork Linux distributions has resulted in something that most markets identify as "competition", something which the x86 desktop OS market hasn't seen in some time.
In spite of Sun's touching concerns, this can actually be a healthy situation, and usually is.
Heh. The sign-on screen of the OS2200 box I'm playing on right now says "Exec Level 47R2A", so what does version numbering say about the maturity of mainframe OSes? :-)