Let me correct myself. The JLS obviously does say a lot about threading semantics, just not enough to specify whether threads are even pre-emptive under Java, let alone map to native threads or across processors on an SMP box.
If you are extraordinarily careful and use synchronization primitives with care, you can write code that will function (however slowly/poorly) even in a very limited threading environment.
Optimization cannot be irrelevant. Yes, it would be nice if the Linux OS and JVM scaled in all the same ways as a certain JVM on Solaris or NT does, but that's not realistic. The Java Language Specification makes no guarantees about threading semantics, let alone scaling and performance issues.
Write Once, Run Everywhere works surprisingly well, all things considered, and it's getting better. It's not a panacea, though. You do have to test your software across several JVM's and in various memory, threading, and loading conditions.
All of which you know already, of course. Just don't curse Sun (too much)for not attaining perfection when they've got a better portability story than anyone else does today.
It doesn't surprise me that Java on Solaris would be more stable than Java on Linux. I run my (large!) RMI server app on Solaris under Java 1.2 and under Linux under 1.1.7/8, and it works fine in both places.
Perhaps you are doing very fine-grained RMI object exporting? One thing I learned fairly early on is that it is important not to have all of your RMI objects inherit from UnicastRemoteObject.. if you do that, then your objects are automatically registered for export on creation. Much better to use the static UnicastRemoteObject.exportObject() method to export your Remote-implementing object only when needed.
Actually, now that I think of it, I only actually register a single object in the RMI registry.. my top-level server object. All further RMI activity is done using returned references to RMI-exported objects.
What sort of architecture are you using in your program? Which versions of the JDK have you been seeing problems on Linux with? What version of glibc do you have installed?
A history of being slowest, yes, but Sun's HotSpot dynamically optimizing VM is very nice, competitive or superior to anything else out there, at least for Java 1.2 and greater.
Keep in mind that their are a lot of systems for handling installed software via symlinks, and most of them have unique strengths in particular circumstances. I have a list of many of them at my opt_depot page, including CMU Depot, Stow, Epkg, and several others.
With the exception of Epkg and LUDE, these systems tend to come into play only when it comes time to install and manage installed software on your system and/or network, so it isn't so crucial that everyone use the same software.
Epkg does seem to be one of the best out there now, at least going by the feature list on the Epkg web site. I know that opt_depot is uniquely easy to manage on an NFS network with central package archives, and we and others have been running on it for over 5 years now. I doubt that you're going to get everyone to use Epkg, but it's good to see the work that the UIUC folks are doing on it.
It might not kill them to acknowledge the many alternatives to their software for this very commonly implemented idea, however.
If people are looking for something like STOW, they should take a look at opt_depot. opt_depot is rather more developed than Stow, and includes support for managing package archives in an NFS server environment.
The only downside to opt_depot is that I haven't filed the paperwork to release it under the GPL.. I've been too busy with Ganymede over the last few years to mess with it.
Note that opt_depot itself hasn't been very actively maintained for the last few years, but some folks at the National Library of Medicine are supposedly preparing a new release based on it.
Of course, browsing at threshold 2 makes it impossible for moderators to catch any improperly lowered posts.
Which, it seems, is how the moderation system is biased. Moderators are instructed to concentrate on boosting good articles and wade through the crap to catch stuff that has been unjustly lowered. Unfortunately, there are so many AC trolls now (Don Knotts in Takedown! Woohoo!) that this is a rather unrealistic thing to ask of anyone. And if everyone browsed at 2, good AC posts would remain permanently invisible.
What would such a warranty say? Can you point me in the direction of a vendor who does provide a warranty on their software? Most of the ones I'm familiar with provide a warranty on the physical media, and that's it. You can buy a support contract from Red Hat if you like, which seems to be about the same level of satisfaction and support you can get from any other vendor.
Or am I mistaken?
It might be nice if software vendors offered warranties, or if the US commercial code provided some sort of obligation in that direction, except that in the year 2000 we're not writing software in such a fashion as to be reliable enough for a warranty to mean much. If people were that serious about reliability, I expect software would take 10 times as many resources to produce and cost 10 times as much as it does now.
The guarantee that the software I use is open to me for my examination and that I can turn to any competent developer on the planet to improve the software as needed is about as robust a warranty as can be had.
Yup, very poorly written, as a matter of fact. The program eventually terminated with a memory allocation failure, despite having occasionally reduced its memory loading while running.
The README indicates that they had to take special precautions to avoid having the thing scan itself or its output while operating.. I wonder if they messed that up somehow so it caught in an infinite loop trying to scan its own image in/proc, or something. The logging it performed while running was very minimal.
Well, I am running the tool, and folks should know that it looks as though it is written to keep allocating memory as long as it can.. my system has 128megs of RAM and 256megs of swap, and the find_ddos program has totally exhausted my swap space.
Whatever it's doing, it's doing a lot of it. Be careful not to run it on production systems unless you can stand a bit of a DoS yourself while it runs.
All anyone has to do is whip out their credit card and head on over to www.eff.org and fill out the nice form on their web page with your name and credit card number.
I did it, it really works, it's easy, and all the money you contribute will go directly to them, no muss, no fuss.
Hm, that's an interesting point. I actually think that Sun has long since stopped caring about whether or not Java uses Motif, since all the Swing GUI libraries are almost totally divorced from native widget sets like Motif. The only time you'll see a Java program use any visible Motif object is when you're running an old-skool AWT app.
It seems eminently plausible that a JDK could be produced which used GTK or QT instead of Motif, so long as everything was sufficiently threadsafe.. I know that Sun's Java Bug Parade had lots of Motif-level bugs in early JDK releases.. as long as switching to GTK or QT wouldn't be too big a hit on stability, I'd say great, go for it.
Now, what would be truly sweet would be a set of JNI native classes implementing a GTK or QT Look&Feel for Swing on Linux, especially if the ability to support themeing could be done when running Java Swing stuff under Linux. Given that widgets under Swing are actually drawn using Java bytecodes rather than platform-specific C/C++ code, there would have to be some code that could read theme information out of the GTK/QT environment and render the appropriate widgets using Java graphics code. This might not be too difficult for pixmap-based widget themes, but anything that actually involves C/C++ code for doing algorithmic rendering would probably be very challenging to support for Swing apps.
X Resources and all the splendiferous ways that they can be played with is one of the reasons that The Unix Hater's Handbook described X as having the feature that you could steer with your radio's volume control.. that is, that there were an incredibly large number of ways that users could hack around with running code, for better or worse.
The only really useful thing I saw done with X resources was the old Wcl, or Widget Creation Language, a system that let you specify widgets in a X resource file, and then use a libwcl.a library to load the resource file and create those widgets. This is very similar to what Glade is providing for GTK, except that Glade is based on XML and comes with cool GUI editors and several language bindings.
For general runtime customization purposes, however, I tend to favor the theme approach, even though it does mean that users can't spend days and days hacking X resource files to identify and change the colors of various panels in their X applications so easily anymore.
Anyone interested in reading about Bob Zubrin's plans for Mars, and about all of the plans that people are building around them, so forth and so on, should visit www.marssociety.org, you'll find lots of links to good books on Mars, interviews, video, news, and more.
Robert Zubrin and The Case For Mars
on
On to Mars
·
· Score: 1
Definitely. Dr. Zubrin is big on self-promotion and ego, from reading his books, but he also seems to have developed an honest-to-god viable and sensible approach to Mars, and his approach has been chosen by NASA for their planning.
If humans walk on Mars within the next 20 years, it will be in very considerable part because of Bob Zubrin's work.
I'm afraid I'm not very familiar with internationalization issues with Linux.. how well established is Unicode and localization support on Linux? Are there web pages dedicated to it? How does one find out?
I know Java has support for internationalization and localization (Unicode + a system for using resource files for messages), but it still depends on having national fonts on the system it is installed on. Do any of the JDK ports for Linux come with a full set of Unicode fonts for XFree86? Does XFree86 itself have Unicode support?
I have to disagree.. X is wonderful, X is great, but X doesn't have any sort of advanced graphics system or printing API, which Quartz (and Display Postscript before it) have in spades. There's nothing in X to support arbitrary affine transformations on other X windows/image components, and nothing for doing anti-aliasing, nothing for doing multi-colored fonts, etc., etc. The Gnome folks are doing a super job of implementing those things in Gnome libraries, but doing that means that they've got to pump a *lot* more data over the network to the X server.
That's why Java 2 is having to do pixel-by-pixel and/or pixmap based imaging operations to do all their fancy stuff. It turns out that if you run a Java 2 application over X on a network, performance sinks to unusability. NeWS may have died, but I would love to see X support plug-in rendering modules so we could implement something like the Java 2 Graphics2d or Quartz renderers on the far side of a network.
If you're talking about a LinuxConf-style tool, then yes, scaling breaks down quickly, and you're far better off with a cfengine-based utility, the way that Christopher Browne was suggesting.
For a network of systems, though, you can have very good tools for managing a directory database that all the systems can consult for their networking operations, and this can be a big win.
Exhibit A: Ganymede, a GPL'ed metadirectory system I've been working on for the last four years.
The example I gave showed a simple configuration in both one possible XML format and one possible HSI format. Just because it was a simple example does not imply that either format is limited to only simple cases. You seem to be implying that while XML is not so limited, that HSI is. This is absolutely not true.
So HSI can represent recursive trees? I confess to not having seen anything in the way of documentation for the HSI format.
But as long as GUI based tools fail to allow every possible configuration the way I want it, then I need to stick with the tool (my swiss army knife which consists of both vi and emacs) that does let me do what I need to do to make things work. And I therefore need to stick with a reasonable file format that is oriented to human editing.
I don't know about you, but I use vi and emacs for editing my web pages, in HTML. XML is, if anything, simpler and more consistent than HTML. Is XML the easiest possible format to edit by hand? No, perhaps not, but it's not that hard, and it provides absolute consistency of structure across any imaginable hierachical or linear structure, with full specification of character encodings, Unicode, structural layout, etc.
In addition, people are defining RPC/RMI systems that use XML to define their remote object calls.. XML documents and document fragments are completely encapsulable in another XML document, so it would be possible to use these standard systems to send a description of a change to be made to any other sort of XML file quite easily and naturally, using the same code/tools.
If XML were something absolutely horrible for hand-editing, I'd agree, no way, let's not put that burden on people. But for many things it would be *very* nice to have a consistent format that can be easily manipulated by tools as well. And don't think that I'm saying that 'tools==GUI tools'. Perl comes with a very nice XML parser these days that makes it quite easy to examine and manipulate a deeply structured XML file.
Finally, I'd say consider XML because it is so well standardized.. XML doesn't have that much of an advantage over a lisp/scheme-like file format, except that it is standardized and it is easier to work with for humans.
The thing you have to remember is that XML was specified by people who are really and truly experts in the whole area of text/document markup and processing.. XML is deeply specified, down to the character encodings, nesting rules, and schema definition. There are a whole bunch of good parsers already existing for it, as well as databases that are designed to store XML in a format that can be easily scanned, and more.
The person who said that XML is too general to be useful is correct, as far as that goes.. the mere fact of XML-encoding is analagous to the mere fact of ASCII-encoding, but it is more structured and detailed than that.
XML is just fine for config files because it can express much more detailed and involved relationships than could be expressed with the simple format you propose, but it may not be the easiest thing to read or hand-edit, depending on the way the file is laid out. So? As long as the config file formats are specified well enough that tools can deal with the file, what do you care?
Slashdot Mirror
Let me correct myself. The JLS obviously does say a lot about threading semantics, just not enough to specify whether threads are even pre-emptive under Java, let alone map to native threads or across processors on an SMP box.
If you are extraordinarily careful and use synchronization primitives with care, you can write code that will function (however slowly/poorly) even in a very limited threading environment.
Optimization cannot be irrelevant. Yes, it would be nice if the Linux OS and JVM scaled in all the same ways as a certain JVM on Solaris or NT does, but that's not realistic. The Java Language Specification makes no guarantees about threading semantics, let alone scaling and performance issues.
Write Once, Run Everywhere works surprisingly well, all things considered, and it's getting better. It's not a panacea, though. You do have to test your software across several JVM's and in various memory, threading, and loading conditions.
All of which you know already, of course. Just don't curse Sun (too much)for not attaining perfection when they've got a better portability story than anyone else does today.
It doesn't surprise me that Java on Solaris would be more stable than Java on Linux. I run my (large!) RMI server app on Solaris under Java 1.2 and under Linux under 1.1.7/8, and it works fine in both places.
Perhaps you are doing very fine-grained RMI object exporting? One thing I learned fairly early on is that it is important not to have all of your RMI objects inherit from UnicastRemoteObject.. if you do that, then your objects are automatically registered for export on creation. Much better to use the static UnicastRemoteObject.exportObject() method to export your Remote-implementing object only when needed.
Actually, now that I think of it, I only actually register a single object in the RMI registry.. my top-level server object. All further RMI activity is done using returned references to RMI-exported objects.
What sort of architecture are you using in your program? Which versions of the JDK have you been seeing problems on Linux with? What version of glibc do you have installed?
A history of being slowest, yes, but Sun's HotSpot dynamically optimizing VM is very nice, competitive or superior to anything else out there, at least for Java 1.2 and greater.
Keep in mind that their are a lot of systems for handling installed software via symlinks, and most of them have unique strengths in particular circumstances. I have a list of many of them at my opt_depot page, including CMU Depot, Stow, Epkg, and several others.
With the exception of Epkg and LUDE, these systems tend to come into play only when it comes time to install and manage installed software on your system and/or network, so it isn't so crucial that everyone use the same software.
Epkg does seem to be one of the best out there now, at least going by the feature list on the Epkg web site. I know that opt_depot is uniquely easy to manage on an NFS network with central package archives, and we and others have been running on it for over 5 years now. I doubt that you're going to get everyone to use Epkg, but it's good to see the work that the UIUC folks are doing on it.
It might not kill them to acknowledge the many alternatives to their software for this very commonly implemented idea, however.
If people are looking for something like STOW, they should take a look at opt_depot. opt_depot is rather more developed than Stow, and includes support for managing package archives in an NFS server environment.
The only downside to opt_depot is that I haven't filed the paperwork to release it under the GPL.. I've been too busy with Ganymede over the last few years to mess with it.
Note that opt_depot itself hasn't been very actively maintained for the last few years, but some folks at the National Library of Medicine are supposedly preparing a new release based on it.
Of course, browsing at threshold 2 makes it impossible for moderators to catch any improperly lowered posts.
Which, it seems, is how the moderation system is biased. Moderators are instructed to concentrate on boosting good articles and wade through the crap to catch stuff that has been unjustly lowered. Unfortunately, there are so many AC trolls now (Don Knotts in Takedown! Woohoo!) that this is a rather unrealistic thing to ask of anyone. And if everyone browsed at 2, good AC posts would remain permanently invisible.
Something needs to be done.
What would such a warranty say? Can you point me in the direction of a vendor who does provide a warranty on their software? Most of the ones I'm familiar with provide a warranty on the physical media, and that's it. You can buy a support contract from Red Hat if you like, which seems to be about the same level of satisfaction and support you can get from any other vendor.
Or am I mistaken?
It might be nice if software vendors offered warranties, or if the US commercial code provided some sort of obligation in that direction, except that in the year 2000 we're not writing software in such a fashion as to be reliable enough for a warranty to mean much. If people were that serious about reliability, I expect software would take 10 times as many resources to produce and cost 10 times as much as it does now.
The guarantee that the software I use is open to me for my examination and that I can turn to any competent developer on the planet to improve the software as needed is about as robust a warranty as can be had.
And, why are they wrapping the wires in plastic tubing? What are they trying to hide? ;-)
Yup, very poorly written, as a matter of fact. The program eventually terminated with a memory allocation failure, despite having occasionally reduced its memory loading while running.
The README indicates that they had to take special precautions to avoid having the thing scan itself or its output while operating.. I wonder if they messed that up somehow so it caught in an infinite loop trying to scan its own image in /proc, or something. The logging it performed while running was very minimal.
A for effort, now let's see something that works.
Well, I am running the tool, and folks should know that it looks as though it is written to keep allocating memory as long as it can.. my system has 128megs of RAM and 256megs of swap, and the find_ddos program has totally exhausted my swap space.
Whatever it's doing, it's doing a lot of it. Be careful not to run it on production systems unless you can stand a bit of a DoS yourself while it runs.
Or so I assume, at least. I certainly couldn't get to it. Wound up buying my Palm Developer's Book straight from O'Reilly instead. ;-)
All anyone has to do is whip out their credit card and head on over to www.eff.org and fill out the nice form on their web page with your name and credit card number.
I did it, it really works, it's easy, and all the money you contribute will go directly to them, no muss, no fuss.
I sent them my $100. Should have done it a long time ago, hopefully not too late.
Hm, that's an interesting point. I actually think that Sun has long since stopped caring about whether or not Java uses Motif, since all the Swing GUI libraries are almost totally divorced from native widget sets like Motif. The only time you'll see a Java program use any visible Motif object is when you're running an old-skool AWT app.
It seems eminently plausible that a JDK could be produced which used GTK or QT instead of Motif, so long as everything was sufficiently threadsafe.. I know that Sun's Java Bug Parade had lots of Motif-level bugs in early JDK releases.. as long as switching to GTK or QT wouldn't be too big a hit on stability, I'd say great, go for it.
Now, what would be truly sweet would be a set of JNI native classes implementing a GTK or QT Look&Feel for Swing on Linux, especially if the ability to support themeing could be done when running Java Swing stuff under Linux. Given that widgets under Swing are actually drawn using Java bytecodes rather than platform-specific C/C++ code, there would have to be some code that could read theme information out of the GTK/QT environment and render the appropriate widgets using Java graphics code. This might not be too difficult for pixmap-based widget themes, but anything that actually involves C/C++ code for doing algorithmic rendering would probably be very challenging to support for Swing apps.
X Resources and all the splendiferous ways that they can be played with is one of the reasons that The Unix Hater's Handbook described X as having the feature that you could steer with your radio's volume control.. that is, that there were an incredibly large number of ways that users could hack around with running code, for better or worse.
The only really useful thing I saw done with X resources was the old Wcl, or Widget Creation Language, a system that let you specify widgets in a X resource file, and then use a libwcl.a library to load the resource file and create those widgets. This is very similar to what Glade is providing for GTK, except that Glade is based on XML and comes with cool GUI editors and several language bindings.
For general runtime customization purposes, however, I tend to favor the theme approach, even though it does mean that users can't spend days and days hacking X resource files to identify and change the colors of various panels in their X applications so easily anymore.
Anyone interested in reading about Bob Zubrin's plans for Mars, and about all of the plans that people are building around them, so forth and so on, should visit www.marssociety.org, you'll find lots of links to good books on Mars, interviews, video, news, and more.
Definitely. Dr. Zubrin is big on self-promotion and ego, from reading his books, but he also seems to have developed an honest-to-god viable and sensible approach to Mars, and his approach has been chosen by NASA for their planning.
If humans walk on Mars within the next 20 years, it will be in very considerable part because of Bob Zubrin's work.
I'm afraid I'm not very familiar with internationalization issues with Linux.. how well established is Unicode and localization support on Linux? Are there web pages dedicated to it? How does one find out?
I know Java has support for internationalization and localization (Unicode + a system for using resource files for messages), but it still depends on having national fonts on the system it is installed on. Do any of the JDK ports for Linux come with a full set of Unicode fonts for XFree86? Does XFree86 itself have Unicode support?
If you want a lot of good commentary on the MacOS X interface, check out Ask Tog for his detailed critique of the Aqua interface as demo'ed by Steve.
I have to disagree.. X is wonderful, X is great, but X doesn't have any sort of advanced graphics system or printing API, which Quartz (and Display Postscript before it) have in spades. There's nothing in X to support arbitrary affine transformations on other X windows/image components, and nothing for doing anti-aliasing, nothing for doing multi-colored fonts, etc., etc. The Gnome folks are doing a super job of implementing those things in Gnome libraries, but doing that means that they've got to pump a *lot* more data over the network to the X server.
That's why Java 2 is having to do pixel-by-pixel and/or pixmap based imaging operations to do all their fancy stuff. It turns out that if you run a Java 2 application over X on a network, performance sinks to unusability. NeWS may have died, but I would love to see X support plug-in rendering modules so we could implement something like the Java 2 Graphics2d or Quartz renderers on the far side of a network.
If you're talking about a LinuxConf-style tool, then yes, scaling breaks down quickly, and you're far better off with a cfengine-based utility, the way that Christopher Browne was suggesting.
For a network of systems, though, you can have very good tools for managing a directory database that all the systems can consult for their networking operations, and this can be a big win.
Exhibit A: Ganymede, a GPL'ed metadirectory system I've been working on for the last four years.
XML integration coming soon. ;-)
Actually, they are specifying a namespaces standard for XML which will allow you to mix different DTD's without confusing what tag belongs to who.
So HSI can represent recursive trees? I confess to not having seen anything in the way of documentation for the HSI format.
I don't know about you, but I use vi and emacs for editing my web pages, in HTML. XML is, if anything, simpler and more consistent than HTML. Is XML the easiest possible format to edit by hand? No, perhaps not, but it's not that hard, and it provides absolute consistency of structure across any imaginable hierachical or linear structure, with full specification of character encodings, Unicode, structural layout, etc.
In addition, people are defining RPC/RMI systems that use XML to define their remote object calls.. XML documents and document fragments are completely encapsulable in another XML document, so it would be possible to use these standard systems to send a description of a change to be made to any other sort of XML file quite easily and naturally, using the same code/tools.
If XML were something absolutely horrible for hand-editing, I'd agree, no way, let's not put that burden on people. But for many things it would be *very* nice to have a consistent format that can be easily manipulated by tools as well. And don't think that I'm saying that 'tools==GUI tools'. Perl comes with a very nice XML parser these days that makes it quite easy to examine and manipulate a deeply structured XML file.
Finally, I'd say consider XML because it is so well standardized.. XML doesn't have that much of an advantage over a lisp/scheme-like file format, except that it is standardized and it is easier to work with for humans.
YMMV, of course.
The thing you have to remember is that XML was specified by people who are really and truly experts in the whole area of text/document markup and processing.. XML is deeply specified, down to the character encodings, nesting rules, and schema definition. There are a whole bunch of good parsers already existing for it, as well as databases that are designed to store XML in a format that can be easily scanned, and more.
The person who said that XML is too general to be useful is correct, as far as that goes.. the mere fact of XML-encoding is analagous to the mere fact of ASCII-encoding, but it is more structured and detailed than that.
XML is just fine for config files because it can express much more detailed and involved relationships than could be expressed with the simple format you propose, but it may not be the easiest thing to read or hand-edit, depending on the way the file is laid out. So? As long as the config file formats are specified well enough that tools can deal with the file, what do you care?