He did what he was supposed to do. He inadvertantly collected information on innocent people and then destroyed it upon recognition. That's what is supposed to happen to protect our rights.
No, what was supposed to happen, as pointed out in the SF Gate article, was that the data should have been retained for judicial review, as part of normal oversight procedures:
Henry Perritt, who led a team authorized by the FBI to review the surveillance system, said he was surprised the technician deleted the e-mails.
"The collection is supposed to be retained for judicial review," Perritt said. "If an agent simply deleted a whole bunch of files without the court instructing, that's not the way it's supposed to work."
Morever, all this talk about backups or method of deletion doesn't matter. Even if that data is still somewhere, it can't be used (legally, that is). It was collected in an illegal manner and the innocent people are not under investigation. You don't go out of your way to resurrect data that you can't do anything with
You're right, you don't. Instead, you go out of your way to delete data that would point to criminal activity on your own point - such as violating the terms of a search warrant.
The guy goofed. What's nice to read is that he was upset about collecting information on innocent Americans, and that he deleted it. I would have been more upset if he did something with the information.
You should have read the entire article. It turns out that what the agent should have done, and should already have been trained to do was to preserve all the intercepted communications, suspend operations, and contact the appropriate authorities for review of the event. Instead, just like many criminals, he knowingly destroyed the evidence, thus impeding proper investigation and followup.
My son is a diabetic. He takes insulin several times every day to survive until the next, and has done so for 19 years. Today his insulin is produced by (horrors!) recombinant DNA production. 19 years ago it was produced by extraction from the pancreas of beef-cattle and pigs. I thank God regularly for scientists and researchers who refuse to accept the status quo or the blindness of those who will not see.
The same idiots that oppose the research and animal testing that produced the substances that keep my son alive are today opposing the stem-cell research that holds out the best promise for a genuine cure to his disease in his shortened lifetime. PETA, Bush, the assorted Churches and the right-wing demagogues should all be faced with the daily decision of whether their infant son should live or die for their principles. They'd soon find themselves more receptive to scientific advances and to other people's reasons for opposing them.
Go read the article - the research was performed from 1999 to 2001, which means that it was mostly before Bush took his wishy-washy "stand" on stem-cell research, and indeed might even have been over by that point. Not to mention that the lab in question originated two of the approved stem-cell lines!
If you're at NIU, you've got two excellent mainframe scholars available for your questions. Go hunt down Dr. Robert Rannie or Micheal Stack. Neither one of them will support your "consensus" of 120MIPS total for 16 engines. Try over 10 times that number.
The mainframe instruction set also contains incredibly complex instructions, which are microcoded.
For example, the Move String (MVST) and Compare Logical String (CLST) instructions are the Standard C library functions strcpy() and strcmp() respectively.
Memory bandwidth is very high as has been mentioned, but it's also multiported, multiplying the bandwidth.
Not to mention up to 12-way SMP, with complete cache consistency!
Why are folks getting so wired about this situation? Most geeks have entire bookshelves full of non-Free, copywritten, non-redistributable, non-updatable documentation, for which they paid in sum thousands of dollars. And they did so happily. So why the concern about the electronic equivalents?
There is a difference between installing from source and straight binaries? Not really. Source install is a two step process. The first step is to compile binaries. Thats it.
Nope. The first step is to succesfully compile binaries. That's it. Unfortunately, all too often there's more to that step than "./configure && make install". There's writing patches because nobody else has compiled this release of the package for platform X before. There's reconciling conflicts with standard libraries and include files. There's figuring out what changed since GCC 2.x such that the package won't compile with your compiler. There's installing the C compiler! Etc. The reason binary RPMs are so popular is that someone who knows how to do this stuff does the heavy lifting, and the rest of the crowd just installs the resulting binaries.
Would you rather buy a Checker Marathon or try to assemble one from parts gathered from assorted manufacturers and hope it goes together right?
When you've predetermined the product to be bid on, you change the RFP process completely. In some environments (governments, many universities, etc.) you actually invalidate the RFP altogether and open yourself to legal challenges by providers of competing products. But assuming you're allowed to do so, how do you force the bid to get you the specific stuff you want normally?
When outfitting an office of 7,000 managers and 3,000 geeks, do you send out an RFP for 10,000 copies of MS-Windows, 10,000 copies of MS-Outlook, 7,000 copies of MS-Office and 3,000 copies of MS-Visio and wait for Best Buy, CompUSA, jOeZZZZ WareZ, and Uncle Guido's Drive-by Software Truck to respond, then take the best offer? Do you call Microsoft and say "What's the discount on this, so I can get Purchase Order cut?"? Do you buy 1 copy of each from petty cash and install it everywhere?
Whatever you do when you want a specific product and no additional services makes just as much sense for open-source software. Either way, you're probably focusing on the lowest-cost distributor of a commodity, because you've taken all the other bid-evaluation criteria off the table.
Likewise, whatever you do when you want a specific product to be customized for your use makes just as much sense for customized versions of open-source "products". In this case, you're probably focusing on the service-delivery aspect, because except for really big RFPs, big software vendors don't customize their products. So you're going to compare reputations and track records of the responding consultants and contractors, in addition to the cost.
All in all, just do what you always do when you want a fixed response to the RFP.
This seems a bit like asking what it would take to replace the current way of driving a car (steering wheel, gas and pedal brakes, etc.) with something better. But the interface between humans and automobiles is pretty much a solved problem, and nobody seems to spend much time speculating on what a paradigm change in automobile control would be like.
Oh yeah? Two words: cruise control. It completely redefined the "car interface". How about two more: intermittent wipers. True, the inventor got shafted by Detroit and had to fight tooth and nail for years to get his due, but he too changed the "car interface" dramatically.
There's a curious assumption which I've seen repeatedly-- namely, that a paradigm shift in human/computer interaction would be a good thing. Why, exactly?
Simple: because the quantum increase in computer access that was engendered by the WIMP interface isn't by any stretch of the imagination the endpoint of interface evolution. Want an example? Don Hopkins has been pushing his concept of Pie Menus for about 15 years now, and has implemented them everywhere he can find an amenable display system (starting with (*shudder*) X10 and including MS-Windows!). If you think you know how user interfaces should work and you haven't read any of Don's exhortations on the human-factors improvements inherent in non-linear menus, you need to get with the program.
I do have a serious ergonomic bone to pick wrt emacs, anything that makes me use CTRL, ALT, and/or ESC frequently is going to give me hand cramps real quick becuase of the distance those keys are from the alphanumeric ones (i mean finger distance, not whole-arm-movement distance).
About 20 years ago, when we didn't have mice on Unixoid systems, and therefore didn't know to complain about Carpal Tunnel Syndrome and Thoracic Outlet pain (informally "mouse shoulder"), everyone whined about having "emacs pinky". You could always tell the Unix geeks at the Comp Sci parties - their Vulcan-style pinky-swung-wide-over greeting spoke volumes (usually "No, I don't have a date. Ever.").
In those days we counted ourselves lucky to have intelligent ASCII terminals like the Wyses, TeleVideos and ADM3-As that could do more than just write characters at the bottom of the screen, and the predominant editor was something called "tvedit" (Yup, Don Lancaster's "TV Typewriter" inspired lots of us!). I distinctly remember one professor refusing to switch to emacs until he could get foot-pedals for CTL and ALT - he even got the EE Dept. to cobble up an experiment for him! Too bad it didn't catch on.
Pipes seem necessarily linked to the command line.
IBM's VM/CMS mainframe interactive system has only rudimentary windows and no icons, mice or pointers at all, but it makes up for the lack in spades: It has pipes on steroids. The more complicated examples of multistream "pipelines" require at least three dimensions to render graphically, so we don't bother doing so. But years ago, Chuck Boeheim at the Stanford Linear Accelerator Center wrote a two-dimensional pipeline animator called PipeDemo. Each "stage" of the pipeline (i.e. each program in a bash pipe) is displayed on a single line of the screen, and the data flows from stage to stage at a rate slow enough to observe. It's the moral equivalent of an IDE debugger, but for pipes.
The only way I could see doing similar in a GUI would be to have an "alternate view" window where each program would have however many appropriate pipe fittings on their icon where input and output pipes (hoses?) could be joined until your screen resembles a game of pipes.
Inspired by Chuck's work with PipeDemo, I've started several times on a graphical pipe builder similar to what you suggest. I've never gotten far enough though, due to time constraints. At its core lives a printed-circuit-board routing program that sees every pipeline stage as an integrated circuit with a specific pin-out. Whenever asked to, it re-rationalizes the display to make the "traces" look clean and to minimize the number of "layers" required to implement the "PCB".
I remember once when one of the teachers was having problems with her telephone and decided to pull out the RJ-11 patch cable since it looked the same and use it as a phone line to see if that was the problem (it wasn't).
A guy I used to work with had something he called "Ron's Rule of Connectors":
If you
can plug two things together, you may plug them together.
He started seriously ranting when keyboards started coming out with RJ-11 plugs. A guy in the electrical shop responded by wiring up a 3-prong 120VAC power cord with an RJ-11 jack for him!
The point, of course, is that there's a reason the National Electrical Code specifies a different kind of connector for every different use. The big honking Type 1 Token Ring plugs are never mistaken for anything else, and never wind up being plugged into the wrong place.
Anybody who ever fried a laptop modem by jacking into a hotel's digital phone system understands the issue.
Of course, then IBM went and screwed it all up by creating 16Mb TR and the resulting problems from having 4Mb and 16Mb stations on the same ring!
I certainly did not ask it to generate ring errors when I put the card into promiscuous mode.
Back In The Day, when only IBM, Proteon, and Novell were building Token Ring hardware, getting your hands on a NIC that would do promiscuous mode was not easy. It was specifically intended that stations not be able to turn into packet sniffers, because the stations of the time weren't up to the workload of recording every packet that flew by. And unlike promiscuous Ethernet NICs (which we all used with the good old MIT PC-TCP package), when the TR NIC doesn't keep up, don't nobody keep up.
Linux/390 was developed behind closed doors at IBM, while Linux/370 was an open development effort by Linas Vespas and crew. Linux/390's beta was released, finally, while Linux/370's still in beta.
Almost correct. The Linux/370 "Bigfoot" project is effectively dead, and has been almost since the day IBM revealed their Linux/390 project.
The reason? Lots more people wanting something for their S/390s, than wanting something to play around with on superannuated i370s.
Sorry, but that's not how it happened. What happened was that IBM had software engineers who had far greater resources to apply to the task at hand. Linas Vepstas and the "Bigfoot" folks were making great headway - they actually had the kernel booting almost cleanly when IBM spoke up. We voted with our feet, and began running the only system that was fully functional as fast as we could get our hot little hands on it. That system happened to be Linux/390.
The IBM mainframe user community has always seen the danger in forked development. We tend to support the variations of projects that have the best hope of success. When your community is as small as ours is, everybody benefits from a unified stand. "Bigfoot" had some good ideas that I really miss, and I work on Linux/390 all day every day. At a minimum, Linux/370 was poised to be one of the few platforms not succeptible to the classic C buffer-overrun failure, by the simple expedient of making the stack grow up from the bottom as God and Knuth intended.
Ergo, Open Source isn't necessarily the same as open development - but without Linas Vespas and Linux/370, no one in IBM would've considered playing around with Linux on the S/390
Again, untrue, although the public record doesn't support my claim. The stories passed along orally at SHARE meetings etc. report that IBM's effort began simply because a well-placed IBMer wanted to do it. If you talk to some of the Linux/370 "Bigfoot" folks, you'll hear that they learned of IBM's work long before it was revealed, and that they deliberately provoked IBM to open up. What is certain is that without Linas Vepstas and the Bigfoot crew, the coders in IBM's Boerblingen lab would likely never have been able to get Linux/390 out of the lab.
It's kind of interesting, since management overhead is widely regarded as the main reason why people prefer Windoze systems to Linux systems. People believe that it costs less money to perform essential administration tasks in Windows than it does in Linux.
No, you missed the implied "business lingo" rule - this is a TCO study, not a technical analysis. "Management overhead" in that context is the cost of Pointy Haired Bosses, their Administrative Aides, the mailroom, etc.. What you call "management overhead" the report calls "support" - sysadmins, etc. The other tip-off should have been the reference to depreciation - only business-types pay attention to how much of your hardware value has to be written off on your balance sheet every year!
My company (PACCAR) employs well over 20,000, but we are all spread out across the nation, the majority being in the Seattle area.
My company (Computer Associates, Inc.) has roughly 20,000 staff spread all over the world. All the mail servers (MS Exchange) for the US are located in Islandia, NY. In a centralized-IT environment, that's not uncommon. We're also a network-based company - you can't do much of anything without a connection to the corporate network. So of course we've got bandwidth coming out the wazoo. It works just fine.
The second performance result is the low development time. This can be accounted for by the fact that Lisp has a much faster debug cycle than C, C++ or Java. The compilation model for most languages is based on the idea of a compilation unit, usually a file.
More importantly, Lisp is not "file oriented". In Lisp, a function is a function is a function - you don't have the complex mess of static/public/private/whatever.
Of course, Lisp is also write-only, like Forth and APL.
I'll be impressed when I see mainframes running Exchange.
Aw, now, why would you want to go and do that to a nice mainframe?:-) If you really want to "run Exchange" on a mainframe, give Bynari a call. They've ported TradeServer to Linux/390. So yes, you can move your MS-Outlook users to Linux/390-based email. Today! Just ask Winnebago - they're doing it.
Even worse: Jan Vincent and George Peppard!
on
Lord of Light
·
· Score: 1
The horrid "Damnation Alley" movie starred Jan Vincent as "Hell Tanner", perhaps the worst casting since one of the early Stephen King movies (try "Salems Lot" and (shudder) "Return To Salems Lot" to see REAL bad casting).
Does this mean the Cylons will be running the trains in Hartsfield Atlanta International Airport again? The poor robot doodz have been retired since the 1996 Olympics, when the were replaced by "clearer, friendlier and effective voice[s]"
So why wasn't this interesting when Scott Courtney wrote about it at LinuxPlanet two weeks ago? Suddenly a press release comes out and it's interesting? Hey folks, go over and read Scott's article - it hasn't been sanitized by Corporate Communications types, and it's still positive!
2001-05-09 03:21:40 IBM Provides Open-Access Linux/390 Playground (articles,news) (rejected)
Trust me, they are slow machines. On a good day, a brand new, 16 processor S/390 is a 120 MIPS machine. Each individual processor is only 7.5 MIPS.
Hogwash! On the brand new zSeries 900 machines, each processor exceeds your paltry 120 MIPS number. And we get up to 16 of those in a single array.
Heck, even the poor, beknighted half-Intel/half-S/390 "P/390" systems clock in at almost 7 MIPS, and everyone in the mainframe business knows those are only interesting to cash-challenged 1-or-2-man ISV shops. Running production work on anything that slow is disheartening.
Slashdot Mirror
No, what was supposed to happen, as pointed out in the SF Gate article, was that the data should have been retained for judicial review, as part of normal oversight procedures:
Morever, all this talk about backups or method of deletion doesn't matter. Even if that data is still somewhere, it can't be used (legally, that is). It was collected in an illegal manner and the innocent people are not under investigation. You don't go out of your way to resurrect data that you can't do anything with
You're right, you don't. Instead, you go out of your way to delete data that would point to criminal activity on your own point - such as violating the terms of a search warrant.
The guy goofed. What's nice to read is that he was upset about collecting information on innocent Americans, and that he deleted it. I would have been more upset if he did something with the information.
You should have read the entire article. It turns out that what the agent should have done, and should already have been trained to do was to preserve all the intercepted communications, suspend operations, and contact the appropriate authorities for review of the event. Instead, just like many criminals, he knowingly destroyed the evidence, thus impeding proper investigation and followup.
My son is a diabetic. He takes insulin several times every day to survive until the next, and has done so for 19 years. Today his insulin is produced by (horrors!) recombinant DNA production. 19 years ago it was produced by extraction from the pancreas of beef-cattle and pigs. I thank God regularly for scientists and researchers who refuse to accept the status quo or the blindness of those who will not see.
The same idiots that oppose the research and animal testing that produced the substances that keep my son alive are today opposing the stem-cell research that holds out the best promise for a genuine cure to his disease in his shortened lifetime. PETA, Bush, the assorted Churches and the right-wing demagogues should all be faced with the daily decision of whether their infant son should live or die for their principles. They'd soon find themselves more receptive to scientific advances and to other people's reasons for opposing them.
Go read the article - the research was performed from 1999 to 2001, which means that it was mostly before Bush took his wishy-washy "stand" on stem-cell research, and indeed might even have been over by that point. Not to mention that the lab in question originated two of the approved stem-cell lines!
That's all folks!
If you're at NIU, you've got two excellent mainframe scholars available for your questions. Go hunt down Dr. Robert Rannie or Micheal Stack. Neither one of them will support your "consensus" of 120MIPS total for 16 engines. Try over 10 times that number.
The mainframe instruction set also contains incredibly complex instructions, which are microcoded.
For example, the Move String (MVST) and Compare Logical String (CLST) instructions are the Standard C library functions strcpy() and strcmp() respectively.
Memory bandwidth is very high as has been mentioned, but it's also multiported, multiplying the bandwidth.
Not to mention up to 12-way SMP, with complete cache consistency!
Why are folks getting so wired about this situation? Most geeks have entire bookshelves full of non-Free, copywritten, non-redistributable, non-updatable documentation, for which they paid in sum thousands of dollars. And they did so happily. So why the concern about the electronic equivalents?
According to the bondholders' motion, the typical @Home user charge is $46.00, of which @Home only sees $16 - the cable company keeps the other $30.
There is a difference between installing from source and straight binaries? Not really. Source install is a two step process. The first step is to compile binaries. Thats it.
Nope. The first step is to succesfully compile binaries. That's it. Unfortunately, all too often there's more to that step than "./configure && make install". There's writing patches because nobody else has compiled this release of the package for platform X before. There's reconciling conflicts with standard libraries and include files. There's figuring out what changed since GCC 2.x such that the package won't compile with your compiler. There's installing the C compiler! Etc. The reason binary RPMs are so popular is that someone who knows how to do this stuff does the heavy lifting, and the rest of the crowd just installs the resulting binaries.
Would you rather buy a Checker Marathon or try to assemble one from parts gathered from assorted manufacturers and hope it goes together right?
When you've predetermined the product to be bid on, you change the RFP process completely. In some environments (governments, many universities, etc.) you actually invalidate the RFP altogether and open yourself to legal challenges by providers of competing products. But assuming you're allowed to do so, how do you force the bid to get you the specific stuff you want normally?
When outfitting an office of 7,000 managers and 3,000 geeks, do you send out an RFP for 10,000 copies of MS-Windows, 10,000 copies of MS-Outlook, 7,000 copies of MS-Office and 3,000 copies of MS-Visio and wait for Best Buy, CompUSA, jOeZZZZ WareZ, and Uncle Guido's Drive-by Software Truck to respond, then take the best offer? Do you call Microsoft and say "What's the discount on this, so I can get Purchase Order cut?"? Do you buy 1 copy of each from petty cash and install it everywhere?
Whatever you do when you want a specific product and no additional services makes just as much sense for open-source software. Either way, you're probably focusing on the lowest-cost distributor of a commodity, because you've taken all the other bid-evaluation criteria off the table.
Likewise, whatever you do when you want a specific product to be customized for your use makes just as much sense for customized versions of open-source "products". In this case, you're probably focusing on the service-delivery aspect, because except for really big RFPs, big software vendors don't customize their products. So you're going to compare reputations and track records of the responding consultants and contractors, in addition to the cost.
All in all, just do what you always do when you want a fixed response to the RFP.
This seems a bit like asking what it would take to replace the current way of driving a car (steering wheel, gas and pedal brakes, etc.) with something better. But the interface between humans and automobiles is pretty much a solved problem, and nobody seems to spend much time speculating on what a paradigm change in automobile control would be like.
Oh yeah? Two words: cruise control. It completely redefined the "car interface". How about two more: intermittent wipers. True, the inventor got shafted by Detroit and had to fight tooth and nail for years to get his due, but he too changed the "car interface" dramatically.
There's a curious assumption which I've seen repeatedly-- namely, that a paradigm shift in human/computer interaction would be a good thing. Why, exactly?
Simple: because the quantum increase in computer access that was engendered by the WIMP interface isn't by any stretch of the imagination the endpoint of interface evolution. Want an example? Don Hopkins has been pushing his concept of Pie Menus for about 15 years now, and has implemented them everywhere he can find an amenable display system (starting with (*shudder*) X10 and including MS-Windows!). If you think you know how user interfaces should work and you haven't read any of Don's exhortations on the human-factors improvements inherent in non-linear menus, you need to get with the program.
I do have a serious ergonomic bone to pick wrt emacs, anything that makes me use CTRL, ALT, and/or ESC frequently is going to give me hand cramps real quick becuase of the distance those keys are from the alphanumeric ones (i mean finger distance, not whole-arm-movement distance).
About 20 years ago, when we didn't have mice on Unixoid systems, and therefore didn't know to complain about Carpal Tunnel Syndrome and Thoracic Outlet pain (informally "mouse shoulder"), everyone whined about having "emacs pinky". You could always tell the Unix geeks at the Comp Sci parties - their Vulcan-style pinky-swung-wide-over greeting spoke volumes (usually "No, I don't have a date. Ever.").
In those days we counted ourselves lucky to have intelligent ASCII terminals like the Wyses, TeleVideos and ADM3-As that could do more than just write characters at the bottom of the screen, and the predominant editor was something called "tvedit" (Yup, Don Lancaster's "TV Typewriter" inspired lots of us!). I distinctly remember one professor refusing to switch to emacs until he could get foot-pedals for CTL and ALT - he even got the EE Dept. to cobble up an experiment for him! Too bad it didn't catch on.
Pipes seem necessarily linked to the command line.
IBM's VM/CMS mainframe interactive system has only rudimentary windows and no icons, mice or pointers at all, but it makes up for the lack in spades: It has pipes on steroids. The more complicated examples of multistream "pipelines" require at least three dimensions to render graphically, so we don't bother doing so. But years ago, Chuck Boeheim at the Stanford Linear Accelerator Center wrote a two-dimensional pipeline animator called PipeDemo. Each "stage" of the pipeline (i.e. each program in a bash pipe) is displayed on a single line of the screen, and the data flows from stage to stage at a rate slow enough to observe. It's the moral equivalent of an IDE debugger, but for pipes.
The only way I could see doing similar in a GUI would be to have an "alternate view" window where each program would have however many appropriate pipe fittings on their icon where input and output pipes (hoses?) could be joined until your screen resembles a game of pipes.
Inspired by Chuck's work with PipeDemo, I've started several times on a graphical pipe builder similar to what you suggest. I've never gotten far enough though, due to time constraints. At its core lives a printed-circuit-board routing program that sees every pipeline stage as an integrated circuit with a specific pin-out. Whenever asked to, it re-rationalizes the display to make the "traces" look clean and to minimize the number of "layers" required to implement the "PCB".
I remember once when one of the teachers was having problems with her telephone and decided to pull out the RJ-11 patch cable since it looked the same and use it as a phone line to see if that was the problem (it wasn't).
A guy I used to work with had something he called "Ron's Rule of Connectors":
He started seriously ranting when keyboards started coming out with RJ-11 plugs. A guy in the electrical shop responded by wiring up a 3-prong 120VAC power cord with an RJ-11 jack for him!The point, of course, is that there's a reason the National Electrical Code specifies a different kind of connector for every different use. The big honking Type 1 Token Ring plugs are never mistaken for anything else, and never wind up being plugged into the wrong place. Anybody who ever fried a laptop modem by jacking into a hotel's digital phone system understands the issue.
Of course, then IBM went and screwed it all up by creating 16Mb TR and the resulting problems from having 4Mb and 16Mb stations on the same ring!
I certainly did not ask it to generate ring errors when I put the card into promiscuous mode.
Back In The Day, when only IBM, Proteon, and Novell were building Token Ring hardware, getting your hands on a NIC that would do promiscuous mode was not easy. It was specifically intended that stations not be able to turn into packet sniffers, because the stations of the time weren't up to the workload of recording every packet that flew by. And unlike promiscuous Ethernet NICs (which we all used with the good old MIT PC-TCP package), when the TR NIC doesn't keep up, don't nobody keep up.
Linux/390 was developed behind closed doors at IBM, while Linux/370 was an open development effort by Linas Vespas and crew. Linux/390's beta was released, finally, while Linux/370's still in beta.
Almost correct. The Linux/370 "Bigfoot" project is effectively dead, and has been almost since the day IBM revealed their Linux/390 project.
The reason? Lots more people wanting something for their S/390s, than wanting something to play around with on superannuated i370s.
Sorry, but that's not how it happened. What happened was that IBM had software engineers who had far greater resources to apply to the task at hand. Linas Vepstas and the "Bigfoot" folks were making great headway - they actually had the kernel booting almost cleanly when IBM spoke up. We voted with our feet, and began running the only system that was fully functional as fast as we could get our hot little hands on it. That system happened to be Linux/390.
The IBM mainframe user community has always seen the danger in forked development. We tend to support the variations of projects that have the best hope of success. When your community is as small as ours is, everybody benefits from a unified stand. "Bigfoot" had some good ideas that I really miss, and I work on Linux/390 all day every day. At a minimum, Linux/370 was poised to be one of the few platforms not succeptible to the classic C buffer-overrun failure, by the simple expedient of making the stack grow up from the bottom as God and Knuth intended.
Ergo, Open Source isn't necessarily the same as open development - but without Linas Vespas and Linux/370, no one in IBM would've considered playing around with Linux on the S/390
Again, untrue, although the public record doesn't support my claim. The stories passed along orally at SHARE meetings etc. report that IBM's effort began simply because a well-placed IBMer wanted to do it. If you talk to some of the Linux/370 "Bigfoot" folks, you'll hear that they learned of IBM's work long before it was revealed, and that they deliberately provoked IBM to open up. What is certain is that without Linas Vepstas and the Bigfoot crew, the coders in IBM's Boerblingen lab would likely never have been able to get Linux/390 out of the lab.
It's kind of interesting, since management overhead is widely regarded as the main reason why people prefer Windoze systems to Linux systems. People believe that it costs less money to perform essential administration tasks in Windows than it does in Linux.
No, you missed the implied "business lingo" rule - this is a TCO study, not a technical analysis. "Management overhead" in that context is the cost of Pointy Haired Bosses, their Administrative Aides, the mailroom, etc.. What you call "management overhead" the report calls "support" - sysadmins, etc. The other tip-off should have been the reference to depreciation - only business-types pay attention to how much of your hardware value has to be written off on your balance sheet every year!My company (PACCAR) employs well over 20,000, but we are all spread out across the nation, the majority being in the Seattle area.
My company (Computer Associates, Inc.) has roughly 20,000 staff spread all over the world. All the mail servers (MS Exchange) for the US are located in Islandia, NY. In a centralized-IT environment, that's not uncommon. We're also a network-based company - you can't do much of anything without a connection to the corporate network. So of course we've got bandwidth coming out the wazoo. It works just fine.
The second performance result is the low development time. This can be accounted for by the fact that Lisp has a much faster debug cycle than C, C++ or Java. The compilation model for most languages is based on the idea of a compilation unit, usually a file.
More importantly, Lisp is not "file oriented". In Lisp, a function is a function is a function - you don't have the complex mess of static/public/private/whatever.
Of course, Lisp is also write-only, like Forth and APL.
I'll be impressed when I see mainframes running Exchange.
Aw, now, why would you want to go and do that to a nice mainframe? :-) If you really want to "run Exchange" on a mainframe, give Bynari a call. They've ported TradeServer to Linux/390. So yes, you can move your MS-Outlook users to Linux/390-based email. Today! Just ask Winnebago - they're doing it.
The horrid "Damnation Alley" movie starred Jan Vincent as "Hell Tanner", perhaps the worst casting since one of the early Stephen King movies (try "Salems Lot" and (shudder) "Return To Salems Lot" to see REAL bad casting).
KEWL!!!
Does this mean the Cylons will be running the trains in Hartsfield Atlanta International Airport again? The poor robot doodz have been retired since the 1996 Olympics, when the were replaced by "clearer, friendlier and effective voice[s]"
Long live the Imperious Leader!
So why wasn't this interesting when Scott Courtney wrote about it at LinuxPlanet two weeks ago? Suddenly a press release comes out and it's interesting? Hey folks, go over and read Scott's article - it hasn't been sanitized by Corporate Communications types, and it's still positive!
2001-05-09 03:21:40 IBM Provides Open-Access Linux/390 Playground (articles,news) (rejected)
Trust me, they are slow machines. On a good day, a brand new, 16 processor S/390 is a 120 MIPS machine. Each individual processor is only 7.5 MIPS.
Hogwash! On the brand new zSeries 900 machines, each processor exceeds your paltry 120 MIPS number. And we get up to 16 of those in a single array.
Heck, even the poor, beknighted half-Intel/half-S/390 "P/390" systems clock in at almost 7 MIPS, and everyone in the mainframe business knows those are only interesting to cash-challenged 1-or-2-man ISV shops. Running production work on anything that slow is disheartening.