I still don't understand why Google and Sun are offering the same software under different names. Google is backing the Mozilla Foundation while supporting their own Chrome (read: they didn't write Firefox, just back it), and Sun is distributing both OpenOffice and StarOffice.
What are you saying here? That Chrome and Firefox are the same software?!? What you're saying about Sun seems right, but Chrome and Firefox aren't close at all...
The Karma is a nice player, my girlfriend has one, but I'd point out that the storage part of it is a bit weird, using some special software to access the data (they call it "Rio Taxi"). The iRiver H120 also plays Oggs, has a nice remote (the only thing my girlfriend is wishing for) and I think is accessible USB storage (but be sure to verify that first!). There's also a 40GB model.
Their funkier thingy with the big screen also supports USB On The Go, which might be cool to hook up a USB flash reader and transfer pictures to the hard drive, for a long trip without a laptop (my two "dinky" 256MB CompactFlash is only good for almost 40 pictures on a Canon EOS 10D!).
While the Earth Simulator might be custom in a sense (you can't order Earth Simulator nodes, for example), they are NOT specialized, or at least not very much.
The Earth Simulator nodes are the prototypes of the SX-6, so yes, they are custom-built, like all prototypes are. A fully-loaded SX-6 is very nearly the same as an Earth Simulator node, and the same interconnect is also available for the SX-6. I think one of the difference, beside the paint job, is slightly more efficient memory timings on the SX-6, so actually, the commercially-available version is actually BETTER!
But I guess you wouldn't be able to call an SX-6 "off the shelf"...
Both Earth Simulator and SX-6 runs a (putrid, but that's off-topic!) Unix variant which runs directly on the main processor, it isn't one of these designs with an off-the-shelf processor for the OS and management, and a specialized coprocessor for accelerating computations. It can operate on a variety of problems with equivalent ability. As for their power, that's what you get when you put lots and lots of vector pipes in processor: the SX-5 could do around 4096 floating point operations per clock cycle (if they are all the same!) and had a 256 *bytes* wide memory bus (compared the the puny "one flop every few clock cycle" of a Pentium 4, and its tiny 64 bit memory bus). I don't have the info for SX-6, but it is similar...
"Vector computers" might have been called "SIMD computers" instead, in the recent history.
They are in fact using more and more off-the-shelf hardware, having switched from HiPPI for networking and disk access to gigabit ethernet and fibre channel, respectively.
Disclaimer/credentials: I used to work for NEC's North American supercomputer subsidiary, then for Cray, who is currently NEC's distributor in America.
I like a single thread/process per CPU design, where each thread/process use event-driven I/O to operate. A few things to keep in mind:
Never forget how a lot of idle connections can kill you, for example a thousand of people connecting to your fast server over 56k modems, sucking only a packet now and then. If you have a thread/process-per-connection design, like Apache, you'll get screwed real hard when you have a bazillion thread/process doing *almost* (but not quite) nothing, swamping the I/O scheduler and context switching like mad. If you use a select/poll-based approach, scanning all these inactive file descriptors, looking for those that are readable/writable, wastes a lot of time. Check out the new epoll stuff or Ben LaHaise's callback-based AIO interface.
You should use something like libevent or liboop to abstract your event loop, so that you can use select/poll on old or unpatched kernel, but so that you use epoll and other fancy event dispatching mechanisms on your production servers.
Of course, they bought it from Sybase (if I remember correctly).
MS SQL Server doesn't have multiversioned concurrency control, that only Oracle and PostgreSQL have. Without this, readers block writers and writers block readers on tables involved in a transaction. This thing alone makes me an Oracle/PostgreSQL boy (though I don't want to touch Oracle sysadmining with a 10 foot pole).
PostgreSQL doesn't lack too many things compared to MS SQL (although it *does* lack a few things critical for larger installations).
I can't say anything good about MySQL. It's barely faster. It's so much harder on me to write proper code (but I haven't been using InnoDB and all these other fancy things).
Yes, the Q3 engine goes about a quarter million dollars. Why not license it for cheap after Doom3? Well, because people will keep licensing it for a while after Doom3 comes out, and at $250,000 a pop, you'd need a cool 2,500 $100 licensees to compensate for a single normal price license. Also, Garage Games model requires a bit of publishing infrastructure that iD probably doesn't want to get into.
Looks like you need a Net Integrator. It does all of what you ask for, has a cool backup system, RAID support, and is winning all of the awards in magazine reviews (yes, kicking the ass of Cobalts soundly). For example, PC Magazine got pretty happy about the NI.
They were supposed to sell a number of SX machines since they struck the deal with NEC. This is the *only* one they managed to sell, and since they didn't have much money left to sustain their own SX-6 installation in Chippewa Falls (which was the actual first US SX-6 installation), they sold their machine to the ARSC, with a deal that lets them use it sometimes for testing and training.
My feeling is that they are utterly uninterested in selling SX systems, they'd rather sell their more profitable SV systems or their crazy MTA systems (woohoo, they managed to build ONE).
Disclaimer: I used to work for Cray in their SX support team and with HNSX Supercomputers before that, the North American subsidiary of NEC for supercomputers. I left of my own will, I wasn't part of the friday-right-before-Christmas round of layoff Cray did.
The basic strategy I would see for open source game development would be to keep the data proprietary, similar to the current situation with Doom and the first two Quakes (and I think some others).
This is based on the idea that game engines resemble each others to some degree and that the differentiating factor will be the maps/levels/artwork/scripting and so on. You can thus get improvement done on the engine contributed back to you, and others can make their own original games with your engine, but nobody is playing your exact game for free.
This strategy, of course, supposes that there is some significant amount of non-code data involved. If this is a puzzle game whose's only non-engine resources are backdrop images, this strategy is not effective.
Remember to mark down contributions from the outside somehow, because you might want to relicense the engine under a non-open license (or maybe just change the license to another open source one), and you'll have to ask permission from the copyright owners of these patches (remember what is happening to Mozilla!). Having them assign copyright to you, having a "clean" codebase branch or keeping contact information are three possible approaches.
Also, if you have some truly innovative technology in the engine that you think nobody else has, it might make sense to hold off the release a bit, so that you can build a market lead on that technology, then as competitors come up with equivalent technology, you can then release the source code.
Last commit in their CVS tree dates from 2001/12/12, so it wasn't *that* long, but still a few months.
If you like Korelib's idea, XPLC is pretty similar, with maybe exception of the UUIDs instead of strings as component identifiers.
XPLC is getting more development time than before, since my employer, Net Integration Technologies (http://www.net-itech.com/) is allowing me to work a full day per week on XPLC, in addition to what I used to do on nights and weekends.
On the other hand, Korelib seems to be somewhat more usable currently (XPLC is generally usable, but dynamic loading of components is not in yet, so it's usefulness is limited), being used in some of theKompany.com's applications.
Actually, TAO (The ACE ORB) has features to have dynamically loaded in-process servers, and to disable most of the features that makes other ORB's in-proc servers slower than COM or virtual C++ method invocation (stuff like method interception for example).
I wonder why you would choose CORBA if it was to disable all of the features that make it CORBA. Compatibility with other ORBs might be a reason, but I don't think that the kind of objects that you might want to have in-process and so on would be any good on other ORBs.
Some CORBA proponents will often claim that out-of-process is safer anyway, so that if you have a plugin crash, it won't take down your application, but most applications that do it that way becomes more or less confused after a plugin crashed, some to the point of crashing, so I don't see that being *that* much good anyway.
Objective-C has similar mechanisms built-in, and dynamic loading of components is nothing new there, being available since way back (1989?), as far as I know.
But then, Java is of the same language family as Smalltalk and Objective-C, only with a C++-style syntax, so I suppose this is no coincidence either (that Java has similar mechanisms to Objective-C and Smalltalk).
You have XPLC (shameless plug, that's the one I'm working on), CrystalSpace's SCF ("Shared Class Facility"), theKompany.com's Korelib, as well as others, including the previously mentioned Bamboo and Bonobo, but others like KDE's KPart/XPart, Mozilla's XPCOM and OpenOffice's UNO. You might even count Microsoft's.NET as well, if you want to.
Didn't it come out in 1988? And I seem to remember it be resolution-independent back then, but it has now been brain-damaged, like all the other popular OSes (including Linux), a real shame...
Mac OS X was derived from NeXTStep, which did run on Intel as well as Motorola hardware. A number of the earlier Developer Releases, back when it was still only known as "Rhapsody", still ran on Intel hardware.
Couldn't this article (and a number of others on Slashdot) be at least demoronized (cleaned up of Microsoft-specific characters, that turns up as question marks on my Unix browsers).
Svgalib has the architecture to support hardware acceleration, but the drivers are crap. No alpha support in the API (that was back in the day that alpha was science-fiction stuff). Should die and stay dead IMHO.
I don't know anything about QtE.
aalib, please.
GGI is supposed to support hardware acceleration, but I don't know about alpha. I also don't know about the status of their drivers and how much they accelerate.
I don't know much about MicroWindows/NanoX. Transparency is mentioned.
There is also SDL, which has a FB target that provides some acceleration for a few cards, and there is also alpha support. I do not know the extent of the acceleration.
My opinion is that when you have a properly abstracted API, adding hardware acceleration is not that hard (it's basically as hard as the hardware makes it). The problem is when the hardware has features that the API doesn't have anything close, like for example alpha transparency in the Xlib API. XRender basically extends the API to have this, and even provides hardware accelerated implementations for some cards.
So citing "hardware accelerated" as a feature is not that impressive. It all depends on the API being flexible enough.
What I do see DirectFB providing is a single-application window support, much like OpenGUI does. OpenGUI supports the framebuffer, Svgalib, DGA2 and Mesa as back ends. Accelerations for the framebuffer could be much less than what is provided by DirectFB, but still, consider that it could be the exact same thing.
While none are exact replacement for each others, there is a HUGE amount of overlap between what all of these projects do. There is definitely room for some unification.
Why don't someone write a Xlib driver for DirectFB?
Why isn't DirectFB limited to the simple task of doing hardware acceleration, and something like OpenGUI layered upon it to take advantage of those acceleration?
Why do everyone think that a library that can only have one single application at a time can suddenly replace X?
Slashdot Mirror
I still don't understand why Google and Sun are offering the same software under different names. Google is backing the Mozilla Foundation while supporting their own Chrome (read: they didn't write Firefox, just back it), and Sun is distributing both OpenOffice and StarOffice.
What are you saying here? That Chrome and Firefox are the same software?!? What you're saying about Sun seems right, but Chrome and Firefox aren't close at all...
You're talking about polygyny, not polygamy, although that's a common mistake.
The Karma is a nice player, my girlfriend has one, but I'd point out that the storage part of it is a bit weird, using some special software to access the data (they call it "Rio Taxi"). The iRiver H120 also plays Oggs, has a nice remote (the only thing my girlfriend is wishing for) and I think is accessible USB storage (but be sure to verify that first!). There's also a 40GB model.
Their funkier thingy with the big screen also supports USB On The Go, which might be cool to hook up a USB flash reader and transfer pictures to the hard drive, for a long trip without a laptop (my two "dinky" 256MB CompactFlash is only good for almost 40 pictures on a Canon EOS 10D!).
One of the best place I can think of is photo.net's "learn" section, particularly the "Making Photographs" tutorial.
http://www.photo.net/learn/
While the Earth Simulator might be custom in a sense (you can't order Earth Simulator nodes, for example), they are NOT specialized, or at least not very much.
The Earth Simulator nodes are the prototypes of the SX-6, so yes, they are custom-built, like all prototypes are. A fully-loaded SX-6 is very nearly the same as an Earth Simulator node, and the same interconnect is also available for the SX-6. I think one of the difference, beside the paint job, is slightly more efficient memory timings on the SX-6, so actually, the commercially-available version is actually BETTER!
But I guess you wouldn't be able to call an SX-6 "off the shelf"...
Both Earth Simulator and SX-6 runs a (putrid, but that's off-topic!) Unix variant which runs directly on the main processor, it isn't one of these designs with an off-the-shelf processor for the OS and management, and a specialized coprocessor for accelerating computations. It can operate on a variety of problems with equivalent ability. As for their power, that's what you get when you put lots and lots of vector pipes in processor: the SX-5 could do around 4096 floating point operations per clock cycle (if they are all the same!) and had a 256 *bytes* wide memory bus (compared the the puny "one flop every few clock cycle" of a Pentium 4, and its tiny 64 bit memory bus). I don't have the info for SX-6, but it is similar...
"Vector computers" might have been called "SIMD computers" instead, in the recent history.
They are in fact using more and more off-the-shelf hardware, having switched from HiPPI for networking and disk access to gigabit ethernet and fibre channel, respectively.
Disclaimer/credentials: I used to work for NEC's North American supercomputer subsidiary, then for Cray, who is currently NEC's distributor in America.
I like a single thread/process per CPU design, where each thread/process use event-driven I/O to operate. A few things to keep in mind:
o ntent/tech/servers.html
Never forget how a lot of idle connections can kill you, for example a thousand of people connecting to your fast server over 56k modems, sucking only a packet now and then. If you have a thread/process-per-connection design, like Apache, you'll get screwed real hard when you have a bazillion thread/process doing *almost* (but not quite) nothing, swamping the I/O scheduler and context switching like mad. If you use a select/poll-based approach, scanning all these inactive file descriptors, looking for those that are readable/writable, wastes a lot of time. Check out the new epoll stuff or Ben LaHaise's callback-based AIO interface.
You should use something like libevent or liboop to abstract your event loop, so that you can use select/poll on old or unpatched kernel, but so that you use epoll and other fancy event dispatching mechanisms on your production servers.
Here are a few URLs for you:
http://kegel.com/c10k.html
http://pl.atyp.us/c
Of course, they bought it from Sybase (if I remember correctly).
MS SQL Server doesn't have multiversioned concurrency control, that only Oracle and PostgreSQL have. Without this, readers block writers and writers block readers on tables involved in a transaction. This thing alone makes me an Oracle/PostgreSQL boy (though I don't want to touch Oracle sysadmining with a 10 foot pole).
PostgreSQL doesn't lack too many things compared to MS SQL (although it *does* lack a few things critical for larger installations).
I can't say anything good about MySQL. It's barely faster. It's so much harder on me to write proper code (but I haven't been using InnoDB and all these other fancy things).
Yes, the Q3 engine goes about a quarter million dollars. Why not license it for cheap after Doom3? Well, because people will keep licensing it for a while after Doom3 comes out, and at $250,000 a pop, you'd need a cool 2,500 $100 licensees to compensate for a single normal price license. Also, Garage Games model requires a bit of publishing infrastructure that iD probably doesn't want to get into.
Looks like you need a Net Integrator. It does all of what you ask for, has a cool backup system, RAID support, and is winning all of the awards in magazine reviews (yes, kicking the ass of Cobalts soundly). For example, PC Magazine got pretty happy about the NI.
Disclaimer: I do work for Net Integration Technologies, check out our web site for more info. It's a pretty cool place to work at, with bright people and supportive of open source software.
Yeah, we're the guys behind the famous WvDial program.
They were supposed to sell a number of SX machines since they struck the deal with NEC. This is the *only* one they managed to sell, and since they didn't have much money left to sustain their own SX-6 installation in Chippewa Falls (which was the actual first US SX-6 installation), they sold their machine to the ARSC, with a deal that lets them use it sometimes for testing and training.
My feeling is that they are utterly uninterested in selling SX systems, they'd rather sell their more profitable SV systems or their crazy MTA systems (woohoo, they managed to build ONE).
Disclaimer: I used to work for Cray in their SX support team and with HNSX Supercomputers before that, the North American subsidiary of NEC for supercomputers. I left of my own will, I wasn't part of the friday-right-before-Christmas round of layoff Cray did.
Once you've had them, you can never go back! Oh the speed! Oh the accuracy!
I'm a non-recursive whore, go Keith!
The basic strategy I would see for open source game development would be to keep the data proprietary, similar to the current situation with Doom and the first two Quakes (and I think some others).
This is based on the idea that game engines resemble each others to some degree and that the differentiating factor will be the maps/levels/artwork/scripting and so on. You can thus get improvement done on the engine contributed back to you, and others can make their own original games with your engine, but nobody is playing your exact game for free.
This strategy, of course, supposes that there is some significant amount of non-code data involved. If this is a puzzle game whose's only non-engine resources are backdrop images, this strategy is not effective.
Remember to mark down contributions from the outside somehow, because you might want to relicense the engine under a non-open license (or maybe just change the license to another open source one), and you'll have to ask permission from the copyright owners of these patches (remember what is happening to Mozilla!). Having them assign copyright to you, having a "clean" codebase branch or keeping contact information are three possible approaches.
Also, if you have some truly innovative technology in the engine that you think nobody else has, it might make sense to hold off the release a bit, so that you can build a market lead on that technology, then as competitors come up with equivalent technology, you can then release the source code.
See Software Secrets: Do They Help or Hurt?.
Last commit in their CVS tree dates from 2001/12/12, so it wasn't *that* long, but still a few months.
If you like Korelib's idea, XPLC is pretty similar, with maybe exception of the UUIDs instead of strings as component identifiers.
XPLC is getting more development time than before, since my employer, Net Integration Technologies (http://www.net-itech.com/) is allowing me to work a full day per week on XPLC, in addition to what I used to do on nights and weekends.
On the other hand, Korelib seems to be somewhat more usable currently (XPLC is generally usable, but dynamic loading of components is not in yet, so it's usefulness is limited), being used in some of theKompany.com's applications.
Actually, TAO (The ACE ORB) has features to have dynamically loaded in-process servers, and to disable most of the features that makes other ORB's in-proc servers slower than COM or virtual C++ method invocation (stuff like method interception for example).
I wonder why you would choose CORBA if it was to disable all of the features that make it CORBA. Compatibility with other ORBs might be a reason, but I don't think that the kind of objects that you might want to have in-process and so on would be any good on other ORBs.
Some CORBA proponents will often claim that out-of-process is safer anyway, so that if you have a plugin crash, it won't take down your application, but most applications that do it that way becomes more or less confused after a plugin crashed, some to the point of crashing, so I don't see that being *that* much good anyway.
Objective-C has similar mechanisms built-in, and dynamic loading of components is nothing new there, being available since way back (1989?), as far as I know.
But then, Java is of the same language family as Smalltalk and Objective-C, only with a C++-style syntax, so I suppose this is no coincidence either (that Java has similar mechanisms to Objective-C and Smalltalk).
You have XPLC (shameless plug, that's the one I'm working on), CrystalSpace's SCF ("Shared Class Facility"), theKompany.com's Korelib, as well as others, including the previously mentioned Bamboo and Bonobo, but others like KDE's KPart/XPart, Mozilla's XPCOM and OpenOffice's UNO. You might even count Microsoft's .NET as well, if you want to.
Clemens Szyperski's book, Component Software - Beyond Object-Oriented Programming, is an excellent book on that subject.
Who do you sue when a Free open source program breaks or lets in the commies?
Well, Microsoft software is well known for breaking, who's suing them? That would be very funny.
Didn't it come out in 1988? And I seem to remember it be resolution-independent back then, but it has now been brain-damaged, like all the other popular OSes (including Linux), a real shame...
Berlin?
Mac OS X was derived from NeXTStep, which did run on Intel as well as Motorola hardware. A number of the earlier Developer Releases, back when it was still only known as "Rhapsody", still ran on Intel hardware.
SuSE has a few distros built for specific roles (e-mail server and firewall, from memory, but I think there may be others).
Check out Quadra, you might be surprised after trying it out...
Couldn't this article (and a number of others on Slashdot) be at least demoronized (cleaned up of Microsoft-specific characters, that turns up as question marks on my Unix browsers).
I know Dr Dobbs Journal was founded as one of the first PC-oriented magazine, but I don't know whether it was actually the first or whatever...
Svgalib has the architecture to support hardware acceleration, but the drivers are crap. No alpha support in the API (that was back in the day that alpha was science-fiction stuff). Should die and stay dead IMHO.
I don't know anything about QtE.
aalib, please.
GGI is supposed to support hardware acceleration, but I don't know about alpha. I also don't know about the status of their drivers and how much they accelerate.
I don't know much about MicroWindows/NanoX. Transparency is mentioned.
There is also SDL, which has a FB target that provides some acceleration for a few cards, and there is also alpha support. I do not know the extent of the acceleration.
My opinion is that when you have a properly abstracted API, adding hardware acceleration is not that hard (it's basically as hard as the hardware makes it). The problem is when the hardware has features that the API doesn't have anything close, like for example alpha transparency in the Xlib API. XRender basically extends the API to have this, and even provides hardware accelerated implementations for some cards.
So citing "hardware accelerated" as a feature is not that impressive. It all depends on the API being flexible enough.
What I do see DirectFB providing is a single-application window support, much like OpenGUI does. OpenGUI supports the framebuffer, Svgalib, DGA2 and Mesa as back ends. Accelerations for the framebuffer could be much less than what is provided by DirectFB, but still, consider that it could be the exact same thing.
While none are exact replacement for each others, there is a HUGE amount of overlap between what all of these projects do. There is definitely room for some unification.
Why don't someone write a Xlib driver for DirectFB?
Why isn't DirectFB limited to the simple task of doing hardware acceleration, and something like OpenGUI layered upon it to take advantage of those acceleration?
Why do everyone think that a library that can only have one single application at a time can suddenly replace X?