Re: Java and NC

Tim Schaefer <tschaefe@mindspring.com> wrote: :[some snippage occured to prevent confusion of who said what] : :> Actually, NC's are better for intranet apps than PCs. :> :It's too early to tell for sure. If you read some of the articles :at javaworld.com the cost for some of the NCs are actually higher :than a PC--at the outset. May be, but the theory goes that it doesn't realy matter when you count management and other costs into the calculation. Also NC's can drop more rapidly and deaper in price as they do not have the legacy requirements for hardware and software compatibility that the PCs now have. Early adopters report expectations of large savings. : But I'd love to have one server and :several NCs here at my lab at home. The simplicity is so :obvious. But if it works for an intra-net, it obviously will :work for inter-net apps, as long as you have bandwidth. It also :begs the question of setting up replication schemes for internet :apps--will it even be necessary for internet apps as they exist :today, compared with NC-based apps. By some it has been said the NC requires more (even significantly more) bandwith on your LAN for intranet use as well. We should however remember there are ways to avoide that. It may start with simple proxy servers (small black boxes that will not even need a power switch), to harddisks in the NC for caching and probably for local storage. :> NC brings the tool back to being a tool, not a multimedia game :> console with stereo speakers. :> :Now here I have a problem. One the one side I see the point of :keeping the user focused on the work, i.e. a data enry person :doing a travel reservation. But we also have to temper a little :humanity in the workplace. Why do you think Dilbert is so :popular? I think a system with speakers and a few games is :actually a GOOD thing. Well, few managers would agree with you on this one. Anyway you may put your multimedia games, speakers and so on as easily on an NC as on a PC. Intel is allready, in cooperation with Javasoft, out with a multimedia API for Java. The remaining lovers of character terminals should also have pause to think, and X-terminal makers have allready retooled. :> > Also, I don't think Microsoft is scared anymore. Their VJ++ tool and :> > AFC class library shows that they are taking Java seriously although :> > surprisingly, VJ++ can't produce a Windows EXE (yet). :> > . :> VJ++ ? Let me get this straight. You want to take a portable :> language, Java, and add Machine dependant code which makes your :> application less portable? :> :> Hello? Am I the only one who thinks that this is strange? : :No you're not. I agree totally. The VJ++ tool already produces *right now* :applets that don't work correctly without IExplorer. I've removed VJ++ :from my systems because of the mistrust of the usurper. One of the best decisions anyone can do in the Java world. The AFC class library is probably yet more dangerous. Granted you can (still) develop pure Java with these tools, but there is a great risk of easily beeing bound to MS Windows only. The nice think here is that other dev.tools are better and offer more functionality than the MS tools. If you absolutely want you can even develop MS Windows spesific programs with them (i.e. utilizing ActiveX and related techonologies) but in a much more controlled way. You can also rest assured 100% pure Java will remain the main focus. :> The biggest feature of Java is that it is machine independant. :> This way, when I write an app, it will run on any machine. Which means :> I can then buy the hardware best suited to my needs. Sorry but this is still far from the truth. Sun/Javasoft is coming from the Unix side of computing and apparently have all but zero understanding for GUI developments and its requirements. (That's one part of the reason why Unix lost on the desktop.) Witness its AWT catastrophy up until JDK 1.0.2 and it's lackluster fix of it in JDK 1.1. There are also currently (with the 1.0.2 based versions) so many bugs and differences in the Java Virtual Machine implementations that it is hard to say the least to make a GUI based program run deasantly on more than one platform. Even between different JVMs from the same company these problems exists. This will be fixed however. Companies like IBM who have decided that Java shall be one of their most important, if not the most important, development tool (available on all platforms including the mainframes) can't live with such a situation. Their own JVM implementations are reportedly those who realy work well even at the 1.0.2 level. Netscapes IFC may be a saviour for Java as a GUI tool also. Luckily this part of the computing world is on internet time as to speed of developments so it shouldn't take too long to fix the whole situation. If it takes too long though (no solution in sight within a month or two from now) we may have to start beeing carefull. :Your instincts will probably take you away from Microsoft. The one :article I read about NCs noted an average per-user memory requirement of :at least 32 MB, if you use NT as the server. I'm curious to see what it :will be like for UNIX. What on earth is this? Do you mean 32MB per user on the server? What purpose should that possibly serve? If it's on the NC itself I am quite sure it will not require significantly less memory than current PCs, all talk about thin clients notwithstanding. For single purpose NCs there will be cases when you can get away with relatively small amounts of memory, possibly 8 to 16 MB. But memory is cheap. :> > The next couple of years will be very interesting. :> > :> > David : :Indeed. :> #include <std_disclaimer.h> /* Mike Segel (MS385) */ Nils.Myklebust@idg.no NM Data AS, P.O.Box 9090 Gronland, N-0133 Oslo, Norway My opinions are those of my company The Informix FAQ is at http://www.iiug.org