It turns out that the initial run of nautilus that I did (the one that took me to Eazel's site to view their system config stuff) had not completely died in the face of a crasher, and I had a completely invisible nautilus process spinning in the background.
Obviously nautilus shouldn't ever get into a spin like that, but I've seen various versions of Netscape on Solaris do the same thing when they lose their connection to the X server.. something down in X lib perhaps, or else just convergent buggage.
Anyway, Nautilus under normal operation does not seem to eat the processor when idle, as it appeared to do for me.
On my system, Nautilus eats half the CPU even when it's idle and hid behind another window
or minimized.
I completely understand about needing to do algorithmic optimization for active operations, but when I'm not frobbing the window, the algorithms running should be O(zero), which does not seem to be happening.
As you say, I look forward to seeing what happens with optimizations.
After all, Java does support the final attribute on both methods and classes, and JVM's like HotSpot are perfectly capable of doing extremely aggressive inlining as necessary.
Since Java is a late binding language, you do have to have some intelligence in the JVM to optimize the method resolution when new classes are loaded and compiled, so you still have to pay the link penalty for both virtual and non-virtual Java methods at the time that a class is loaded, but Sun's JVM on Solaris, Windows, and Linux will do the code rewriting during execution to translate final method calls to direct calls without any vtable. I believe it may even be able to optimize virtual methods to direct calls in circumstances where the execution history forces the object pointer to be of a specific type, as in the case where you have a line of code that creates an object of a given type and the next line you call a method on it.. since HotSpot could reasonably tell that at that point in the code that object reference will always be of the specific subtype that was just created, it would be able to just do a direct jump to the method.
I'm speculating here somewhat.. HotSpot may not be quite that smart, but Sun's comments strongly suggest that it does do that sort of path analysis for heavily used code segments.
HotSpot is *extremely* good.. probably a fair distance along the way to optimal, given its ability to do things like deep inlining across several layers when the runtime history indicates that path is very hot. The reason Java code still runs slower than C++ is partially due to the HotSpot overhead and partially due to the fact that the way you write code in Java is often much less CPU efficient than if you were to write code with similar intent in C++.
In C/C++, you would parse a file line by line by constantly re-using a single memory buffer for each line of the file that you read (sizing it up if it overflows, of course). In Java, since Strings are immutable (for thread safety), you wind up creating a new String for each line, plus a new String for just about every subelement that you pull out for further processing. This sort of style is mandated by the fact that so much of the Java class library API's demand real live immutable Strings, and you don't have a choice but to create a bazillion of them in many cases.
With HotSpot, creating new objects off of the heap can be very nearly as fast as stack-based allocation of auto variables in C/C++, but it's just not going to ever be as fast as intelligently re-using a memory buffer. There are many things in Java programming that force that kind of trade-off. The benefit is that you get a lot of aid and encouragement to make your code thread-safe and that it is actually possible to guarantee that an object's private state can't be trashed by anything external to it, never no way no how. A completely reasonable trade, in my opinion, especially in light of the massive portability support provided by Java, but it's not The Answer To Everything, of course.
What you describe is similar to what the OODS team is trying to put together. Their idea is to have a single API for interacting with any kind of data held in a directory-style structure, with the OODS software providing client access, permissions controls, and back-end data store drivers.
They are just at the point of planning and discussing everything.. it's not clear that any signficant amount of code will be written in the foreseeable future, but if you want to join a discussion with people who are working on this sort of thing, check it out.
Right, I agree that WSH is some pretty nice stuff, but so far as I know, Microsoft hasn't completed the picture by shipping out-of-the-box a Perl or Python (or anything even remotely similar) runtime that can be used from the command-line. I know you can write VBA, JavaScript, or VBScript code that interacts with COM, but until that capability is as ubiquitous as the gawdawful.BAT file handling, and doesn't require a GUI application, then all versions of Windows will be really limited.
I want to be able to ssh into a Windows NT system and run a script to interact with the operating system.. create users, synchronize account groups, and the like. Today I have to install a third party RSH/SSH service along with ActiveState's Perl and the Win32::NetAdmin and Win32::AdminMisc modules. It should be possible to script things without any GUI tools on NT today.
And.BAT doesn't even come close to being the same concept as what I'm talking about here, of course.;-)
The biggest source of flexibility in UNIX is
that everything can be manipulated with linguistic
tools. If Microsoft ever ships a truly easy to
use from-the-command-line scripting system that
can easily interact with and manipulate COM objects, they'll have achieved much of the flexibility of UNIX. If they ship Perl/Python,
then they'll have a language rich enough to generate its own hashtables and lists of data that can then be analyzed/treated as if it were a text file, and regexp's and the like will be available to work with their full COM suite.
I've spent almost five years now developing a GUI, object-based sysadmin project for UNIX, and it has taken almost that much time to convince some die-hard UNIX traditionalists here that the very poweful consistency safeguards, error checking, privilege delegation and support for n-user simultaneous editing that it provides was worth giving up the ability to do grep on the passwd file.
I'm with Miguel all the way on this.. something
like COM can mean *more* flexibility, as long as we have good scripting tools that make working at the higher level easy, and as long as the COM-style interfaces are designed with a *lot* of thought towards flexibility and security.
If we get COM-style interfaces that prevent us from doing things that the designer thinks we shouldn't do (such as setting a pre-hashed password for a user account, which NT doesn't provide an API for), then a COM would become a barrier. If the interfaces are designed to be as open as possible while still hiding implementation -specific details and providing safety and error checking, then a COM becomes a tremedous strength.
I sure wish Miguel would have talked some about security, though.
Sun hasn't been able to find its own ass with regards to X window manager integration since around Java 1.1.6. Some not-too-bright Sun programmer hacked their window manager interaction logic to make Java windows pop up pretty under MWM/CDE, and broke Java's window display/placement for every other window manager around.
And, Sun being Sun and Java not being quite Open, they have left this unrepaired for over two years now, despite the blackdown folks fixing it on about day one, as I recall.
So, don't try to pin this one on Gnome, this one is all Sun's baby.
I program in Java and love it lots, but Sun's priorities are not always in complete alignment with mine.
I made a mistake in my response.. while what I said was perfectly true as far as it went, a=a+i would result in a new Integer object being assigned to a, so that wouldn't break thread safety. Integer's immutability would rule out something like "a++;" if it didn't have the same reassignment semantics of "a=a+i".
The fact that you couldn't truly treat an Integer like an int for unary operators is a good argument from trying to treat it like an int for binary operators, but the fact is that James Gosling ruled out operator overloading as a simplification for the programmer's sake, to make code easier to read and less ambiguous. That's the same reason why Java doesn't do the implicit type conversions for objects that C++ can do. You can argue that the simplification hurt more than it helped, but Java programming really does benefit from Java being a simpler, more easy to understand language than C++, and I don't fault Gosling for leaving well enough alone as far as operator overloading.
Well, from reading over the C# docs, I have to say that C# is simply not equivalent to Java. It looks like Microsoft has done some good work on it, but the language is less revolutionary than Java was, and seems less refined in terms of language definition, portability, and security.
It's nice that they have included threading and garbage collection in the language, but this feels a lot more like a Delphi class language than a Java class language/environment. Maybe Microsoft will flesh out a lot more details than they have so far, but right now it just seems like a nice little language that will be more comfortable to program in than C.
It does seem that C# will be a much better systems programming language than Java, of course, and Microsoft deserves praise for that.
Java's applet support was one of the strongest reasons why we wrote Ganymede in Java. I have dozens of users running the Ganymede client applet every day, no problem whatsoever.
Of course, the trick is that those users are required to have the Java 1.2/1.3 plug-in installed on their Windows system so that they can use a full featured applet with Swing and RMI and the rest, or they have to run the applet from a UNIX command line.
In Java, you can actually make a single program that can be run as an application without the sandbox limits, or as an applet with. In Java 1.2/1.3, you can even set sandbox limits on applications or loosen them on applets, with the right configuration set-up and digital signatures.
Java applets make perfectly fine clients for Java servers.
Poorly written Java programs end up locking more than necessary, yes. But 'synchronized' is simply Java syntax for Tony Hoare's monitor synchronization primitive, and it is super easy to build whatever sort of lock or semaphore structure you want out of monitors.
The fact that you can put synchronized on any method of any class is nice because you can easily ensure that a given object is thread safe, but when you've got a large system you really do need to use semaphores and the like to avoid getting into nested monitor deadlike and all of that.
Yeah.. Sun was extremely ambitious in their plans for Swing, and it just isn't all there yet, performance-wise. They are planning on making major improvements to the rendering pipeline for Java2d in Java 1.4 (oh, excuse me, Java 2 Standard Edition Version 1.4 ).
The reason that you can't do a=a+i in Java is that Integers (and Shorts, Longs, Doubles, etc.) were defined to be immutable to provide thread safety.
Remember, Java passes objects by reference, not by value. Having Integer be immutable guarantees that if once you pass an Integer to a method call, that method won't have to worry about the Integer having its value changed in midstream. Otherwise, you could wrap a call to a method that does some kind of sandbox operation in a new Thread() and then possibly change the parameter after the method had verified that the Integer was in an acceptable range.
In general, Java trades not only portability but also and especially security for performance.
Actually, VMS had a quite decent X11 implementation on it, and all our Vaxstations had graphical logins. It had nothing decent like the Windows Explorer, Finder, Workplace Shell or Gnome/KDE, but then neither did any UNIX other than NeXT until recently.
Microsoft has developed a way to write code that addresses the platform in a more direct fashion than Java supports. Bully for them, but Java has those portable characteristics by design, and many of us who program in Java chose it for those reasons.
I haven't read the pdf docs yet, but C# sounds like something very nice for Windows programmers, and something that might allow them to develop for Windows 2k and Windows CE conveniently, and maybe even something that companies with financial relationships with Microsoft will incorporate into their embedded products, but it doesn't sound like something that will chase Java from the market place.
Now, it may put pressure on Sun to rethink their objection to "standardization", but in fact Sun has already done quite a bit to open up their platform. C and C++ needed standardization because their were many, many incompatible implementations and there were features that people felt needed to be added into those languages in a way that would be supported by all the compiler vendors. Java is already standardized due to Sun's investment in the Java Language Specification and through their strict quality control and test suite.
Hm, bit of a digression. Anyway it will be interesting to see how C# does, and whether it really does get use on, say, Linux.
People forget that in the early eighties, back when Microsoft developed software for dozens of different platforms and operating systems, Microsoft did all of their application software on top of a VM-like infrastructure.
Remember Multiplan, Multiwrite, Multifile, etc.? They were written in something resembling p-code, and they had them on Apple II, Apple III, CP/M, TRS-80, C64, Atari, and oh yes, the IBM PC. They did pretty well for Microsoft until Lotus 1-2-3 came along and stomped everything due to its being written in extremely optimized Intel assembler.
Speaking as someone who has written a couple hundred thousand lines of Java code and seen that code work without tweaking, first time, on OS/2 and Macintosh after developing it exclusively on UNIX and testing it on Windows, I have to disagree with this 'almost not cross platform' assertion. Scratch that, I really have to laugh at it.
The trick to cross platform coding with Java is that you have to code to the set of API's that Sun has published and standardized. If you do that, and if you don't fall into a hole that Sun has left in their API's, you're fine. Someone has to define the greatest common denominator of portability, and Sun's been doing a surprisingly good job at that.
I will be very interested to see if Microsoft will even attempt to define a substantial set of runtime API's for the C# runtime or whether they will just provide COM and SOAP and claim that that's good enough while encouraging everyone to use COM-wrapped Win32 to get their work done.
I'm quite looking forward to seeing what Microsoft actually has in this C# and whether they actually have something new and innovative. All the blather about C# not being a response to Java is obvious nonsense, of course.
If Microsoft attempts to duplicate the Java API set with C#, then they will be open to all the same criticisms of platform definition and limited service coverage that Java has been since it was created. If they attempt merely to provide clean access to operating system API's with really decent runtime #ifdef and #include type functionality, so that the same piece of code can conditionally execute sections of code based on the underlying environment, while still sharing the high level logic and providing a Java-like code distribution framework *and* just enough runtime functions like threading and garbage collection, then they might have something which might really swing the pendulum away from Java.
They'd have to standardize it, though, after screaming at Sun for four years about that.
Hi. We have spent the last four and half years working on a system that allows you to manage directory information in a central database, which will propagate network information into various directories (NIS, DNS, LDAP, Samba, Windows NT) when changes are made. Since it's all open source and scriptable, you can tie just about anything you want into your directory services.
See my.sig for a link to Ganymede. We haven't ut out a release for nearly six months, but we've been busy working on it, and 1.0pre1 will be coming out within a couple of weeks with a whole heck of a lot of new features, performance improvements, and bug fixes.
Now that Sun is making their Java plug-in available, the problems with varying Java support in browsers is going away. For Ganymede, we use a hybrid Java applet/application for the client, and it works great on UNIX, Win32 (under Netscape or IE), MacOS, and OS/2.
Applets work just fine as long as you don't get overly ambitious about it, and as long as you keep in mind what an applet is for, and what the constraints of the Java security model are.
I'm not an NSA cryptographer, but unless the NSA knows of some magical math, I don't think the NSA is cracking 128 bit RSA keys (for example) in a few hours, no matter how much computer resources they have.
Am I wrong on this? After all, RC5-64 has taken distributed.net a couple of years of distributed calculations across the Internet to get, what, 15% of the keyspace exhausted by now?
And 128 bits is 2^64 times harder than that.
Once you get the keylength high enough, it quickly becomes pointless to try to do a brute force key search. At that point, you do whatever you have to in order to get your data tap inserted into the processing stream at a point in which the data has already been decrypted.
Now you just need to learn how to translate from geek into proper English.
The term 'lowest common denominator' is almost universally misused. The proper term is 'greatest common denominator'.
After all, the 'lowest common denominator' is, what, ASCII? The concept of a bit? The most full featured standards that are for our purposes universally available would be the greatest common denominator.
I've been working on a directory services management system for over four years now. It works on Linux, BSD, Solaris, AIX, HP/UX.. a fellow here has even got the server running on OS/2. The system's GUI client works on all of the above plus Macintosh and all flavors of Win32.
It's called Ganymede, and it is a metadirectory system, which is to say that it is an object database with a sophisticated permissions system that accepts changes and turns around and updates NIS, DNS, Samba, our NT PDC, our routers, Sendmail, etc.
Ganymede is designed to be a smart server, where the adopter can define their own network schema and write plug-ins that customize how various kinds of objects in the server behave and how they connect to each other. It's all written in Java, so it is quite robust and portable.
It's not designed to replace something like OpenLDAP or DNS or NIS, it's designed to provide sophisticated management for all of the above. At our lab, we have a dozen technical groups that have their own resources, but we share directory services, and Ganymede is what manages the whole show.
It has been a few months since I've made a release of Ganymede, but development hasn't stopped, by any means. Lots of performance and stability improvements on the server have been achieved, and this week I'm writing a Ganymede client that can take XML from external sources (Perl generated, etc.) and load that data into Ganymede. I expect a 1.0pre1 release will come out by the end of the month.
Slashdot Mirror
It turns out that the initial run of nautilus that I did (the one that took me to Eazel's site to view their system config stuff) had not completely died in the face of a crasher, and I had a completely invisible nautilus process spinning in the background.
Obviously nautilus shouldn't ever get into a spin like that, but I've seen various versions of Netscape on Solaris do the same thing when they lose their connection to the X server.. something down in X lib perhaps, or else just convergent buggage.
Anyway, Nautilus under normal operation does not seem to eat the processor when idle, as it appeared to do for me.
On my system, Nautilus eats half the CPU even when it's idle and hid behind another window or minimized.
I completely understand about needing to do algorithmic optimization for active operations, but when I'm not frobbing the window, the algorithms running should be O(zero), which does not seem to be happening.
As you say, I look forward to seeing what happens with optimizations.
After all, Java does support the final attribute on both methods and classes, and JVM's like HotSpot are perfectly capable of doing extremely aggressive inlining as necessary.
Since Java is a late binding language, you do have to have some intelligence in the JVM to optimize the method resolution when new classes are loaded and compiled, so you still have to pay the link penalty for both virtual and non-virtual Java methods at the time that a class is loaded, but Sun's JVM on Solaris, Windows, and Linux will do the code rewriting during execution to translate final method calls to direct calls without any vtable. I believe it may even be able to optimize virtual methods to direct calls in circumstances where the execution history forces the object pointer to be of a specific type, as in the case where you have a line of code that creates an object of a given type and the next line you call a method on it.. since HotSpot could reasonably tell that at that point in the code that object reference will always be of the specific subtype that was just created, it would be able to just do a direct jump to the method.
I'm speculating here somewhat.. HotSpot may not be quite that smart, but Sun's comments strongly suggest that it does do that sort of path analysis for heavily used code segments.
HotSpot is *extremely* good.. probably a fair distance along the way to optimal, given its ability to do things like deep inlining across several layers when the runtime history indicates that path is very hot. The reason Java code still runs slower than C++ is partially due to the HotSpot overhead and partially due to the fact that the way you write code in Java is often much less CPU efficient than if you were to write code with similar intent in C++.
In C/C++, you would parse a file line by line by constantly re-using a single memory buffer for each line of the file that you read (sizing it up if it overflows, of course). In Java, since Strings are immutable (for thread safety), you wind up creating a new String for each line, plus a new String for just about every subelement that you pull out for further processing. This sort of style is mandated by the fact that so much of the Java class library API's demand real live immutable Strings, and you don't have a choice but to create a bazillion of them in many cases.
With HotSpot, creating new objects off of the heap can be very nearly as fast as stack-based allocation of auto variables in C/C++, but it's just not going to ever be as fast as intelligently re-using a memory buffer. There are many things in Java programming that force that kind of trade-off. The benefit is that you get a lot of aid and encouragement to make your code thread-safe and that it is actually possible to guarantee that an object's private state can't be trashed by anything external to it, never no way no how. A completely reasonable trade, in my opinion, especially in light of the massive portability support provided by Java, but it's not The Answer To Everything, of course.
But HotSpot itself is some impressive shit.
What you describe is similar to what the OODS team is trying to put together. Their idea is to have a single API for interacting with any kind of data held in a directory-style structure, with the OODS software providing client access, permissions controls, and back-end data store drivers.
They are just at the point of planning and discussing everything.. it's not clear that any signficant amount of code will be written in the foreseeable future, but if you want to join a discussion with people who are working on this sort of thing, check it out.
Right, I agree that WSH is some pretty nice stuff, but so far as I know, Microsoft hasn't completed the picture by shipping out-of-the-box a Perl or Python (or anything even remotely similar) runtime that can be used from the command-line. I know you can write VBA, JavaScript, or VBScript code that interacts with COM, but until that capability is as ubiquitous as the gawdawful .BAT file handling, and doesn't require a GUI application, then all versions of Windows will be really limited.
I want to be able to ssh into a Windows NT system and run a script to interact with the operating system.. create users, synchronize account groups, and the like. Today I have to install a third party RSH/SSH service along with ActiveState's Perl and the Win32::NetAdmin and Win32::AdminMisc modules. It should be possible to script things without any GUI tools on NT today.
And .BAT doesn't even come close to being the same concept as what I'm talking about here, of course. ;-)
The biggest source of flexibility in UNIX is that everything can be manipulated with linguistic tools. If Microsoft ever ships a truly easy to use from-the-command-line scripting system that can easily interact with and manipulate COM objects, they'll have achieved much of the flexibility of UNIX. If they ship Perl/Python, then they'll have a language rich enough to generate its own hashtables and lists of data that can then be analyzed/treated as if it were a text file, and regexp's and the like will be available to work with their full COM suite.
I've spent almost five years now developing a GUI, object-based sysadmin project for UNIX, and it has taken almost that much time to convince some die-hard UNIX traditionalists here that the very poweful consistency safeguards, error checking, privilege delegation and support for n-user simultaneous editing that it provides was worth giving up the ability to do grep on the passwd file.
I'm with Miguel all the way on this.. something like COM can mean *more* flexibility, as long as we have good scripting tools that make working at the higher level easy, and as long as the COM-style interfaces are designed with a *lot* of thought towards flexibility and security.
If we get COM-style interfaces that prevent us from doing things that the designer thinks we shouldn't do (such as setting a pre-hashed password for a user account, which NT doesn't provide an API for), then a COM would become a barrier. If the interfaces are designed to be as open as possible while still hiding implementation -specific details and providing safety and error checking, then a COM becomes a tremedous strength.
I sure wish Miguel would have talked some about security, though.
Sun hasn't been able to find its own ass with regards to X window manager integration since around Java 1.1.6. Some not-too-bright Sun programmer hacked their window manager interaction logic to make Java windows pop up pretty under MWM/CDE, and broke Java's window display/placement for every other window manager around.
And, Sun being Sun and Java not being quite Open, they have left this unrepaired for over two years now, despite the blackdown folks fixing it on about day one, as I recall.
So, don't try to pin this one on Gnome, this one is all Sun's baby.
I program in Java and love it lots, but Sun's priorities are not always in complete alignment with mine.
You mean:
I made a mistake in my response.. while what I said was perfectly true as far as it went, a=a+i would result in a new Integer object being assigned to a, so that wouldn't break thread safety. Integer's immutability would rule out something like "a++;" if it didn't have the same reassignment semantics of "a=a+i".
The fact that you couldn't truly treat an Integer like an int for unary operators is a good argument from trying to treat it like an int for binary operators, but the fact is that James Gosling ruled out operator overloading as a simplification for the programmer's sake, to make code easier to read and less ambiguous. That's the same reason why Java doesn't do the implicit type conversions for objects that C++ can do. You can argue that the simplification hurt more than it helped, but Java programming really does benefit from Java being a simpler, more easy to understand language than C++, and I don't fault Gosling for leaving well enough alone as far as operator overloading.
Well, from reading over the C# docs, I have to say that C# is simply not equivalent to Java. It looks like Microsoft has done some good work on it, but the language is less revolutionary than Java was, and seems less refined in terms of language definition, portability, and security.
It's nice that they have included threading and garbage collection in the language, but this feels a lot more like a Delphi class language than a Java class language/environment. Maybe Microsoft will flesh out a lot more details than they have so far, but right now it just seems like a nice little language that will be more comfortable to program in than C.
It does seem that C# will be a much better systems programming language than Java, of course, and Microsoft deserves praise for that.
Java's applet support was one of the strongest reasons why we wrote Ganymede in Java. I have dozens of users running the Ganymede client applet every day, no problem whatsoever.
Of course, the trick is that those users are required to have the Java 1.2/1.3 plug-in installed on their Windows system so that they can use a full featured applet with Swing and RMI and the rest, or they have to run the applet from a UNIX command line.
In Java, you can actually make a single program that can be run as an application without the sandbox limits, or as an applet with. In Java 1.2/1.3, you can even set sandbox limits on applications or loosen them on applets, with the right configuration set-up and digital signatures.
Java applets make perfectly fine clients for Java servers.
Poorly written Java programs end up locking more than necessary, yes. But 'synchronized' is simply Java syntax for Tony Hoare's monitor synchronization primitive, and it is super easy to build whatever sort of lock or semaphore structure you want out of monitors.
The fact that you can put synchronized on any method of any class is nice because you can easily ensure that a given object is thread safe, but when you've got a large system you really do need to use semaphores and the like to avoid getting into nested monitor deadlike and all of that.
If you're interested in multithreaded programming in Java, run do not walk to your local book seller and pick up Doug Lea's Concurrent Programming in Java
.Yeah.. Sun was extremely ambitious in their plans for Swing, and it just isn't all there yet, performance-wise. They are planning on making major improvements to the rendering pipeline for Java2d in Java 1.4 (oh, excuse me, Java 2 Standard Edition Version 1.4 ).
Do you have a reference to Mr. Stroustrup's commendation?
The reason that you can't do a=a+i in Java is that Integers (and Shorts, Longs, Doubles, etc.) were defined to be immutable to provide thread safety.
Remember, Java passes objects by reference, not by value. Having Integer be immutable guarantees that if once you pass an Integer to a method call, that method won't have to worry about the Integer having its value changed in midstream. Otherwise, you could wrap a call to a method that does some kind of sandbox operation in a new Thread() and then possibly change the parameter after the method had verified that the Integer was in an acceptable range.
In general, Java trades not only portability but also and especially security for performance.
Actually, VMS had a quite decent X11 implementation on it, and all our Vaxstations had graphical logins. It had nothing decent like the Windows Explorer, Finder, Workplace Shell or Gnome/KDE, but then neither did any UNIX other than NeXT until recently.
Heheheheh.
Oh, wait, were you serious?
Microsoft has developed a way to write code that addresses the platform in a more direct fashion than Java supports. Bully for them, but Java has those portable characteristics by design, and many of us who program in Java chose it for those reasons.
I haven't read the pdf docs yet, but C# sounds like something very nice for Windows programmers, and something that might allow them to develop for Windows 2k and Windows CE conveniently, and maybe even something that companies with financial relationships with Microsoft will incorporate into their embedded products, but it doesn't sound like something that will chase Java from the market place.
Now, it may put pressure on Sun to rethink their objection to "standardization", but in fact Sun has already done quite a bit to open up their platform. C and C++ needed standardization because their were many, many incompatible implementations and there were features that people felt needed to be added into those languages in a way that would be supported by all the compiler vendors. Java is already standardized due to Sun's investment in the Java Language Specification and through their strict quality control and test suite.
Hm, bit of a digression. Anyway it will be interesting to see how C# does, and whether it really does get use on, say, Linux.
People forget that in the early eighties, back when Microsoft developed software for dozens of different platforms and operating systems, Microsoft did all of their application software on top of a VM-like infrastructure.
Remember Multiplan, Multiwrite, Multifile, etc.? They were written in something resembling p-code, and they had them on Apple II, Apple III, CP/M, TRS-80, C64, Atari, and oh yes, the IBM PC. They did pretty well for Microsoft until Lotus 1-2-3 came along and stomped everything due to its being written in extremely optimized Intel assembler.
Everything old is new again.
Yet another uninformed anti-Java rant.
Speaking as someone who has written a couple hundred thousand lines of Java code and seen that code work without tweaking, first time, on OS/2 and Macintosh after developing it exclusively on UNIX and testing it on Windows, I have to disagree with this 'almost not cross platform' assertion. Scratch that, I really have to laugh at it.
The trick to cross platform coding with Java is that you have to code to the set of API's that Sun has published and standardized. If you do that, and if you don't fall into a hole that Sun has left in their API's, you're fine. Someone has to define the greatest common denominator of portability, and Sun's been doing a surprisingly good job at that.
I will be very interested to see if Microsoft will even attempt to define a substantial set of runtime API's for the C# runtime or whether they will just provide COM and SOAP and claim that that's good enough while encouraging everyone to use COM-wrapped Win32 to get their work done.
I'm quite looking forward to seeing what Microsoft actually has in this C# and whether they actually have something new and innovative. All the blather about C# not being a response to Java is obvious nonsense, of course.
If Microsoft attempts to duplicate the Java API set with C#, then they will be open to all the same criticisms of platform definition and limited service coverage that Java has been since it was created. If they attempt merely to provide clean access to operating system API's with really decent runtime #ifdef and #include type functionality, so that the same piece of code can conditionally execute sections of code based on the underlying environment, while still sharing the high level logic and providing a Java-like code distribution framework *and* just enough runtime functions like threading and garbage collection, then they might have something which might really swing the pendulum away from Java.
They'd have to standardize it, though, after screaming at Sun for four years about that.
Interesting times ahead.
Hi. We have spent the last four and half years working on a system that allows you to manage directory information in a central database, which will propagate network information into various directories (NIS, DNS, LDAP, Samba, Windows NT) when changes are made. Since it's all open source and scriptable, you can tie just about anything you want into your directory services.
See my .sig for a link to Ganymede. We haven't ut out a release for nearly six months, but we've been busy working on it, and 1.0pre1 will be coming out within a couple of weeks with a whole heck of a lot of new features, performance improvements, and bug fixes.
Now that Sun is making their Java plug-in available, the problems with varying Java support in browsers is going away. For Ganymede, we use a hybrid Java applet/application for the client, and it works great on UNIX, Win32 (under Netscape or IE), MacOS, and OS/2.
Applets work just fine as long as you don't get overly ambitious about it, and as long as you keep in mind what an applet is for, and what the constraints of the Java security model are.
I'm not an NSA cryptographer, but unless the NSA knows of some magical math, I don't think the NSA is cracking 128 bit RSA keys (for example) in a few hours, no matter how much computer resources they have.
Am I wrong on this? After all, RC5-64 has taken distributed.net a couple of years of distributed calculations across the Internet to get, what, 15% of the keyspace exhausted by now?
And 128 bits is 2^64 times harder than that.
Once you get the keylength high enough, it quickly becomes pointless to try to do a brute force key search. At that point, you do whatever you have to in order to get your data tap inserted into the processing stream at a point in which the data has already been decrypted.
IANAC, of course.
Now you just need to learn how to translate from geek into proper English.
The term 'lowest common denominator' is almost universally misused. The proper term is 'greatest common denominator'.
After all, the 'lowest common denominator' is, what, ASCII? The concept of a bit? The most full featured standards that are for our purposes universally available would be the greatest common denominator.
But that doesn't sound so dismissive, does it?
I've been working on a directory services management system for over four years now. It works on Linux, BSD, Solaris, AIX, HP/UX.. a fellow here has even got the server running on OS/2. The system's GUI client works on all of the above plus Macintosh and all flavors of Win32.
It's called Ganymede, and it is a metadirectory system, which is to say that it is an object database with a sophisticated permissions system that accepts changes and turns around and updates NIS, DNS, Samba, our NT PDC, our routers, Sendmail, etc.
Ganymede is designed to be a smart server, where the adopter can define their own network schema and write plug-ins that customize how various kinds of objects in the server behave and how they connect to each other. It's all written in Java, so it is quite robust and portable.
It's not designed to replace something like OpenLDAP or DNS or NIS, it's designed to provide sophisticated management for all of the above. At our lab, we have a dozen technical groups that have their own resources, but we share directory services, and Ganymede is what manages the whole show.
It has been a few months since I've made a release of Ganymede, but development hasn't stopped, by any means. Lots of performance and stability improvements on the server have been achieved, and this week I'm writing a Ganymede client that can take XML from external sources (Perl generated, etc.) and load that data into Ganymede. I expect a 1.0pre1 release will come out by the end of the month.