Tuesday, March 31, 2009

java frameworks

I register the term "Java", in only some vague manner, for example encountering a "JavaScript error" when web browsing. Digging deeper, I learned that "Java" and "JavaScript" are unrelated, except in name. JavaScript is the current name of what formerly was called LiveScript. LiveScript was developed at Netscape, the same Netscape now owned by AOL, however the name LiveScript was eventually changed to JavaScript, probably to leverage the (then) popularity of Java. How AOL was not sued by Sun Microsystems, I don't know, since Java was created at Sun Microsystems and its development was, of course, prior to the name change of LiveScript to JavaScript.

Java is a programming language which results in code compiled into executable (binary) programs, in a manner similar to other languages such as "C". Java-written programs require a Java run-time environment installed on the executing computer. Alternatively, JavaScript is only questionably a language and, if a language, then a scripting-type language; it doesn't require compilation. Applications written in JavaScript operate only in a browser (except to write cookies), and are called "applets". Applets require a run-time environment, and this is either built-in to the browser or is a browser plug-in. The user can enable or disable the JavaScript run-time for their browser. For example, a user might encounter a warning that JavaScript has not been enabled on their browser; this refers not to the applet, but to the JavaScript run-time plug-in not being installed/enabled.

As just noted, JavaScript browser applications ("applets") run via a JavaScript plug-in prepackaged inside most browsers. JavaScript applets are difficult to design for all browsers, since each browser (IE, Firefox, Opera, etc) designs its run-time slightly differently. A variance from what that particular browser needs to run the applet leads to the somewhat common "JavaScript error" messages encountered when browsing. This is expected to change as the ECMA eventually standardizes the approach. Another difficulty with JavaScript applets in browsers is security. Applets written in JavaScript operate in limited parameters ("sandboxes") designed to limit access to the user's system. But they've been proven not to entirely deny this access. A nice thing about the JavaScript browser plug-in is it alerts users to necessary updates.

What about the original Java? Java is a language for writing applications that run on the workstation itself, not merely in a browser. For example, you could write a program in Java that edits photos, or documents, etc. Like other compiled programs, Java programs require a runtime environment, but Java was also designed to be cross-platform. That is, the Java concept is to create programs which run inside various operating systems (Linux, Windows, Mac OSx), and platforms (x86, Mac). The software framework of the runtime is what varies for each machine, and this runtime framework is installed first, prior to the program. Once the virtual framework is installed, the Java application may then be installed - the application is supposed to work regardless of the type of machine or OS, since the underlying runtime layer is handling any OS idiosyncracies.

I've found that Java applications do work on anything if the runtime is properly installed. Unfortunately, in my experience at least, Java runtime framework installation is often problematic, so much so that the original reason for this blog page was to refresh my memory for some typical steps. One other note, framework version updates are not typically automatically displayed so that installers must remember to check for periodic upgrades.

The Java Runtime Environment (JRE) is the primary framework for Java-written applications, in a similar way that the Visual Basic Runtime Environment (VBRE) is the virtual machine for applications written in Microsoft's Visual Basic. The latest version of the JRE appears to be called J2SE (Java2 Software Environment). Sometimes J2SE by itself is enough to run a Java-written application, other times, additional Java frameworks have to be compiled and added to J2SE to provide functionality. Some examples: I have Sun's OpenOffice on my workstation. Without installing the Java Media Framework (JMF), a separately compiled framework which relies upon J2SE already being installed underneath it, there is no way I know of for OpenOffice's Impress application (it's like PowerPoint) to playback sound and video. An mp3 addition to the JMF can also be compiled and added. The Java Database Connectivity (JDBC) software first requires J2SE to be in-place. JDBC supports databases such as Neo4j (a graphing database good for tags). There are additional Java environments/frameworks available. Taking all these Java flavors together, the terminology and installation picture appears complicated, and the best overall description I've seen is here. The remainder of this post is hands-on.

Java Media Framework (JMF)

A fundamental problem is the Java Installation site provides ambiguous information. Of course, mere awareness of its ambiguity isn't going to overcome it. In one forum, a guy complained that he spent so long attempting to configure his JMF installation that he decided to return to M$ Windows. That's extreme, but it seems questionable that the JMF installation appears to require a significant underlying understanding of paths, classpaths, and softlinks for software roughly four years old. Installation should be simpler by this point.

Step One: JRE

I haven't yet installed J2SE, so I use the old Java Runtime Environment. It's important to check that it's installed and that it exists in user's and root's path. I checked both of these to be sure, and then just repeated as root:
$java -version
java version "1.6.0_11"
Java(TM) SE Runtime Environment (build 1.6.0_11-b03)
Java HotSpot(TM) Client VM (build 11.0-b16, mixed mode, sharing)

$ echo $PATH
If these don't show up, it's best to check and make sure the JRE path has been exported. For example, check that /etc/profile includes somewhere:
export JAVA_HOME

Step Two unpacking and moving

Download the bin file and unpack it:
$ sh ./jmf-2_1_1e-linux-i586.bin.

It makes a directory like any untar. I rooted-up and moved this entire directory to /usr/lib/JMF-2.1.1e

Step Two: user and root paths

JMF needs to be found on occasion by root and on other occasions by the user. These are two different setups:
1) User: Sun recommends creating a /home/~/.profile file with these entries:
# path settings for JMF
export JMFHOME=/usr/lib/JMF-2.1.1e
export CLASSPATH=.:$CLASSPATH:$JMFHOME/lib/jmf.jar

I like things explicit, so I leave out the "JMFHOME" variable and do it this way:


2) Root: add the same lines, but at the top of /etc/profile.

3) User and Root: Echo the path ("echo $PATH") to be sure that it includes paths to the jmf files. If not, add additional paths as the final lines of the "/etc/profile". For example, I also wanted some X11 bin files in my path, so my final two "etc/profile" lines are:

export PATH

Following this, JMF was working except

Step Three: activate

Easiest: restart the computer so it sources both profiles.

Step whatever - diagnostics

The one good thing Java has done is make an online diagnostics page with which to check the JMF installation. Just point the browser there and it checks my JMF (and JRE). However, checking via the browser in this was seems to confoundingly generate classpath errors, regardless that there aren't any. See below.


Firefox is a separate matter. With JMF properly configured for their workstation, when one visits the online diagnostics page, one will receive an error " classes..".


JMF also has a download to play MP3's.

Monday, March 30, 2009

slackware 12.2 - kernel recompile

Last edited: 2013/05/03
Links: slackware compile simple   good: includes LILO   full Debian   gentoo instructions w/LILO   arch instructions   kernel performance
Kernel builds are straightforward and can be done in user mode in /usr/src/[version]
$ make mrproper
$ cp /boot/config /usr/src/[version]/.config
$ make menuconfig
$ make dep
$ make bzImage (or just "make")
$ make modules
# make modules_install
Recompiles are mostly the same, but we use same source version repeatedly. That is, each recompile uses source with the same version number. That causes a modules problem.

the problem and solution

A problem with using the same version source repeatedly is that modules are installed according to kernel version numbers. The modules go into /lib/modules/[version]. We don't want modules for each recompile overwriting or mixing with the prior recompile. We want a unique directory for each build's modules. How do we do that? We could just change $MOD_INSTALL_PATH, in the Makefile. However, we also need our new kernel to be able to find its modules. A better option then, is to change $EXTRAVERSION to something unique. This will then be incorporated into $KERNELRELEASE, and everything downstream -- the module directory, and pointers to those modules within System.map --- will be properly named and installed. So, before running "make menuconfig", change the top-level $EXTRAVERSION (or occasionally "$EXTRAVER") variable in Makefile to a different suffix for each build. Before running "make", double check the Makefile for your identifier. There is also apparently an option for "local version" suffix creation within the make menuconfig process beginning with kernel 2.6.

Note: to examine the running kernel settings in a GUI without changing the settings, run "make xconfig". This displays the configuration of the booted kernel. Select "discard changes" before exiting. To do the same in an ncurses CLI interface, the command is "make menuconfig" (also discard changes when exiting).

Other - unintended effects

There's a small chance one's video drivers or other hardware will act odd with the new kernel and modules. It's therefore worthwhile to back-up the old modules in case one needs to use the old kernel. If one recompiles GLibC, it's nearly certain some applications will have to be recompiled.

Other - what is /boot/vmlinuz?

When bzImage is created in /usr/src/[version]/arch/i386/and we copy the bzImage to /boot, we change its name. The file is the same, but we change it to "vmlinuz". We also append a suffix to its file name to distinguish it from other kernels in /boot. For example, we might title it "vmlinuz-20120604" or "vmlinuz-test". We add this same suffix to the "config" and "System.map", files for that build when they are copied to /boot.

pre-compile: patches, optimizations, modules

Patches are accomplished prior to opening the configuration files; they potentially expand the kernel options with new features. To patch, put the patch in the same directory as the source, consider the level for "p" (in this example I'll use "1") and:
$ patch -p1 < patchname

For optimizing the kernel, hardware information: # lshw or # lspci. Save this to a file, and print it. For example, I have one older laptop with
    AMD Athlon(tm) X2 Dual-Core QL-60 64 bits, 1900MHz,L1 256 capacity, L2 2x512KB capacity
It appears the processor will be able to run an i686 instruction set (using amd 64 / i686). Instruction sets are backwards compatible to 386,486,586. It's also worth reading here about CFLAGS (SLKCFLAGS for Slackware) CHOST, and so on, for compilation notes, since the compilation of the kernel is just another compile. Also examine these two
$ cat /proc/cpuinfo
$ echo | gcc -dM -E - -march=native
I save march info to the lshw file. Of course, we can adjust the march to something forced, but it's valuable to start with examining what's automatically selected (by gcc).


So "vmlinuz" is simply "bzImage" renamed and copied into /boot. If we compile using the standard make install technique, the vmlinuz file in /boot will be overwritten during that step. Instead, use make (or make bzImage) without "install". Later, we'll manually copy the new kernel, "bzImage" into /boot, changing its name to, say, vmlinuz_20090312 as we do so, and preventing overwrites.
$ make mrproper
$ make menuconfig
$ make dep
$ make bzImage (or just "make")
$ make modules
# make modules_install
Kernel compilation varies depending on the processor speed and the number of cores. See "j" flag options for "make".


Booting requires System.map and vmlinuz. And, each kernel requires its own System.map file. These both need to be in /boot. Also the ".config" file should be placed in /boot for future reference. Make them easy to locate within /boot. Eg, supposing the unique identifier for that build were "20090312", then I would move the files to /boot from /usr/src/linux/) as
# cp /arch/i386/bzImage /boot vmlinuz-20090312
# cp /usr/src/linux/System.map /boot/System.map-20090312
# cp /usr/src/.config /boot/config-20090312
# rm /boot/vmlinuz
# ln -s /boot/vmlinuz-200903312 /boot/vmlinuz

Double check kernels, System.maps, config files and proper softlinks within /boot.


If you're certain about a single kernel, a single softlink named "vmlinuz" to that kernel will work, as just described. LILO needn't be changed. However, if wanting to select between multiple kernels at boot time, LILO needs additional entries. The one we have been doing above would be added as
  label= somenameforscreen
  root= /dev/sda1
  read only
Then to update LILO:
# lilo -v

Appendix - Cleaning source

(courtesy http://linuxgazette.net/111/krishnakumar.html)

After we have initiated compilation once on the source if we want to clean the object files and other temporary files then we have to run the following:
make clean
This will remove most generated files but will keep the configuration file. If we need an absolute cleaning, i.e. if we want to return the source to the state in which it was before we started the compilation, then do a
make mrproper
This command will delete all generated files, the configuration file as well as various backup files. This will in effect unwind all the changes we made to the source. The source after this step will be as good as it was just after the download and untar.

Tuesday, March 3, 2009

toshiba l305d-s5869 - touchpad

Synaptics touchpad fun
Xorg touchpad notes
Disabling synaptics touchpad
Touchpads or, as I call them, "random cursor placement devices" annoy me. Attempting to work on a paper where natural thumb placement means inadvertently moving the cursor from line to random line, or from word to random word, etc, brings a desire to tear-out hair.

1. Synclient In my Toshiba, I have the Synaptics pad and driver, though some will have the ALPS. The command to disable the touchpad:
$ synclient TouchPadOff=1