This is part of the experix Reference Manual Copyright (C) 2005, 2006, 2007, 2008, 2009 William Bayard McConnaughey. See the file experix.manual for copying conditions. The installation method that is recommended and outlined here is designed to meet a set of requirements which may conflict at times. Before starting, note that at present experix only runs on i486 or compatible processors due to inline assembly code mainly in the mathematical section. The main program can run on GNU-Linux 2.2.x, but the data acquisition equipment drivers are written for GNU-Linux 2.6.x. The program can run in text mode, but to draw graphs and load bitmaps it needs the accompanying svgaserv program which uses svgalib (or the frame buffer alternative). The help files are written for a modified nano editor. If the graphics server svgaserv is based on SVGALIB, using the mouse to drop text selections onto the experix command line in graphics mode requires a slightly modified gpm (the standard gpm works when the frame buffer based svgaserv is used). If non-root users are to load and unload experix device drivers, modified insmod and rmmod programs are required. The modified sources and build instructions for all of these are in a separate release accompanying the experix release. Web addresses and special installation notes for auxiliary software are given later in this file. These are the considerations that the installation scheme addresses: 1. Each user maintains his own version of the program. If he finds an error he can (if he has the skills) fix his version and get on with his work, without having to wait for somebody else to handle the problem. If he needs a new operator or function he can add it, at the risk of making his applications incompatible with other people's experix versions. He can contribute to experix development by sharing his fixes and additions. Giving each user his own version results in file duplication, which may be seen as waste of disk space, but if the number of users is not large this will not be a strain on any modern system. It also means that two users running their own versions at the same time will not share code, which is a waste of memory. This is unlikely to be a problem because other resource conflicts (data acquisition devices, and physical access to the computer) are likely to prevent multiple users from trying to operate at the same time, and anyway the system can probably handle it. 2. Ordinary users run without root privileges to avoid the danger of system-wide file corruption that can result from errors made by a root process. There are necessary exceptions to this, in order to use svgalib graphics and to load and unload device drivers. This may introduce security holes that a malicious user could exploit. If experix is used in an environment where users know and trust each other, security policies only need to limit the consequences of accidents. 3. Users need to load (insmod) and unload (rmmod) device drivers. Loading the drivers at boot time or providing for automatic loading through modprobe may not give the flexibility that some users need, particularly during development of an experimental system. But disasters will result if users are able to link whatever code they like to the kernel. Therefore, special versions of insmod and rmmod are made available to ordinary users. They only work on drivers (.ko files) in the /experix_dev directory, and only root may write that directory. Users have their own versions of driver code and they can modify and rebuild drivers, but then the administrator needs to put the driver into /experix_dev before the user can try it. This listing shows the experix directory tree, presumably located in a user's account directory, and other experix-related files and directories. These are the general management policies: Keep the distribution directories free of junk, object files and other stuff that is not to be included when experix is shared with other people. The administrator keeps the "official" version in /experix_dev/dist/ and that is available in case a user messes up his own copy. Each user should periodically examine and clean his experix/bin/ directory to prevent accumulation of command logs, fifos left over from broken sessions and any other junk. Be extremely obsessive about documenting all changes to experix and svgaserv programs, drivers, auxiliary programs, command files and anything else. Be hyper-obsessive about documenting the local equipment and all programming associated with it. experix_helpers (root maintains this directory) |-- dist/ tar --> /experix_dev/dist/experix_r4_helpers.tgz2 | |-- gpm/ our changes to gpm | | |-- readme-gpm-wbm explanation of our changes | | `-- (altered sources) the altered source files | |-- nano/ our changes to nano | | |-- readme-nano-wbm explanation of our changes | | `-- (altered sources) the altered source files | `-- module-init-tools/ our changes to module-init-utils | |-- readme-module-init-tools-wbm explanation of our changes | `-- (altered sources) the altered source files | (Please update the version numbers below | when moving to new versions of these programs.) |-- gpm/ archive and build directory of gpm | `-- gpm-1.20.1.tar.bz2 downloaded gpm |-- nano/ archive and build directory of nano | `-- nano-1.2.5.tar.gz downloaded nano `-- module_init_tools/ archive and build dir. of module-init-tools `-- module-init-tools-3.1-pre5.tar.bz2 downloaded module-init-tools /experix_dev/ (root maintains this directory) |-- xinsmod restricted insmod program |-- xrmmod restricted rmmod program |-- pport device special file for the pport demo |-- experix__pport.ko device driver for the pport demo |-- dist/ everything needed for making new experix setup | |-- readme general stuff and news | |-- install copy of experix/book/install (this file) | |-- (If desired, keep copies of individual updated | | files here prior to updating the archives. | | See at end of this file about creating the | | following archives:) | |-- experix_rX_dist.tgz2 archive of experix/dist/ | |-- experix_rX_book.tgz2 archive of experix/book/ | `-- experix_r4_helpers.tgz2 archive of experix_helpers/dist/ | (Drivers might be orgainized into subdirectories for users or for devices.) |-- *.ko experix device drivers |-- device special files |-- scripts related to loading and unloading `-- notes about devices /etc/vga/svgaserv_valid_modes (optional) tells what svga modes are available experix/ (one per user; put it wherever convenient) |-- equipment/ notes, manuals, etc. on local equipment |-- notes notes about this installation |-- todo unfinished business |-- bin/ | |-- gdbc startup instructions for using gdb on experix | |-- pptype executable used with the pport example driver | |-- xpxdtest experix driver tester | |-- svgaserv the graphics server | |-- errs compiler messages | |-- *.o compiled experix source files | |-- experix experix executable | |-- item_list.exp file made by the list command | |-- experixlog* command log file (* is PID) | `-- svgaserv*fifo pipe to the graphics server (* is PID) |-- book/ tar --> /experix_dev/dist/experix_rX_book.tgz2 | |-- install this file | |-- experix.manual intro, contents, general stuff | |-- booktodo unfinished business | `-- * book chapters and supporting material `-- dist/ tar --> /experix_dev/dist/experix_rX_dist.tgz2 |-- readme general information for getting started |-- COPYING GPL license information |-- performance notes on how fast it runs and stuff like that |-- obsolete/ unmaintained but maybe still useful stuff | |-- readme | |-- xpxdtest.c stand-alone program for testing a driver | `-- mapper.c stand-alone program for testing driver memmap |-- into_bin/ things that should be copied to experix/bin | |-- cleanup cleanup script | |-- gdbc startup instructions for using gdb on experix | `-- readme |-- drivers/ | |-- * supporting programs and material | |-- hello/ simple demonstration drivers | | |-- Makefile | | |-- hello.c simple demo | | |-- xhello.c simple demo with memory mapping | | `-- missing.c some functions other drivers might need | |-- pcdas16/ | | |-- Makefile | | |-- experix__pcdas16.c driver for Measurement Computing | | |-- experix__pcdas16.c.old pcdas16, needs updating | | |-- pcdas16.h | | |-- poker_iorec.xpx experix commands for i/o recording | | `-- start_poker.xpx experix commands for starting cell poker | |-- pcm308/ | | |-- Makefile | | |-- experix__pcm308.c driver for the SuperLogics pcm308, | | |-- pcm308.h working now on 2.6.18-1.2798.fc6 SMP | | |-- poker_iorec.xpx i/o recording | | |-- start_poker1.xpx poker number 1 startup | | `-- start_poker2.xpx poker number 2 startup | |-- platform.h general platform-dependent stuff | |-- poker.xpx cell poker data acquisition command file | |-- pport/ parallel port demonstration driver | | |-- notes on removing resource conflicts | | |-- Makefile | | |-- experix__pport.c | | |-- pport.h | | `-- pport.xpx | |-- pptype.c program for exercising the pport driver | |-- prometh/ | | |-- Makefile | | |-- prometh.h driver for "prometheus" 486-PC101 computer | | |-- prometh1.c with daq; needs updating | | `-- prometh1.xpx | |-- das16/ an unfinished driver | | |-- das1602x1.c driver for Measurement Computing DAS1602, | | |-- das160x.h needs updating | | |-- start_poker.xpx experix command file for cell poker | | `-- poker_iorec.xpx experix command file for i/o recording | |-- step.xpx commands for stepper motors (very specialized) | `-- xpxdtest.c stand-alone program for testing a driver |-- hardware/ hardware information of general interest |-- help/ | |-- COPYING GPL license information | |-- *.hlp experix help files for commands and operators | |-- app/ experix application help files | | `-- poker.hlp | |-- keywords.doc program description | |-- nocolor.c for stripping color escape sequences out | |-- sign_on.message program startup message | |-- structs.doc info on program structures (needs update) | `-- tu.experix.hlp tutorial (seriously needs rewrite) |-- maybe_u_need | |--bitops.h /usr/include/asm/bitops.h absent from FC6 | `--config.h /usr/include/linux/config.h absent from FC6 |-- source/ | |-- *.c experix program sources | |-- *.h experix program headers | |-- models/ special-purpose mathematical stuff | | |-- fpr.c fluorescence photobleaching recovery | | |-- fpr.xpx | | |-- fprs.hlp | | |-- zdhist.c Zeiss Confocor raw data analysis | | `-- zdhist.xpx | `-- svgalib/ | |-- *.h svgaserv headers | |-- *.c svgaserv sources | |-- exp_svga.c experix to svgaserv interface | |-- font??.? processed graphics print font definitions | |-- font??.?bak backups of graphics print font definitions | |-- ssfgen.c program for processing the font definitions | |-- svgaserv_valid_modes example mode list file | |-- screen0 -> link to the default screen setup | |-- screen? screen setups | |-- colors.00 color definitions | |-- colors.xpx experix command file for testing the colors | |-- spectra.xpx experix command file for testing the colors | |-- altcolortest miscellaneous things for testing svgaserv | |-- altcolorwrite | |-- stdcolortest | |-- stdcolorwrite | `-- vgatest.c svgalib test program `-- xpx/ experix command files |-- graftrix.xpx some useful graphing commands |-- mathtrix.xpx useful mathematical stuff |-- calculus.xpx some pretty graphing demos |-- arraytests.xpx |-- daq.xpx |-- example1.xpx |-- example2.xpx |-- example3.xpx `-- gtest.xpx Those who expect an out-of-the-box, no-thinking-required installation have to get ready for a disappointment, or wait until things are more settled. There are several reasons for this. At this time, there is and has ever been only one person working on experix. Learning how to create configuration and makefile scripts, and maintain them as ideas change, is not something that he has time for. Such scripts really are indispensible for complicated software systems that are required to behave the same way on many processors and under many different operating systems. That is not the situation of experix now. Development has been done solely on PC platforms with GNU-Linux. Inline assembly nas been used to make functions and operators work with all data types without creating huge switch statements with much duplication and inefficient code. Porting to other platforms will require a huge effort. The installation procedure described here could be massaged into a makefile applicable to PC with GNU-Linux. But makefiles are difficult for experienced programmers, and completely opaque to students who need to concentrate on their projects. If users are to participate in the development, they need a comprehensible overview of the system. That implies a description which would duplicate the makefile in human-readable form. And that creates the burden of maintaining the two in parallel. Furthermore, it tends to fossilize the system, since it is so difficult for most people to figure out how a change they want to try (beyond source code changes) needs to be integrated into the makefile. That should be enough excuses, and it's time to move on to the installation. First we present the steps that the administrator takes to install modified versions of certain other software packages and make the system archive of experix, and other matters that are needed to make it work. For updates, it is convenient to replace individual sources within the dist directory tree and compile only the affected source files. Installation instructions: Shell commands are on indented lines. Replace the release designation "_rX_" and similar with whatever release you are using. We are still using experix_r4_helpers since no changes were made in there. Make the experix_dev directory. mkdir /experix_dev chmod +rx /experix_dev cd /experix_dev mkdir dist cd dist Download the following archives to here: experix_rX_dist.tgz2 experix_rX_book.tgz2 experix_r4_helpers.tgz2 Make the experix_helpers directory and modified utilities. cd /root # or wherever the experix_helpers directory is to be kept mkdir experix_helpers cd experix_helpers tar -xjf /experix_dev/dist/experix_rX_helpers.tgz2 This makes the experix_helpers/dist directory; for each directory within dist, follow the instructions in the readme file found in that directory. In order for the help system to open an editing session in a virtual terminal, the terminal device files need to be accessible by an ordinary user. After building experix (the next section of these instructions), run the program as root and use help requests such as ??def to open editing help sessions. When MAXVT of them (#define in files.c) are open simultaneously, find out which keys they correspond to. Note that the ones which are used probably depends on whether an X-session is running. With no X-session I find that 7, 8, 9, 10 are used; with an X-session, which turns out to be on terminal 7, experix help sessions use vt's 8, 9, 10 and 11. These are the tty numbers that should be made available to ordinary users. For example, if they are 8 through 11, put these commands in /etc/rc.d/rc.local: chmod o+rw /dev/tty chmod o+rw /dev/tty8 chmod o+rw /dev/tty9 chmod o+rw /dev/tty10 chmod o+rw /dev/tty11 (If it is necessary to restrict the number of these, change MAXVT and rebuild.) If changing the permissions on ttys is disagreeable, then either another way must be found such as rewriting the GetHelp function so that it calls a suid root program to get the terminal, or users will have to make do without editing help sessions. Make the experix installation. This procedure is the same whether done by root or a user. Maximum flexibility is designed into this so that, for example, root can change a few files and put them individually into /experix_dev/dist and not bother with re-doing the tarballs until he is sure of the changes or wants to ship an updated distribution. cd (wherever you want the experix directory) mkdir experix cd experix mkdir equipment mkdir bin tar -xjf /experix_dev/dist/experix_rX_dist.tgz2 tar -xjf /experix_dev/dist/experix_rX_book.tgz2 Check /experix_dev/dist/readme and replace individual updated files and do other things that it may indicate. In experix/dist/xpx, experix/dist/drivers, experix/dist/source/svgalib and experix/dist/models, correct the home directory in the first line of every .xpx file. Then add the difference between the new and old lengths of the first line to the number on the second line (if any), so that the "xo######" gives the correct character offset to the first executable line of the file. (This chore is necessary because the shell does not accept '~' in the exec. filepath when experix is started by invoking a .xpx file.) cd /experix/bin cp ../dist/into_bin/* . Build svgaserv as instructed below. Build experix as instructed below. Examine the screen# files in experix/dist/source/svgalib and choose one that uses a video mode that your equipment supports. Make a link, for example: cd experix/dist/svgalib ln -sf screen1 screen0 That makes screen0 --> screen1, so that "experix -g0" starts with graphics set up according to screen1. Build a few auxiliary programs, as described in these files: dist/drivers/pptype.c dist/drivers/xpxdtest.c Build drivers. Each driver has its own subdirectory in experix/dist/drivers, containing the source files, build scripts and any other stuff that should be in the program distribution. Full instructions for a particular driver should be in the source file or Makefile in that driver's directory. For example, the pport demonstration driver is built like this: cd ~/experix/dist/drivers/pport make When the administrator is satisfied that the driver is not dangerous, he puts it in /experix_dev (or a subdirectory thereof) and (if not done already) makes the device special file. For example, mv experix__pport.ko /experix_dev mknod /experix_dev/pport c 42 0 chmod uo+rw /experix_dev/pport The administrator keeps updated archives in /experix_dev/dist for all users to access. The archives are maintained as follows: (replace "_rX_" in the tar commands below with the designation for the next release) --------------archive the modifications to nano, module-init-tools, gpm, etc cd /root/experix_helpers # or wherever it is # Clean up dist/ and ensure that all files in there are up-to-date. tar --one-file-system -cjf /experix_dev/dist/experix_r4_helpers.tgz2 dist --------------archive the experix distribution cd /root/experix # or wherever the up-to-date experix is # Clean up book/ and ensure that all files in there are up-to-date. tar --one-file-system -cjf /experix_dev/dist/experix_rX_book.tgz2 book # Clean up dist/ and ensure that all files in there are up-to-date. tar --one-file-system -cjf /experix_dev/dist/experix_rX_dist.tgz2 dist When the experix directory tree is set up, the program is built as follows (assuming that the experix tree is under $HOME.) Special notes: If using an old compiler such as gcc version 2, struct definitions ending with a line like "int variable_size_array[]" cause an error. It wants to see a '0' in the brackets. To fix it add " -DGCC2 " to the compilation command (see source/structs.h). 0) (This is already done in the unpacked distribution.) If any of the "pictures" in the font files in dist/source/svgalib have been modified, see the notes in svgalib/ssfgen.c and svgalib/svgafont.c, and regenerate the font. Examine svgalib/svgafont.c and ensure that all the font files listed there are up-to-date. Next comes the program build. Problems we have seen are listed later. 1) My preferred graphics setup uses the framebuffer. To build svgaserv this way, see the instructions in dist/source/svgalib/frbflib.c No need to chown it root or chmod it +s, and the un-modified gpm works with it. It takes less time and is much more reliable and faster in vc switches. It can only run properly in the current frame buffer mode, and that cannot be changed except by re-boot on any system I have seen. This is not an issue if the system is booted to the most suitable mode. The 16-bit modes are recommended because they give more snappy vc switching. 1x) If you like the old svgaserv based on SVGALIB, do this instead: cd ~/experix/bin gcc -g -O -Wall -o svgaserv_svgalib ../dist/source/svgalib/svga????.c\ -lvgagl -lvga chown root:root svgaserv_svgalib # root must do this chmod +s svgaserv_svgalib # root must do this ln -sf svgaserv_svgalib svgaserv Compiler switches: -DDEBUG makes a file ./sslog showing all fifo data received (except binary) and whether the command was done or rejected. And it runs really slow. 2) Examine source/amoeba.h and make it include the models that you want. Compile the sources for those models: gcc -c -g -O -Wall ../dist/source/models/*.c &> errs; cat errs Remove from bin the objects for models not being included. 3) Find out which signals svgalib is using for console switching. This is in the libvga.h file. Then look at experix/dist/source/defines.h, the #define SIGNAL_0 and so on, to find out which signals are being used by experix. If there is a conflict, console switching will not work. Either change defines.h, or change libvga.h and rebuild svgalib. But note that there is a command-line option (-u) that allows experix to use SIGUNUSED and SIGPROF instead of SIGUSR1 and SIGUSR2. 4) Compile the experix sources. gcc -c -g -O -Wall ../dist/source/svgalib/exp_svga.c &> errs; cat errs gcc -c -g -O -Wall ../dist/source/*.c &> errs; cat errs Compiler switches: -DMALLOC_END_CHECK=### (used only in updown.c; see) causes malloC() to pad the malloc buffers and then they are checked by freE(); corruption is noted in the experix session log file. This is an extremely limited but useful heap integrity check. -DSUPPRESS_ERROR_10 (used only in errors.c) suppresses the report for errno = 10 (no child processes) which was constantly coming from our buggy spawn code. Also, see under "Compiler issues" below. 5) Link experix. gcc -o experix *.o -lpthread -lm -lreadline -lcurses 6) Build drivers and programs in the dist/drivers directory as directed in the source files there. ----------------------------- build problems ----------------------------- On Fedora Core 6 the file /usr/include/asm/bitops.h did not exist. And it wants /usr/include/linux/config.h which is also gone. I copied them from my kernel 2.6.12 system and put them in dist/maybe_u_need --------------------------- auxiliary programs --------------------------- >> Web addresses for downloading things ftp://arcana.linux.it/pub/gpm ftp://ftp.linux.it/pub/People/rubini/gpm/ http:// or ftp://ftp.schottelius.org/pub/linux/gpm http://svgalib.org http://www.nano-editor.org >> Compiler issues: -- Old compilers might need to have "-DGCC2" added to the command lines for building experix and svgaserv. Grep for GCC2 in the sources to find out what that affects. -- gcc version 4.1.1 has a bug relating to asm statements with the "m" operand constraint. It causes an internal compiler error (inconsistently). Compile with -DGCC4_ASM_M_ICE to work around this. Affected files: FPUmath.c >> Linux Distribution issues: -- The FC6 installation couldn't compile svgaserv and experix because the bitops header is no longer in /usr/include. I intend to fix this properly, perhaps by not using bitops, but for now I have copied the needed files: /usr/src/kernels/2.6.18-1.2798/fc6-i686/include/.... -> /usr/include/.... ..../asm-i386/bitops.h -> ..../asm/ ..../linux/compiler.h -> ..../linux/ ..../asm-i386/alternative.h -> ..../asm/ ..../asm-generic/bitops/fls64.h -> ..../asm-generic/bitops/ -- gpm didn't link because "fceil" was undefined. Need to add "-lm" to the link command. If you know how to fix a Makefile, go ahead; otherwise, see the readme-gpm-wbm file for my method. An alternative, which I have done in the present distribution, is to use an inline version of fceil and thus remove the mathlib dependency. >> There are enhancements to the nano editor: look in experix_r4_helpers.tgz2, the dist/nano directory >> There is a clumsy hack on gpm: look in experix_r4_helpers.tgz2, in the dist/gpm directory. This is needed only to enable dropping selections on the experix command line when svgaserv is based in SVGALIB. >> There are modified versions of some system utilities: look in experix_r4_helpers.tgz2, the dist/module-init-tools directory >> Notes on svgalib-1.4.3: See also book/svgalibnotes This gets more difficult every time the compiler gets upgraded. I hope I can move up to the new svgalib, but first I'll try to make this work. -- in src/driver.h it may be necessary to increase MAX_REGS (I used 5628 but now I don't know where I got that number-- probably from the diagnostic in src/vga.c which prompted this; look there for "MAX_REGS"). -- in src/mach32.c in function mach32_init() after the label "finish_w_eeprom:" add a line with an empty statement, such as just a semicolon, to stop gcc complaint about a label at the end of a compound statement -- in src/vga.c in function initialize() this test: "if ((long) GM < 0)" should be changed to "if ((void *) GM == MAP_FAILED)" -- in src/vga.c in function process_option() the macro ML_GETINT didn't compile. Replace those lines like this: ML_GETINT(HDisplay); becomes ptr = strtok(NULL, " "); if(!ptr) break; mmt.HDisplay = atoi(ptr); -- in src/s3.c in function s3_ext_set() after the label "default:" add a line with an empty statement, such as just a semicolon, to stop gcc complaint about a label at the end of a compound statement -- in src/vgamisc.c the "static" declaration on __svgalib_linearframebuffer caused an error: previous declaration in src/vgabg.h. I have only seen this with gcc 4.1.1. Trying to fix it as follows: remove the extern decl from vgabg.h and put it in all other files that reference that variable; they are: vga.c -- in demos/lineart.c in function screen() put the first printf statement all on one line to get rid of missing terminator error -- in src/apm.c, function apm_saveregs(), compiled by gcc 4.1.1, the last 6 statements before the return caused invalid lvalue errors. Examining the object compiled by gcc 3.4.4 indicates that it ignored "(unsigned long)" and "(unsigned short)". Removing these lets it compile on 4.1.1. WARNING! I don't have this hardware, so can't test it. -- in gl/inlstring.h, function __memset() "movzbl %%al,%%ax" should be "movzbl %%al,%%eax" (anyway that's what gcc 3.3.4 made). Another one that didn't show up before gcc 4.1.1. -- After getting through the make install and make demos, it may be that the libraries are not linked right. In /usr/local/lib do this: ln -s libvga.so.1.4.3 libvga.so.1 ln -s libvgagl.so.1.4.3 libvgagl.so.1 Also might need links in /usr/lib -- On the gNewSense 1.0 system, vgatest executes but makes a blank screen for all modes except that it drew the pattern **once** for mode 10. (Actually, this was on hardware that can't seem to run svgalib at all.) -- On the 2.6.18 system, libvga cannot load. It says "cannot restore segment prot after reloc: Permission denied". libvgagl loads except for unresolved symbols from libvga. When copied to the 2.6.12-emp system, doing ldd -r on libvga generates a floating-point exception, but no message about segment prot after reloc. >> Notes on svgalib-1.9.25: See also book/svgalibnotes -- In building the driver on kernel 2.6.18, it lacked config.h and devfs_fs_kernel.h. On 2.6.12-emp system, config.h merely includes autoconf.h. I copied both files from that system and finished the build. But here's a better way, at least it works in Fedora Core 6: in kernel/svgalib_helper/main.c, change to and comment out the line for . -- The signals that are used for vt switching are chosen in src/libvga.h as SIGUSR1 and SIGUSR2. This is controlled by a "#if 1" statement. To use SIGPROF and SIGUNUSED, change it to "#if 0". Or change experix to use these. -- To use this version, after boot you have to modprobe svgalib_helper. >> Notes on svgalib (both versions) with Fedora Core 6: -- The libraries failed to load. Complained that it couldn't restore segment protection after relocation. Same result from doing ldd -r on the libraries. This was resolved by copying the libraries to a usb thumb drive and setting the soft links in /usr/local/lib to point there. Reports have been made to the svgalib Google group and the redhat's bugzilla. A response from that describes a similar error and attributes it to SElinux settings. A response from redhat advises that the problem is due to non-use of the -fpic flag in compilation. It turns out that the only part where -fpic is not used is lrmi, which apparently only affects the VESA driver (according to remarks found in svgalib discussion forum). This can be used to turn off SElinux: echo 0 > /selinux/enforce But it's probably not a good idea to operate that way on a routine basis. This fixes the permissions on libvga so that it will be usable with SElinux protections in force: chcon -t textrel_shlib_t /usr/local/lib/libvga.so.1.9.25 ------------------ Miscellaneous other stuff ------------------------------ The beagle is a huge time-waster unless you need it. When it's running, it keeps the disk going almost full-time and slows down the system a lot, and it runs for a very long time. It can be stopped by the beagle-shutdown command, but I am tired of that so I am trying this now: Made the directory /etc/taken_out_by_wbm/ for this and similar things, and moved /etc/cron.daily/beagle-crawl-system to there. I installed FC6 in text mode, and it does not automatically start X windows when I boot up. When I want X windows I use startx. This suits me since I work most of the time in text terminals and svgalib screens. When X is started, it automatically tries to update things, which means going over the web to find out what's new and downloading that. This takes a **HUGE** amount of time, and often has to be aborted. And I'm a little bit paranoid about it maybe un-doing some of the changes I have made to things. So I am careful to unplug the ethernet when I start X. Then I get a warning that updates are not being received. I dismiss that, and plug in the ethernet when I need it.