Backup to harddrives are the way to go, but mirroring is not a complete solution. How many slave drives do you have? If you deleted a file a week ago and find just find out today do you have a way to recover it?
But, in his reality, the machine that is sucking IP in is the Unix licensing agreement and SCO's theory of derivative works. It's hard to believe that these guys even listen to themselves.
You mean Jeremy Paxman: questioning deemed 'too intrusive'? Heise is taking part in a mammoth business scam. His legal theories have been called "moonshine" by a professor of law at Columbia University (granted, he's the FSF's counsel, but lawyers don't tend to be that rude without cause). Intrusive questioning is called for. Him leaving the interview in a huff would be a fine ending.
What questions would you ask that are not so loaded and got some real information on any of those subjects?
Nonsense. Interviews where the interviewee gets to review the questions in advance and decide what to answer are not journalism, they're public relations.
Did you learn anything new from that interview or did you just hear more of the same old spin? If you wanted to learn something more, what are the questions you would ask?
That interview was full of softball questions. What are the questions I would ask?
The Open Source community has shown pretty definitively that the source code you displayed was not stolen. Was that your best shot and if not, show me your best shot now, not under NDA.
Your theory of a derivative work is really stretching. Would you please tell me why you think that JFS is a derivative work of Unix? Under a theory that makes JFS a derivative work, aren't you saying that all Unix device drivers are also derivative works? What are the limits to your theory of derivative works?
SCO insiders have been dumping a lot of stock lately. Why aren't your execs holding onto what should become a vastly more valuable commodity?
I'm sure others can add a bunch more hard hitting questions. The interview was a fluff piece at best.
Did you read the article? That was point 2. Point 1 was that it's ancient, historic code that was released by Caldera (now calling themselves SCO) into the public domain and it was in BSD which has already been shown (legally) to not be derivative of AT&T Unix.
My favorite came from the time that a box was needed to put a prototype board into. One of the engineers made a trip to the hardware store and found a battery operated radio controlled doorbell. The case was just the right size. Afterwards the guts of the thing was still lying around so afterhours the ceiling tiles in a VP's office were lifted and the bell was placed in there. The button went to the bulletin board along with a sign reading "Press Me". So, naturally, it got pressed. A LOT. The VP being your typical PHB type never could figure out where the door bell noise was coming from. And he couldn't put two and two together as he was seen, in the lunch room, vigorously pushing the button and asking "What does this do?"
The piece de resistance was when the engineer in question had a meeting in the VP's office. He took the button off the board and kept it in his pocket, pressing it at appropriate times during the meeting.
So, what is the real win on vector operations? When I was first learning about vector architectures in the late 80's, at first I thought that the advantage the vector processor brought was that it crunched the whole vector simultaneously. I was very disappointed when I discovered that the majority of implementations had a max of 4 arithmetic units.
As part of my learning experience I was tasked with writing a simulator for our next generation processor so we could start fudging benchmarks early:-). What I learned is that the win for vectors (unless modern units have a boatload more processing units) is that the memory I/O is much faster into and out of the registers, there is no loop overhead and accessing the registers by the arithmetic units is very fast.
When I was at FPS we were discussing an i860 based array co-processor. I wonder if anyone has thought of building a vector unit around a set of Pentium or PowerPC chips? They could emulate vector instructions with the registers being held in a shared cache. With proper coding there would be no need for interlocking and the "registers" (emulated by the cache) should be able to blow data in and out of an interleaved memory system as fast as any regular vector unit would.
Yes, but....did you notice that the NEC machine is 5120 processors? It's massively parallel too.
The key, though, is development $$. And development $$ requires either big sales $$ or big $$ from government.
Cray, in 1994, probably one of their better years, had revenues of $920 million and spent $140 million on R&D. Cray was always the best funded of the supercomputer companies, however when you're trying to develop fast silicon $140 million does not go far.
The E10000 is a Celerity product. Celerity was an independent Unix box maker back in the 80's with their own processor architecture. Celerity went bust trying to bring a "minisupercomputer" version of the architecture to market in about 1987 (33 MHz, whoo hoo!). The assets and technology of Celerity along with the design team in San Diego were acquired by Floating Point Systems (FPS). FPS brought the system to market and made the transition to a SPARC based architecture (66 MHz) before going bust. The assets and technology of FPS along with the design team in San Diego and now the manufacturing team in Beaverton were acquired by Cray. Cray did a couple of turns of the crank on the FPS product and sold it as a "business supercomputer". When Cray was acquired by SGI, SGI wanted no part of the SPARC business and sold (yes, again) the San Diego design team (and I think the Beaverton group) to Sun who finally brought a SUCCESSFUL product to market with the E10000.
But it's still the same core team down in San Diego, so I like to think of the E10000 as being a Celerity product.
The trick is keeping ahead of the commodity guys
on
Time For A Cray Comeback?
·
· Score: 5, Interesting
Supercomputing per se died because Intel, DEC, IBM/Motorola had a lot more money to throw at speeding things up than the supercomputing community.
In the 70's up until the early 90's it was possible to build a custom CPU out of discrete logic that ran significantly faster than the available microprocessors. Cray was able to push their clock cycle down into the nanosecond range through clever design. However, a 1ns clock rate == 1GHz. You can go buy that multi-million dollar CPU for a couple of hundred bucks in today's market.
In order for superocmputing to be viable you have to be able to provide quantum leap performance above the commodity hardware AND keep your cost/performance ratio in line as well.
The CRAY-1 came out with a clock speed of about 80 MHz and vector processing and high memory bandwidth at a time when mainstream systems like the PDP 11/70 were running at about 7MHz with a 1MB/s memory bus. Microprocessors weren't even't a joke compared with the Cray.
The new Japanese NEC supercomputer came with a price tag of about $160 million if I remember correctly (some estimates say that it took $1G in research funding) and hits 35 TFlops (sustained). #3 on the Top 500 supercomputers list is a Beowulf cluster with 2304 processors coming in at 7.6 TFlops (sustained). Even figuring $2000/processor + interconnect, that puts the Beowulf cluster at around $5 million or 1/32 of the cost for 1/5th of the performance (roughly speaking).
There are other factors, of course, but the key is that for the supercomputer to stay ahead of the microprocessor a boatload of funding is needed for the supercomputer and the payoff just isn't really there. If it was a lot more supercomputer companies would still be in business.
Well, you just answered the question - "Why go to college?" People who don't go to college do not get salaried office positions. Instead, their career choices often involve the phrase "Would you like fries with that" and attendance and punctuality ARE important if they don't want to wind up IN A TRAILER DOWN BY THE RIVER.
if you're worried about how much resources are consumed in making aluminum. Besides, most (and I mean MOST - not necessarily the best) bicycles are made out of steel.
There actually was one place in the world at least that had 10,000 users on AppleTalk - Apple! Yah, it was all one big happy AppleTalk network when I was there. It worked, too.
Ha, you think you had it bad? Back when I was in college, after trudging through 2 miles of snow (ok, sand - I went to UCSD) we had to "hand compile" our Ada code into Pascal because the Prof's super special Ada compiler used to crash the VAX (this was 1987, I think). We all gave up and just made the Pascal work and then "disassembled" it into Ada. What a waste of time.
Re:This is a lot of work - have you read the LGPL?
on
LGPL is Viral for Java
·
· Score: 1
Well, if you have to jump through all these hoops in Java you would have to jump through those same hoops in any other language and I don't see anyone arguing that.
The GPL license only comes into play when you DISTRIBUTE software. If your customers are asking you for internal solutions, the GPL will not affect them at all and I think you would do the OpenSource community (and yourself) a favor by explaining that to them rather than making a complex piece of code and getting them worried about GPL infringement.
Forget about people dumpster diving - trash cans get spilled and bags get ripped. Do you want your bank statement blowing down the street?
Re:This is a lot of work - have you read the LGPL?
on
LGPL is Viral for Java
·
· Score: 1
The author of the article is retarded. If you read section 6 and find yourself terribly confused (because it makes no mention of anything the would seem to make the LGPL worse for Java than any other language), you should reply labeled "Misleading article" by timsuth, which is a model of clarity and explains the situation fully.
In order to make a buffer between GPL and proprietary code, just make an LGPL'd library and forget about it. You'll have to make the source of the LGPL'd library available but it'll be a pretty thin facade. Or quite trying to steal other people's software and write your own if you want to sell it.
WordPad, bundled with Windows (at least it's in Win2K, I don't have an XP box to check) will open basic Word documents just fine. I'm still waiting for my Panther CD's so I can't check the limits of TextEdit.
So, OS X will now have some basic functionality built into it that Windows does. That's good, but I don't think it's the end of MS Office.
Ummmm...why are you doing all this work? The LGPL is not viral - if you link/import/include what have you to an LGPL library your code does not "become LGPL". What does happen, though, is that you have an obligation to provide the source code to the LGPL'd library that you included. Going through all these acrobatics doesn't change anything - you STILL have to provide the sources to the LGPL'd library.
Well, then you're carrying the metal matrix along with you (adding weight) and it's probably not possible to get the matrix to release hydrogen fast enough for rocket engines - the amount of fuel they gulp is amazing.
Didn't you seen Moonraker? That bad guy Drax hijacked the shuttle and blew up the 747 carrying it. They couldn't afford a new one so it was back to the old drawing board.
The Mac ROMs were reverse-engineered long ago using a white-box approach - the publicly available API descriptions from Inside Macintosh were used to get a start and then they just messed with it until it worked. There was a Mac-on-Unix emulator, damn, I've forgotten the name, but it came out around 1990. Apple killed it the old-fashioned way - they bought it, circa 1996. I think portions of it made their way into the Blue Box.
Apple doesn't license MacOS to OEMs. That's how they keep people from making Mac clones. Most people want to buy a machine with an OS, not a bare box and then have to schlep over to the Apple Store to buy OS X.
Apple does not have a monopoly on the desktop market. MS does. It's a whole different ball game.
Slashdot Mirror
Backup to harddrives are the way to go, but mirroring is not a complete solution. How many slave drives do you have? If you deleted a file a week ago and find just find out today do you have a way to recover it?
But, in his reality, the machine that is sucking IP in is the Unix licensing agreement and SCO's theory of derivative works. It's hard to believe that these guys even listen to themselves.
You mean Jeremy Paxman: questioning deemed 'too intrusive'? Heise is taking part in a mammoth business scam. His legal theories have been called "moonshine" by a professor of law at Columbia University (granted, he's the FSF's counsel, but lawyers don't tend to be that rude without cause). Intrusive questioning is called for. Him leaving the interview in a huff would be a fine ending.
What questions would you ask that are not so loaded and got some real information on any of those subjects?
Nonsense. Interviews where the interviewee gets to review the questions in advance and decide what to answer are not journalism, they're public relations.
Did you learn anything new from that interview or did you just hear more of the same old spin? If you wanted to learn something more, what are the questions you would ask?
That interview was full of softball questions. What are the questions I would ask?
The Open Source community has shown pretty definitively that the source code you displayed was not stolen. Was that your best shot and if not, show me your best shot now, not under NDA.
Your theory of a derivative work is really stretching. Would you please tell me why you think that JFS is a derivative work of Unix? Under a theory that makes JFS a derivative work, aren't you saying that all Unix device drivers are also derivative works? What are the limits to your theory of derivative works?
SCO insiders have been dumping a lot of stock lately. Why aren't your execs holding onto what should become a vastly more valuable commodity?
I'm sure others can add a bunch more hard hitting questions. The interview was a fluff piece at best.
Did you read the article? That was point 2. Point 1 was that it's ancient, historic code that was released by Caldera (now calling themselves SCO) into the public domain and it was in BSD which has already been shown (legally) to not be derivative of AT&T Unix.
My favorite came from the time that a box was needed to put a prototype board into. One of the engineers made a trip to the hardware store and found a battery operated radio controlled doorbell. The case was just the right size. Afterwards the guts of the thing was still lying around so afterhours the ceiling tiles in a VP's office were lifted and the bell was placed in there. The button went to the bulletin board along with a sign reading "Press Me". So, naturally, it got pressed. A LOT. The VP being your typical PHB type never could figure out where the door bell noise was coming from. And he couldn't put two and two together as he was seen, in the lunch room, vigorously pushing the button and asking "What does this do?"
The piece de resistance was when the engineer in question had a meeting in the VP's office. He took the button off the board and kept it in his pocket, pressing it at appropriate times during the meeting.
So, what is the real win on vector operations? When I was first learning about vector architectures in the late 80's, at first I thought that the advantage the vector processor brought was that it crunched the whole vector simultaneously. I was very disappointed when I discovered that the majority of implementations had a max of 4 arithmetic units.
:-). What I learned is that the win for vectors (unless modern units have a boatload more processing units) is that the memory I/O is much faster into and out of the registers, there is no loop overhead and accessing the registers by the arithmetic units is very fast.
As part of my learning experience I was tasked with writing a simulator for our next generation processor so we could start fudging benchmarks early
When I was at FPS we were discussing an i860 based array co-processor. I wonder if anyone has thought of building a vector unit around a set of Pentium or PowerPC chips? They could emulate vector instructions with the registers being held in a shared cache. With proper coding there would be no need for interlocking and the "registers" (emulated by the cache) should be able to blow data in and out of an interleaved memory system as fast as any regular vector unit would.
Yes, but....did you notice that the NEC machine is 5120 processors? It's massively parallel too.
The key, though, is development $$. And development $$ requires either big sales $$ or big $$ from government.
Cray, in 1994, probably one of their better years, had revenues of $920 million and spent $140 million on R&D. Cray was always the best funded of the supercomputer companies, however when you're trying to develop fast silicon $140 million does not go far.
The E10000 is a Celerity product. Celerity was an independent Unix box maker back in the 80's with their own processor architecture. Celerity went bust trying to bring a "minisupercomputer" version of the architecture to market in about 1987 (33 MHz, whoo hoo!). The assets and technology of Celerity along with the design team in San Diego were acquired by Floating Point Systems (FPS). FPS brought the system to market and made the transition to a SPARC based architecture (66 MHz) before going bust. The assets and technology of FPS along with the design team in San Diego and now the manufacturing team in Beaverton were acquired by Cray. Cray did a couple of turns of the crank on the FPS product and sold it as a "business supercomputer". When Cray was acquired by SGI, SGI wanted no part of the SPARC business and sold (yes, again) the San Diego design team (and I think the Beaverton group) to Sun who finally brought a SUCCESSFUL product to market with the E10000.
But it's still the same core team down in San Diego, so I like to think of the E10000 as being a Celerity product.
Supercomputing per se died because Intel, DEC, IBM/Motorola had a lot more money to throw at speeding things up than the supercomputing community.
In the 70's up until the early 90's it was possible to build a custom CPU out of discrete logic that ran significantly faster than the available microprocessors. Cray was able to push their clock cycle down into the nanosecond range through clever design. However, a 1ns clock rate == 1GHz. You can go buy that multi-million dollar CPU for a couple of hundred bucks in today's market.
In order for superocmputing to be viable you have to be able to provide quantum leap performance above the commodity hardware AND keep your cost/performance ratio in line as well.
The CRAY-1 came out with a clock speed of about 80 MHz and vector processing and high memory bandwidth at a time when mainstream systems like the PDP 11/70 were running at about 7MHz with a 1MB/s memory bus. Microprocessors weren't even't a joke compared with the Cray.
The new Japanese NEC supercomputer came with a price tag of about $160 million if I remember correctly (some estimates say that it took $1G in research funding) and hits 35 TFlops (sustained). #3 on the Top 500 supercomputers list is a Beowulf cluster with 2304 processors coming in at 7.6 TFlops (sustained). Even figuring $2000/processor + interconnect, that puts the Beowulf cluster at around $5 million or 1/32 of the cost for 1/5th of the performance (roughly speaking).
There are other factors, of course, but the key is that for the supercomputer to stay ahead of the microprocessor a boatload of funding is needed for the supercomputer and the payoff just isn't really there. If it was a lot more supercomputer companies would still be in business.
We piss you!
Well, you just answered the question - "Why go to college?" People who don't go to college do not get salaried office positions. Instead, their career choices often involve the phrase "Would you like fries with that" and attendance and punctuality ARE important if they don't want to wind up IN A TRAILER DOWN BY THE RIVER.
Remember, you should think big! If you want to make more than $1 per spam, contact me about my new work at home program that pays you big $$$$!
if you're worried about how much resources are consumed in making aluminum. Besides, most (and I mean MOST - not necessarily the best) bicycles are made out of steel.
There actually was one place in the world at least that had 10,000 users on AppleTalk - Apple! Yah, it was all one big happy AppleTalk network when I was there. It worked, too.
Ha, you think you had it bad? Back when I was in college, after trudging through 2 miles of snow (ok, sand - I went to UCSD) we had to "hand compile" our Ada code into Pascal because the Prof's super special Ada compiler used to crash the VAX (this was 1987, I think). We all gave up and just made the Pascal work and then "disassembled" it into Ada. What a waste of time.
Well, if you have to jump through all these hoops in Java you would have to jump through those same hoops in any other language and I don't see anyone arguing that.
The GPL license only comes into play when you DISTRIBUTE software. If your customers are asking you for internal solutions, the GPL will not affect them at all and I think you would do the OpenSource community (and yourself) a favor by explaining that to them rather than making a complex piece of code and getting them worried about GPL infringement.
Forget about people dumpster diving - trash cans get spilled and bags get ripped. Do you want your bank statement blowing down the street?
The author of the article is retarded. If you read section 6 and find yourself terribly confused (because it makes no mention of anything the would seem to make the LGPL worse for Java than any other language), you should reply labeled "Misleading article" by timsuth, which is a model of clarity and explains the situation fully.
In order to make a buffer between GPL and proprietary code, just make an LGPL'd library and forget about it. You'll have to make the source of the LGPL'd library available but it'll be a pretty thin facade. Or quite trying to steal other people's software and write your own if you want to sell it.
WordPad, bundled with Windows (at least it's in Win2K, I don't have an XP box to check) will open basic Word documents just fine. I'm still waiting for my Panther CD's so I can't check the limits of TextEdit.
So, OS X will now have some basic functionality built into it that Windows does. That's good, but I don't think it's the end of MS Office.
Ummmm...why are you doing all this work? The LGPL is not viral - if you link/import/include what have you to an LGPL library your code does not "become LGPL". What does happen, though, is that you have an obligation to provide the source code to the LGPL'd library that you included. Going through all these acrobatics doesn't change anything - you STILL have to provide the sources to the LGPL'd library.
Well, then you're carrying the metal matrix along with you (adding weight) and it's probably not possible to get the matrix to release hydrogen fast enough for rocket engines - the amount of fuel they gulp is amazing.
Didn't you seen Moonraker? That bad guy Drax hijacked the shuttle and blew up the 747 carrying it. They couldn't afford a new one so it was back to the old drawing board.
The Mac ROMs were reverse-engineered long ago using a white-box approach - the publicly available API descriptions from Inside Macintosh were used to get a start and then they just messed with it until it worked. There was a Mac-on-Unix emulator, damn, I've forgotten the name, but it came out around 1990. Apple killed it the old-fashioned way - they bought it, circa 1996. I think portions of it made their way into the Blue Box.
Apple doesn't license MacOS to OEMs. That's how they keep people from making Mac clones. Most people want to buy a machine with an OS, not a bare box and then have to schlep over to the Apple Store to buy OS X.
Apple does not have a monopoly on the desktop market. MS does. It's a whole different ball game.