Re:Broken Angels...
on
Altered Carbon
·
· Score: 2, Interesting
Broken Angels is pretty different to Altered Carbon, there's a bit less characterisation and a bit more 'action'. The plot is alittle less twisted. I enjoyed it just as much to be honest, I found it harder to put down, but it's not a classic. I'm probably going to read Altered Carbon again in a few months, but I doubt I'll ever read Broken Angels again.
Still can't wait for the next one. Getting 're-sleeved' means that Kovach can play a fairly different kind of role in subsequent installments, I hope that the author plays on this bit more (Kovach does kill an awful lot of people:)
This is simply not true. There is no *conceptual* reason for the same algotithim to be any slower when implemented in C++ rather than C. The only reason that this is ever the case is if the C++ compiler is "worse" than the C compiler (i.e. it produces less efficent code, as was true of most early C++ compilers). Or if the C++ implementation uses some of the 'slow' features of C++ (templates, virtual functions etc.), but to match *exactly* an existing C algorithim these need never be used.
In fact, C++ offers const and inline, which can provide dramatic performance increases in certain situations. These are not in C at all (although most C compilers have supported them for ages, and I think that they're actually in C99, anyone know for sure?). Bottom line, you can write a C++ program that will produce the same asm as any given C program (that's why C is a subset of C++). Granted there may be some kind of *really* subtle differences todo with volatile or somthing, which might be an issue on some embedded platforms or somthing, but for PC's it not an issue.
C won't compete in speed with assembly, but as computers get faster, the difference becomes marginal
The difference becomes marginal as *compiler* technology improves. If a compiler creates slower asm from your C than a hand-written version, it will be slower no matter what machine you run it on. The only effect that CPU technology has on the asm/C argument is that as CPU's get proportionally faster when compared to memory access speeds, there is less speed gain to be had from optimising your computations and more to be had from optimising your memory accesses (or other kinds of peripheral access), any decent C (or C++) compiler should allow as much control over your memory accesses as hand-written asm. That's why PC games tend to contain less and less asm these days.
I'f Java lives on, and computers get faster, more and more games will be made in Java
It's not just speed, you can't easily get back the RAM that a VM has taken off you just by starting up. People still begrudge C++ the memory taken up with vtables, the memory overhead of Java is huge by comparison.
I mean, do we really want to have Sun be the judge of what platform will get a good virtual machine and what platform won't. I know there are "self made" virtual machines, but AFAIK Sun is trying to make a buck here, so they probably don't want to be compatible with them...
I think that the only way Java will ever get into the games sector is if Sun it totally open about VM implementations. Trying to make incompatible versions etc. will just hurt their sales, they're not M$ after all. Speaking of which, if the next XBox has an embedded.NET interpreter thingy, then I think that there's a much stronger case for people to be talking about C# in games, rather than Java.
While it's true that all the improvements being made to Java (and to computers in general) will shrink the gaps in speed and RAM is becomming cheaping and cheaper the gap between Java and native implementations will never close to nothing. The transition from asm to C to C++ is a very different thing to the transition from C++ to Java. Java is a far harder pill to swallow, as it has an initial run-time cost and there's no easy way back (if you started using a C++ compiler and it was too slow, you could still write all your update loop code in asm - no problem). Even today C++ has not replaced asm completly, and it never will. Games will always need to get back to the metal every now and then. Unless Sun embrace this and make the native-Java interoperability as easy as possible, then moving to Java will never be worth the programming benefits that Java offers.
Java has already caught on as the dominant format for making games for mobile phones, but the language has yet to be widely used for PC-based games.
Not so. Mobile games are still an evolving area, and J2ME is already dying out in favour of C++ SDK's for specific platforms. The limited kind of games that J2ME has given us are not products that people are willing to pay for.
This is because *real* games need platform specific assets. Sounds that match the sound playback hardware, graphics at the right sizes and colour depths, models with the right LOD for the renderer etc.
Once you're providing a platform specific set of assets, there's very little benefit in having platform independant code. Mobiles don't have alot of CPU or RAM, and if you're not going to have platform portability anyway, then there's really no point in using Java. You're much better off programming on the metal. Native phones like the SPV and the N-Gage already allow this, and offer C++ SDK's, which mobile game developers are using.
SDK's like this are not available on phones without operating systems (because they don't have memory protection so you can't let 3rd party executables onto them, an issue neatly side-stepped by J2ME). However this problem will be overcome by implementations like BREW or by just adding memory protection. It just a matter of time.
Having said all that, I now write PC games and I think that Java could have a bright future there. Not in games written entirely in Java, but with Hybrid games. Java will never compete for speed. It's a fact, live with it. But 90% of a games' CPU time is spent curring around 20% of the games' code (i.e. the renderer, routefinder etc.). If that 20% is written in C/C++/asm and some percentage (large)of the rest in Java, the speed issue will of little consequence.
The real question here is why? C++ works very well thank you and the tools and API's required to create a hybrid game such as this are a real pain (when compared to just hitting F7 in VC++). No kind of marketing speak from Sun is going to make programmers go through that pain, just for the sake of 'using Java'. If the tool's were better and Sun put alot of effort into supporting this kind of deployment then game developers might well take it up. Not for platform independance, but for memory managment and the other *real* benefits of Java (simplified inheiretance, useful RTTI, serialisation etc.). That's were Java can be useful and that's what Sun should be talking about.
Also, if you really want game developers to use your technology, it's got to work on X-Box and PS/2. FACT. So get to it Sun, you've got plenty to sort out before you start nagging us with your marketing hounds.
Just finished it and it's great, reading the sequel now. Basically it's a cyber-punk detective story. The technology is centered around people being able to download themselves into different bodies, which is handy.
Also, the Arabesque series (Pashazade is the first) by J.C. Grimwood is a must read. Again, slightly detective-ish.
The reasons for going with a commercial product aimed specifically at games, rather than an open source (or whatever Mesa is licensed as - I think it's MIT or similar) more generic software renderer should be obvious.
>And the compiler should optimize things for a given processor.
Certain compilers (Intel for example) will allow you to use MMX, SSE and SSE2 compiler intrinsics without going to asm.
Doing it by hand will still beat the compiler (although the gap is always closing). If you get the Quake source from id, you can see Mr. Abrash's real-life demonstration of this. The hand-optimised asm runs faster (only a couple of frames, but still noticeable) than the compiled optimised C version even today (on processors that didn't exist when the asm was written with very different performance profiles). I didn't know that he was involved in the pixomatic thing, it's nice to see that he's still putting all those asm skills to good use:)
I am a games programmer (admittedly, not a console programmer) and I found it fairly easy to get into the industry. Most people that I know in the industry say the same thing. However, I think that this is because I/they were suitable people to work in this industry. There are alot of people, employed as "programmers" in other sectors who are not suitable to be game programmers, and they don't get the jobs. I think that it's more accurate to say "Not everyone can work in the games industry".
I'm not trying to be elitist, most games companies (certainly in the UK) are small and value their programmers, hence they are much more picky on who they employ. Larger companies employ more programmers and are not as badly effected by individual poor performance. Add to this the fact that games programming is often more complex than alot of work done outside of it. Having previously worked (as a programmer) outside the industry I know that alot of my ex-colleagues could not do my job. Games are large and often totally proprietary pieces of code. Anyone who has been writing web/database apps (as I was until I joined the industry) will have a serious shock if they start working for a professional games company (I know that I did).
I don't know how any of this relates to console hardware but anyway....
>Porthouses like Hyperion need to start talking to the developers that make big-name games, considering that the publishers certainly aren't taking a chance on it. Simplistic? Yeah. Idealistic? Definitely. But it needs to happen.
Why? I'm a programmer, working in a game studio, and I'd like to know why everyone expects this to happen. In my previous career (internet/database programmer) I was a big user and advocate of Linux in my workplace(s) because there was a clear cost saving to my employer(s) and a number of other plus points to going the Linux route. I just don't see this for games tho'. There is no commercial reason for us to port our games to Linux. The only extra sales that it gives you are customers who
Have a PC
That meets your min spec
That has Linux (and a version of linux that u can support).
That does not have a version of Windows installed as well (or access to another windows machine).
Now, consider that taking time out to do a Linux port will essentially mean taking features out of the Win32/Console version(s) of the game (or leaving bugs in;) I just don't see the commerical logic here at all. When the market is there (i.e. there are enough Linux users who want to buy games, who don't have Windows machines, to pay for the extra time required to perform/support/test the port) then studios will consider it seriously, until then, why should we bother?
BTW - I think that doing a Linux/Unix version of the server components of a multiplayer game is a good thing, my doubts don't extend to that.
"The good news here is, with Linux loaded on a Zarus we should be able to use any of the great languages that Linux already supports to flood that market with good software."
Er... I must have missed somthing here. I've always thought that Windows was the platform which was full of "non-programmer" languages. VB, Delphi and so forth. When did Linux become the OS which has a "bunch of great languages?". I've just moved from a mainly Solaris/Linux development environment to a 98/NT one, so I'm not as "in the know" as I used to be about such things. Please enlighten me, what have I missed? Which languages are you talking about?
I live in London. I get a train to work every morning. It *sucks*. You can't eat, sleep or be drunk, because there's _barely_ enough space to stand (read a book if you're lucky). You have to wait out in the cold on the platform (this might not be a problem in some parts of US, but it's a problem here). Trains are often delayed or canceled, they are also vunerable to weather.
Now, part of these problems are to do with the fact that it's London, and the train organisation/managment/funding is so screwed up. Also, we have a very high population density here, which doesn't help.
If someone did this in the US it *might* be cool, but it would very much depend on who owned it and how smart they were.
All I'm saying is that while road travel in the US might be pretty bad, train travel over here is not much better.... (if the recent track record - no pun intended - is anything to go by, they're not much safer either!)
One other thing to say: I used to get this boat to work in the morning. This is the way to travel. There's no stress, it's safe, not crowded, this wins all the time.
I used Miranda alot during my first year of College (the department moved the courses to Haskell 2 years after I was done, so I guess they are pretty similar). It was very good for certain things. We built a symbolic integration program in like 6 lines and 10 minutes!!!!
I also took a course in Paralell Computer architecture in my last year, and we looked at a language called SPL (Symetric Processor Language). Which was like Miranda, but would allow you to declare what parts of each function had to happen "together" (ie. because the IO to transfer from one proc to another was too expensive), and what order the various parts had to happen in (ie. B = 2 x A, so we need A before we can use B etc.) Has anyone else heard of this? We only used it in "theory", so I don't know if there are any *actual* implementations of this (ok, so my 3rd year course sucked....).
Anyway, I do actually have a point here too. Functional languages are great for writing certain types of logic in, and there *may* be some great way to use them w/ multi-processor architectures. But we're never going to write desktop apps or games with them, because they are no good for graphics. Apart from the speed problems (which some of the FP advocates here say are implementation specific), it's simply not a suitable syntax for creating graphic applications, or game engines, as one of the basic concepts in such a system is WHEN things happen. For this reason, I do not think that Funcation Languages's will ever "take over", from C/Java etc. as this is a major part of computing today. If I were to write any (non-HTML outputting) program which I thought had logic which could be well expressed in an Functional Language, and had a GUI, then I would write the Functional stuff in a language which let me build a nice DLL/SO out of it, and then build the GUI seperatly. Of course, I wouldn't have enough time to do this because I work in the real world, and not in a Uni, so I'll just build the GUI, and hack the functional stuff into it....
Having said that, wouldn't it be cool if you could put somthing Miranda-like into a Database? (and have it run fast). I think that this would be an Functional Language "killer app":^ espically if it was then decomposed by the RDBMS to use multiple processors (as in my Symetric Processor Language example). My DBA told me that making an Oracle Stored Procedure use Multiprocessors for logic (rather than for Queries) was near-impossible (I didn't look into it myself). Does anyone know if anything like this exists? I think that this is somewhere where Haskell/Miranda etc. would actually be v. useful, espically as SQL is so functional anyway (hey, I would use it).
One last thing, there is talk here of Prolog. Isn't prolog a Declaritive language rather than a Functional one? (no scarcasm). I don't really remember the difference, but there are so many Language Theory buffs posting to this thread, it's worth asking....
We've had these Cisco phones since Janurary. There have been a few teething problems (and having a pair of NT boxes in the server rack really pisses me off), we had to go without voicemail for a while, which was also annoying.
I don't want to repeat what everyone else has said about standards and latency and connecting to leagcy phones etc. but there is one extremely large advantage of this system which no-one else has mentioned. Our office is a listed building. For those that are not in the UK a listed building is an old building which the owners (us) are not allowed to modify in any significant way, as it's historical architecture etc. has to be preserved. I think that this is stupid, but we have to live with it. It means that we can't take up the floor boards etc. and install structured cabling etc. All of the network cable has been installed with skirting board mounts etc. and cost us a hell of alot more than it would have done otherwise. If we'd had to install a seperate set of cables for phones, then it would have cost as more than twice as much again. Now the phones and the PC's are on the same cables, much easier simpler and cheaper. I'm just waiting for the new routers which deliver the phones' power via the cat-5 as well.
The phones are not great, the NT factor is really stupid, but all in all they've been pretty good for us.
Whatever the situation right now. Buy the end of the year, people with alot of money to spend will be stupid not to use Java. There are a host of J2EE compilant application servers on the way (Jrun 3.0, IBM websphere, Weblogic). These are programs which handle requests to Servlets/JSP which can make J2EE API calls to perform a large number of things (talk to DB, perform managed transactions, access remote servers in a number of different protocols etc. -- see the spec). When these calls are made, the application server itself will do the legwork. This can has tremendous performance gains (as well as having to do less code). For example, if you make a call to execute a piece of SQL, the applcation server can use one of it's persistant connects to that database, instead of you're servlet creating a new one.
I know that this can be done quite easily with Servlets anyway, but the application server will be able to do this kind of thing for the whole of the J2EE spec.
Hopefully, future releases of Tomcat will do this, making for the most efficent architecture yet.
Slashdot Mirror
Broken Angels is pretty different to Altered Carbon, there's a bit less characterisation and a bit more 'action'. The plot is alittle less twisted. I enjoyed it just as much to be honest, I found it harder to put down, but it's not a classic. I'm probably going to read Altered Carbon again in a few months, but I doubt I'll ever read Broken Angels again.
:)
Still can't wait for the next one. Getting 're-sleeved' means that Kovach can play a fairly different kind of role in subsequent installments, I hope that the author plays on this bit more (Kovach does kill an awful lot of people
Apparently the renderer and a bunch of other parts were all written in C++.
A guy I used to work with told me that, I don't know if it's true or not.
This is simply not true. There is no *conceptual* reason for the same algotithim to be any slower when implemented in C++ rather than C. The only reason that this is ever the case is if the C++ compiler is "worse" than the C compiler (i.e. it produces less efficent code, as was true of most early C++ compilers). Or if the C++ implementation uses some of the 'slow' features of C++ (templates, virtual functions etc.), but to match *exactly* an existing C algorithim these need never be used.
In fact, C++ offers const and inline, which can provide dramatic performance increases in certain situations. These are not in C at all (although most C compilers have supported them for ages, and I think that they're actually in C99, anyone know for sure?). Bottom line, you can write a C++ program that will produce the same asm as any given C program (that's why C is a subset of C++). Granted there may be some kind of *really* subtle differences todo with volatile or somthing, which might be an issue on some embedded platforms or somthing, but for PC's it not an issue.
The difference becomes marginal as *compiler* technology improves. If a compiler creates slower asm from your C than a hand-written version, it will be slower no matter what machine you run it on. The only effect that CPU technology has on the asm/C argument is that as CPU's get proportionally faster when compared to memory access speeds, there is less speed gain to be had from optimising your computations and more to be had from optimising your memory accesses (or other kinds of peripheral access), any decent C (or C++) compiler should allow as much control over your memory accesses as hand-written asm. That's why PC games tend to contain less and less asm these days.
It's not just speed, you can't easily get back the RAM that a VM has taken off you just by starting up. People still begrudge C++ the memory taken up with vtables, the memory overhead of Java is huge by comparison.
I think that the only way Java will ever get into the games sector is if Sun it totally open about VM implementations. Trying to make incompatible versions etc. will just hurt their sales, they're not M$ after all. Speaking of which, if the next XBox has an embedded
While it's true that all the improvements being made to Java (and to computers in general) will shrink the gaps in speed and RAM is becomming cheaping and cheaper the gap between Java and native implementations will never close to nothing. The transition from asm to C to C++ is a very different thing to the transition from C++ to Java. Java is a far harder pill to swallow, as it has an initial run-time cost and there's no easy way back (if you started using a C++ compiler and it was too slow, you could still write all your update loop code in asm - no problem). Even today C++ has not replaced asm completly, and it never will. Games will always need to get back to the metal every now and then. Unless Sun embrace this and make the native-Java interoperability as easy as possible, then moving to Java will never be worth the programming benefits that Java offers.
Java has already caught on as the dominant format for making games for mobile phones, but the language has yet to be widely used for PC-based games.
Not so. Mobile games are still an evolving area, and J2ME is already dying out in favour of C++ SDK's for specific platforms. The limited kind of games that J2ME has given us are not products that people are willing to pay for.
This is because *real* games need platform specific assets. Sounds that match the sound playback hardware, graphics at the right sizes and colour depths, models with the right LOD for the renderer etc.
Once you're providing a platform specific set of assets, there's very little benefit in having platform independant code. Mobiles don't have alot of CPU or RAM, and if you're not going to have platform portability anyway, then there's really no point in using Java. You're much better off programming on the metal. Native phones like the SPV and the N-Gage already allow this, and offer C++ SDK's, which mobile game developers are using.
SDK's like this are not available on phones without operating systems (because they don't have memory protection so you can't let 3rd party executables onto them, an issue neatly side-stepped by J2ME). However this problem will be overcome by implementations like BREW or by just adding memory protection. It just a matter of time.
Having said all that, I now write PC games and I think that Java could have a bright future there. Not in games written entirely in Java, but with Hybrid games. Java will never compete for speed. It's a fact, live with it. But 90% of a games' CPU time is spent curring around 20% of the games' code (i.e. the renderer, routefinder etc.). If that 20% is written in C/C++/asm and some percentage (large)of the rest in Java, the speed issue will of little consequence.
The real question here is why? C++ works very well thank you and the tools and API's required to create a hybrid game such as this are a real pain (when compared to just hitting F7 in VC++). No kind of marketing speak from Sun is going to make programmers go through that pain, just for the sake of 'using Java'. If the tool's were better and Sun put alot of effort into supporting this kind of deployment then game developers might well take it up. Not for platform independance, but for memory managment and the other *real* benefits of Java (simplified inheiretance, useful RTTI, serialisation etc.). That's were Java can be useful and that's what Sun should be talking about.
Also, if you really want game developers to use your technology, it's got to work on X-Box and PS/2. FACT. So get to it Sun, you've got plenty to sort out before you start nagging us with your marketing hounds.
by Richard Morgan.
Just finished it and it's great, reading the sequel now. Basically it's a cyber-punk detective story. The technology is centered around people being able to download themselves into different bodies, which is handy.
Also, the Arabesque series (Pashazade is the first) by J.C. Grimwood is a must read. Again, slightly detective-ish.
The reasons for going with a commercial product aimed specifically at games, rather than an open source (or whatever Mesa is licensed as - I think it's MIT or similar) more generic software renderer should be obvious.
>And the compiler should optimize things for a given processor.
I am a games programmer (admittedly, not a console programmer) and I found it fairly easy to get into the industry. Most people that I know in the industry say the same thing. However, I think that this is because I/they were suitable people to work in this industry. There are alot of people, employed as "programmers" in other sectors who are not suitable to be game programmers, and they don't get the jobs. I think that it's more accurate to say "Not everyone can work in the games industry".
I'm not trying to be elitist, most games companies (certainly in the UK) are small and value their programmers, hence they are much more picky on who they employ. Larger companies employ more programmers and are not as badly effected by individual poor performance. Add to this the fact that games programming is often more complex than alot of work done outside of it. Having previously worked (as a programmer) outside the industry I know that alot of my ex-colleagues could not do my job. Games are large and often totally proprietary pieces of code. Anyone who has been writing web/database apps (as I was until I joined the industry) will have a serious shock if they start working for a professional games company (I know that I did).
I don't know how any of this relates to console hardware but anyway....
Why? I'm a programmer, working in a game studio, and I'd like to know why everyone expects this to happen. In my previous career (internet/database programmer) I was a big user and advocate of Linux in my workplace(s) because there was a clear cost saving to my employer(s) and a number of other plus points to going the Linux route. I just don't see this for games tho'. There is no commercial reason for us to port our games to Linux. The only extra sales that it gives you are customers who
Now, consider that taking time out to do a Linux port will essentially mean taking features out of the Win32/Console version(s) of the game (or leaving bugs in
BTW - I think that doing a Linux/Unix version of the server components of a multiplayer game is a good thing, my doubts don't extend to that.
There is no implementation of stdio for GBA. People still make games for it tho'.
There's a Sega Megadrive version.
Er... I must have missed somthing here. I've always thought that Windows was the platform which was full of "non-programmer" languages. VB, Delphi and so forth. When did Linux become the OS which has a "bunch of great languages?". I've just moved from a mainly Solaris/Linux development environment to a 98/NT one, so I'm not as "in the know" as I used to be about such things. Please enlighten me, what have I missed? Which languages are you talking about?
I live in London. I get a train to work every morning. It *sucks*. You can't eat, sleep or be drunk, because there's _barely_ enough space to stand (read a book if you're lucky). You have to wait out in the cold on the platform (this might not be a problem in some parts of US, but it's a problem here). Trains are often delayed or canceled, they are also vunerable to weather.
Now, part of these problems are to do with the fact that it's London, and the train organisation/managment/funding is so screwed up. Also, we have a very high population density here, which doesn't help.
If someone did this in the US it *might* be cool, but it would very much depend on who owned it and how smart they were.
All I'm saying is that while road travel in the US might be pretty bad, train travel over here is not much better.... (if the recent track record - no pun intended - is anything to go by, they're not much safer either!)
One other thing to say: I used to get this boat to work in the morning. This is the way to travel. There's no stress, it's safe, not crowded, this wins all the time.
I used Miranda alot during my first year of College (the department moved the courses to Haskell 2 years after I was done, so I guess they are pretty similar). It was very good for certain things. We built a symbolic integration program in like 6 lines and 10 minutes!!!!
I also took a course in Paralell Computer architecture in my last year, and we looked at a language called SPL (Symetric Processor Language). Which was like Miranda, but would allow you to declare what parts of each function had to happen "together" (ie. because the IO to transfer from one proc to another was too expensive), and what order the various parts had to happen in (ie. B = 2 x A, so we need A before we can use B etc.) Has anyone else heard of this? We only used it in "theory", so I don't know if there are any *actual* implementations of this (ok, so my 3rd year course sucked....).
Anyway, I do actually have a point here too. Functional languages are great for writing certain types of logic in, and there *may* be some great way to use them w/ multi-processor architectures. But we're never going to write desktop apps or games with them, because they are no good for graphics. Apart from the speed problems (which some of the FP advocates here say are implementation specific), it's simply not a suitable syntax for creating graphic applications, or game engines, as one of the basic concepts in such a system is WHEN things happen. For this reason, I do not think that Funcation Languages's will ever "take over", from C/Java etc. as this is a major part of computing today. If I were to write any (non-HTML outputting) program which I thought had logic which could be well expressed in an Functional Language, and had a GUI, then I would write the Functional stuff in a language which let me build a nice DLL/SO out of it, and then build the GUI seperatly. Of course, I wouldn't have enough time to do this because I work in the real world, and not in a Uni, so I'll just build the GUI, and hack the functional stuff into it....
Having said that, wouldn't it be cool if you could put somthing Miranda-like into a Database? (and have it run fast). I think that this would be an Functional Language "killer app" :^ espically if it was then decomposed by the RDBMS to use multiple processors (as in my Symetric Processor Language example). My DBA told me that making an Oracle Stored Procedure use Multiprocessors for logic (rather than for Queries) was near-impossible (I didn't look into it myself). Does anyone know if anything like this exists? I think that this is somewhere where Haskell/Miranda etc. would actually be v. useful, espically as SQL is so functional anyway (hey, I would use it).
One last thing, there is talk here of Prolog. Isn't prolog a Declaritive language rather than a Functional one? (no scarcasm). I don't really remember the difference, but there are so many Language Theory buffs posting to this thread, it's worth asking....
We've had these Cisco phones since Janurary. There have been a few teething problems (and having a pair of NT boxes in the server rack really pisses me off), we had to go without voicemail for a while, which was also annoying.
I don't want to repeat what everyone else has said about standards and latency and connecting to leagcy phones etc. but there is one extremely large advantage of this system which no-one else has mentioned. Our office is a listed building. For those that are not in the UK a listed building is an old building which the owners (us) are not allowed to modify in any significant way, as it's historical architecture etc. has to be preserved. I think that this is stupid, but we have to live with it. It means that we can't take up the floor boards etc. and install structured cabling etc. All of the network cable has been installed with skirting board mounts etc. and cost us a hell of alot more than it would have done otherwise. If we'd had to install a seperate set of cables for phones, then it would have cost as more than twice as much again. Now the phones and the PC's are on the same cables, much easier simpler and cheaper. I'm just waiting for the new routers which deliver the phones' power via the cat-5 as well.
The phones are not great, the NT factor is really stupid, but all in all they've been pretty good for us.
JavaScript is nothing to do with CGI. It runs on the web browser, not the server.
Whatever the situation right now. Buy the end of the year, people with alot of money to spend will be stupid not to use Java. There are a host of J2EE compilant application servers on the way (Jrun 3.0, IBM websphere, Weblogic). These are programs which handle requests to Servlets/JSP which can make J2EE API calls to perform a large number of things (talk to DB, perform managed transactions, access remote servers in a number of different protocols etc. -- see the spec). When these calls are made, the application server itself will do the legwork. This can has tremendous performance gains (as well as having to do less code). For example, if you make a call to execute a piece of SQL, the applcation server can use one of it's persistant connects to that database, instead of you're servlet creating a new one.
I know that this can be done quite easily with Servlets anyway, but the application server will be able to do this kind of thing for the whole of the J2EE spec.
Hopefully, future releases of Tomcat will do this, making for the most efficent architecture yet.