☰
Publisher's description
openMosixview is the next version and a complete rewrite of Mosixview.
openMosixview is the next version and a complete rewrite of Mosixview. It is a cluster-management GUI for openMosix-cluster and everybody is invited to download and use it (at your own risk and responsibility).The openMosixview-suite contains 8 usefull applications for monitoring and administrating openMosix-cluster.All parts are accessable from the main application window. The most commonopenMosix-commands are executable by a few mouse-clicks. An advanced executiondialog helps to start applications on the cluster."Priority-sliders" for each node simplifying the manual and automatic load-balancing.openMosixview is now adapted to the openMosix-autodiscovery and gets allconfiguration-values from the openMosix /proc-interface.What's New in This Release:· openMosixview-1.5 is now adjusted+tested to compile+run fine on : Redhat 7.2, Redhat 7.3, Redhat 8.0, Redhat 9.0, SuSE 8.2, Mandrake 9.1, Debian 3.0, Gentoo (latest), Slackware 9.0,...to be continued· It is also tested to compile ok against any QT-version from 2.3.x up to 3.x.x no matter if QT is compiled with or without threads (libqt libqt-mt)· this release is a great clean-up of openMosixview.· The complete "autoconf" is removed !! and replaced with static Makefiles. Here are the reasons why:· openMosixview will run on openMosix system only.· It will only run on IA32 (or IA64 later) as openMosix too.· No need at all to adapt the whole compile-environment to e.g. other architectures.· openMosixivew just depends on a C-compiler and QT, nothing more.· "autoconf" makes it depended to many other stuff e.g. the autoconf version. I do not like that.· the openMosixview applications are all just a few C++ source files and the "autoconf" generates i guess about 50-100 not needed files for each application. I do not like that.· there are just about 5-10 lines to execute for compiling an openMosixview-application, not 500 as with "autoconf"· to my mind it is much easier to manage about 5 Makefiles than to fight with (or against) the "autoconf"· it is much more transparent with static Makefiles· errors are much more easy to detect and i can help better if somebody has probs with it.· read more about the autoconf-trouble at : //freshmeat.net/articles/view/889/· the openMosixmigmon now works together with the "miggroup" feature in the openMosix kernel. You can now select multiple processes by a "mouse-draw" (hold mouse button one pressed and move the mouse) and then migrate complete groups of processes to remote nodes. Each "miggroup" (max 10 in the GUI) has a diffrent color so you will know easily where your groups are migrated to.· a "first idea" of a new openMosix monitoring application was added : the openMosixpidlog. It is a small application which can be "attached" to any running process and it will show the most serious data + information about it. ...... and it is not yet finished. Any ideas + wanted features are welcome as usual.· fixed the "font bug" so now all text in the openMosixview applications should be displayed correctly on any linux distribution.· commented out the "buildfont" function in the 3dmosmon which causes crashes on some libglut versions. No text is displayed any more but it works much safer now. If you would like to run it (test it) with the text-display you can un-comment line 50 in 3dmon/3dmosmon/barmanager.cpp and re-compile. ... also i noticed the sometimes the "base field" is not displayed correctly (if you see it you will know). If this happens to you try to compile it against another glut-version, this helps in my testing. I really "love" this 3d-applet and that is the reason why it is still "in" openMosixview until Johnny Cache has has "the next generation" of the 3dmosmon ready ;)· reduced the use of tmp-files in the openMosixview applications (thanks to Jeremy Weatherford for sending a patch)· the openMosixmigmon now displays only "migrateable" processes.· fixed problem in openMosixprocs+openMosixmigmon to display all processes whith their correct