Big jump from win98 to antix.
Successfuly got m8.5-486 to work quite well on a no-brand AMD k6, about 400 MHz, 256 meg ram, on a diddly little 3 Gig hd. It did not recognize a serial mouse (orig. eqip. with this thing, yes the mouse does work elsewhere), so swapped in a a pci usb card and usb mouse, works fine.
Also have had no problems with m8.2-m8.5-686 versions on PII's with 128meg ram, yes anti can.
If I can find a K5 and/or PI, with enough ram, will try it out.
Repeat, big jump, especially for hardware pulled out of the garbage.

For the serial mouse to work, try this (in /etc/X11/xorg.conf):

- for a two button mouse -for a mouse with scroll

drg, thanks for the feedback. I'd really like some feedback on the 486 kernel antiX-iso and how/if it works on k5/PI so if anyone can test , please do and let me know.

dear anti, no joy on two PIs I found. Lesser one is P133/32M ram (I know), but this one gave me a grub menu, obviously for really lesser PIs. You can press tab for options avail. in this grub, only one (I forget which) gave me detailed info on the ram available, and the rest were errors or telling me ya need the kernal for that. Greater one was a P166/64 ram, and all I got was something like"starting stage 2" in the post messages, and freeze-up after a long wait. So, no boot up, will try to find more ram. Already found that these ram chips (edo, right?) are not interchangeable, ie finicky with matching up, I gather they must be installed in pairs. No K5s in sight. Would you like specs on any of the machines I play with, lemme know, will gladly do so.
edit - These were using the Live CD.

Missed this, sorry.

Yes, give the specs. If you can set up a swap partition before booting the livecd, maybe it will get further. I use an old DamnSmallLinux cd to do this. Even so, it still may not boot.

Hello! For me 8.5 is an improvement. The previous versions would not run on this PC i pulled from the back @work. Its a HP Pavilion 6645C. P2/3 Celeron 550 W/188mb. ram. Video card is a Voodoo3 W/32mb. This mach. has the 810 chipset that some distro's have a hard time with. Anyway, i am using this here"Live". Everything (i use) opens up and runs, BUT, runs VERY slow. Yet, no freezing or hick-up. Conky says 21-25% CPU usage and 112mb usage of 188mb memory. It also says kernel 2.6.32.1 and wonder what kernel the i686 is running? Weren't"older kernels" more suited to"older hardware" ? I'm thinking the speed will pick up with installation and swap.
Off Topic--Everyone has a different idea what"older hardware" is. And, i think there is a difference between a PC hobby, and using a PC as a tool. I have noticed that in Baja MX. there are people who can afford an ISP as a monthly expense, and there are those who cannot. Those who cannot afford, do not have a PC and those who can afford an ISP can also afford a PC that is 4-5 years old or better. Is that the same observation where you are? mike

mike, do you have a swap file? If you don't and try to run the livecd, it will definitely be slow with 188MB RAM.

Once installed, and if you want to experiment, you could try installing an old kernel and see if it works any better.

Where I am, the 'culture' is to use the 'latest and greatest' and throw away everything else, and those that cannot afford a PC, go without. Sad, but that's the way capitalism works.

Hello mike, being it a PII or PIII it can run the 686 version. As anti said you can set up a swap partition, install it and then uninstall some uneeded things that run services at start up time. This topic may help something: antix-8-5-full-startup-services-t2299.html

If the cpu in a Socket 7 is by definition a Pentium I, then I successfully installed antix-85-486 on two PI’s.
1- Pentium MMX 200MHz; Family 5, Model 4, Stepping 3, Bios Award ver 4.51 PG PCI/PNP 586 1997; ATI mach 64 VT (after install I upgraded to ATI Radeon 7000 pci, the extra video memory made big difference in gui performance, with the Mach 64 the mouse cursor used to hang or disappear totally, and also would sometimes be dumped out of the gui into the console); 128 M PC133 (this thing has both slots for PC133 and EDO simm's); the Live CD booted up and installed onto the original 3Gig hd OK.
2- Pentium 166; Family 5, Model 2, Stepping 12 (Pentium Classic); AMI bios date 07/15/95; Trident video card; 64 Meg EDO ram; for this one I used the antix hd created by the MMX, slower but works, same problem with serial mouse; will not boot from live CD, get only"starting stage 2 starting stage2", yes repeated twice.
On both computers conky reported 30 Meg ram use after full boot up. I haven't tried using too many programmes at once, so don't know yet how performance is when swapping really kicks in. But have been kicked out of gui a few times.

anti, I just found your 'hardware specs' thread.

A question re the mouse problem: any suggestions for a programme which can make keyboard keys substitute for the mouse? Thanks secipolla for code on serial mouse, tried it but still does not recognize serial mouse (not p/s2 type).


EDIT- found xkbset from debian works ok as a keyboard-mouse, can't figure out all its features yet, help doesn't help enough.


drg@tiX1:~$ inxi -F
System: Host antiX1 Kernel 2.6.32-1-mepis i586 (32 bit) Distro antiX-M8.5-486 Marek Edelman 11 April 2010
CPU: Single core Pentium MMX (UP) cache 0 KB flags (-) bmips 401.61 clocked at 200.454 MH Pentium MMX 200MHzz
Graphics: Card ATI Radeon RV100 QY [Radeon 7000/VE] X.Org 1.6.5 Res: 1024x768@0.0hz
GLX Renderer Software Rasterizer GLX Version 2.1 Mesa 7.7.1-DEVEL Direct Rendering Yes
Audio: Card Failed to Detect Sound Card!
Disks: HDD Total Size: 11.2GB (77.9% used) 1: /dev/hda QUANTUM FIREBALL ST3.2A 3.2GB
2: USB /dev/sda USB_Flash_Drive 8.0GB
Partition: ID:/ size: 2.7G used: 1.5G (58%) fs: ext3 ID:swap-1 size: 0.30GB used: 0.00GB (1%) fs: swap
Info: Processes 81 Uptime 31 min Memory 68.7/121.6MB Runlevel 5 Client Shell inxi 1.4.9

anti, are these details enough for your use?

Those codes are for serial mouse but nowadays I don't know how much /etc/X11/xorg.conf really takes care of these things. Some observations:
- it's said one must move around the mouse for some time for the system to detect it.
- you should make sure /dev/ttyS0 is the right device.
Other things you may try: I found this one saying to add the line"Option"ZAxisMapping""4 5" to activate the scroll wheel if available (but it can be added anyway because it's ignored if there's no scroll wheel).
Note EndSection at the end, I missed it in the examples I posted earlier.
This configuration is from Kurumim Linux a late Brazilian distro that was very good in its hardware support.
Other links:

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://www.mepis.org/node/347"
linktext was:"http://www.mepis.org/node/347"
====================================


========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://www.faqs.org/docs/Linux-mini/3-Button-Mouse.html"
linktext was:"http://www.faqs.org/docs/Linux-mini/3-Button-Mouse.html"
====================================

re mousing on the Pentium MMX 200 :

Thanks sepicolla. However, those codes aren't working for this little box. Been playing around with variations.

NB: there are three ports involved here, com1 (ttyS0), com2 (ttyS1) and a ps/2 (/dev/psaux). All are the type whose connectors are um.. connected to the motherboard via wires eg ribbon cable, ie not soldered"onboard". Serial mouse is a Microsoft two-button ball type, ps/2 is also Microsoft wheel type, both work smoothly using damnsmalllinux or win 95, and I am clear which one is which. Am currently using USB pci card with USB mouse, but not everybody has that around for a PI.

Have success with xkbset from debian (25kB file), which provides mousekeys using the numeric pad, and also trying keynav from debian. With usb, mouse cursor stutters or stops briefly, but not a lot, ie tolerable for me. Still, getting all working withmore or less original equipment is preferable though a good video card is important, the gui performance is really stressed.

Oddly, have twice got warning message come up to effect that somebody or something may be trying or has tried to"grab the mouse", perhaps for nefarious reasons. If/when that comes up again, I'll write it down. Could this be an attempt by the xorg.conf, with whatever variation of the codes you gave me, to do some grabbing? Oh, there is no networking involved here, no modem, no ethernet card, they don't even exist on the MB.

Hi drg, I'm a noob so to speak. Just a normal user.
I have those tips specially, as I said, from the guides that were written for Kurumim Linux. The developer also wrote Linux guide books so it was very well documented (and maybe most Brazilian Linux users started with it).
Now I'm testing a Puppy and can't find all the pages I had seen.
One thing I'm seeing is that for a PS/2 mouse one can initially try then if it doesn't work, use which is the proper entry for PS/2 mice with wheel. The"PS/2" protocol was for older PS/2 mice without wheel.

Also in the beginning of the file there used to be (because xorg.conf has changed a lot these days) a line like or"USB Mouse" or"PS/2 Mouse". It's said that a PS/2 mouse should work even if xorg.conf has"USB Mouse" in there but for a serial mouse it must be like in the example above.

An example of the mouse section for a PS/2 mouse The Option"Resolution""800" line should enter only if the mouse pointer is too light and difficult to control, otherwise remove it.

These are mouse types with what protocols they are for, from GPM, the mouse daemon, version 1.2.4-3.3 as in antix-4.5-486.
From a terminal as root type gpm -m /dev/ttyS0 -t protocol help

Thanks again sepicolla, and for hangin' in there with me on this project. No joy yet. I wonder if kernel 2.6, gpm and/or xorg not talking together quite right. Found an article online, don't know the url so I'm quoting it. Could be out of date, and nothing to do with antix itself. IMO, this issue is important if you want people to try using PI's/K5's with such uptodate software as antix. Also, I find I am getting quite used to the slower speeds, esp with loading programmes from HDD, fond even. Damnsmalllinux works quite fast, but the choices are very limited. ttfn Ta Ta For Now.

Quote:
Table of Contents
• Introduction
• Background
• The Driver
• Argument against kernel-space mouse drivers
Introduction
This page is about my first non-toy Linux device driver. It's purpose is to provide the /dev/psaux device, which was in Linux pre 2.6 kernels. Since version 2.6, this device has been removed. The developers think that everyone would be satisfied with the new input layer, rendering /dev/psaux useless. However, I don't think so. At least, the touchscreen on my Laptop does not work anymore after moving to Linux 2.6. Fortunately, I still kept the kernel image and modules of version 2.4 in the Laptop, and I have configured LILO to be able to boot both. So, I immediately reboot back to 2.4. (This is what everyone should do when upgrading the kernel. Don't delete the old one. Keep it around — it doesn't take up much disk space, given that 40GB disks are now so cheap. For that tiny cost, you've got the invaluable chance to go back.)
Background
One of the annoying things most early migrants from Linux kernel 2.4.x (or even 2.2.x?) to 2.6.x would encounter a problem: The mouse doesn't work any more!? Thanks to a major change from kernel 2.4 to 2.6 — the introduction of the so called ``the input layer'', old gpm and XFree86 settings don't work anymore.
In most cases, this can be cured by changing the configuration files of XFree86 and gpm to use the new /dev/input/mice virtual device instead of the old /dev/psaux (or /dev/ttySn for a serial mouse). What's nice with the new input layer is that it now allows multiple mice (and keyboard, too) to be used attached to the PC and the kernel now combines the input events from all the mice into a single stream of mouse events and repeats it to /dev/input/mice. A nice feature considering some plug&play input devices such as USB mice.
There are also drawbacks, and unfortunately, these drawbacks are very observable. It is unfortunate that behaviour of the mouse is so visible that a slight change would be more noticeable than a change in many other parts of the kernel. Other than having to change the config files of XFree86 and gpm, another big surprises for users is that the mouse pointer on the screen now moves fast or too slow. This is because the kernel now processes the mouse data and recalculates it in the way it thinks is better. This is not that bad, given that you can tune it with certain kernel or module parameters. It is just annoying to have to fix it, when the old thing was not broken on the Linux 2.4.x kernels in the first place.
Moving the mouse driver into the kernel?
With the Linux 2.6 kernel, the developers have moved a function that used to run in userland in pre 2.6 kernels into the kernel. It is the interpretation of various mouse protocols (Mousesystems, PS/2, and various extensions of PS/2 to support wheel mouse, touch-pads and touch-screen). If you use gpm, it is basically this userland program that is now moved into kernel space. For those who are used to configuring XFree86, that means its mouse driver is now moved into kernel. Have a look in linux-2.6.*/drivers/input/mouse and compare the filenames with ``gpm -t help'' and you'll grasp what I mean. The mouse protocols are now interpreted in kernel space!
So, what's wrong then?
A quick comparison of the list of files in linux-2.6.*/drivers/input/mouse and ``gpm -t help'' should have already given you some hints. The kernel as of this writing still supports just a few mouse protocols, whereas gpm has been supporting dozens of protocols for many years. So, what to do with devices that uses a protocol that is not supported by the kernel? Should you just wait for the kernel developes to write a driver for your device? It'd be nice if you could use gpm or the appropriate XFree86 driver like in the old days. But the kernel developers have excluded such a possibility.
In my case, it happens to be the touchscreen on my Fujitsu Lifebook B142 Laptop (see Jörg Hau's and Justin Cormack's pages about this Laptop). It also has a touch-point. The touch-point and touch-screen together emulates a PS/2 mouse. When activated with some magic command sequences sent to the mouse port (i.e. device node /dev/psaux), the touch-screen function is enabled and it now uses a PS/2 extension protocol to give the touchscreen data. The extended protocol is propreitary, but is relatively simple to work out. Throughout the years, many people have discovered the protocol, and written drivers for both gpm and XFree86 to make use of this touchscreen (see Harald Hoyer's gpm and XFree86 3.x driver and Kenan Esau's XFree86 4.x driver). I'm of course no exception. I wrote an XFree86 4.x driver for it. It communicates with the device via the /dev/psaux device.
After moving to Linux kernel 2.6, the touch-screen works no longer. I spent some time searching the Web to see why. OK. I need to load the modules mousedev and psmouse (if not already compiled in) to get a /dev/psaux device. Wow! But when I tried it, I was disappointed that it doesn't work with my touchscreen. It can only handle the PS/2 mouse emulation that the device does. It can't enable the touchscreen functions. How about writing a program to enable that function? No... that won't work. The kernel mouse driver in 2.6 must interpret the data received from the mouse port. It doesn't understand the propreitary protocol of my touchscreen (yet). For this reason, what the kernel now spits out to /dev/psaux is a censored sequence of data. The touch-screen-specific things can't get through.
Of course, it'd be fun to write a kernel-space device driver to support this touch-screen (see Kenan Esau's lbtouch module). But why have they done away the old /dev/psaux? I believe I'm not alone in this planet facing such a problem. Anyone who uses a device connected to the mouse port and uses a protocol not yet supported by the kernel will suffer. The old /dev/psaux device in pre-2.6 kernels did allow me to directly talk to the device. (It provides the mechanism, but lays down no policy.) The mouse driver runs in user space, whether it's gpm or XFree86, and talks to the device directly via /dev/psaux. Why not keep it in 2.6, so that the devices using protocols not yet supported in kernel space can still be driven in user space, using the old programs? That's why I wrote this psaux driver.
Updates
Neil Brown mentioned in the Linux Kernel Mailing List (LKML) that he also hacked direct access to the /dev/psaux port. He wrote a userland program to talk to that port directly, and then re-feed the interpreted input data into the kernel's input layer via the uinput facility.
NEW: usespace replacements of the atkbd and psmouse modules
Eventually, I've ported the two kernel space input drivers atkbd and psmouse to user space. Those interested can download atkbd.c or psmouse.tgz and have a try. They require the SERIO_USERDEV patch to gain direct access to the PS/2 keyboard and mouse ports. (For simplicity, PS/2 keyboards are the same as AT keyboards.) Moreover, they are still in alpha stage. Expect bugs, etc. (But bugs in userland programs can't bring down the whole OS __{{emoticon}}__ , unless some OS bugs are triggered (e.g. select()ing on the uinput char device created by the uinput module.)
In my opinion, this is the way the input layer should be implemented. The raw device ports should be left freely accessible by daemon programs running in userland. The interpretation of the input protocols should be implemented in daemon programs, which then re-feed the interpreted data to the input layer, which then provides a unified interface for other programs to access the input events. Implementing the protocols in userland daemons offers many advantages, such as more flexibility in the protocol interpretation code (e.g. emulating the wheels with the keyboard's scroll-lock?), ease of development and debugging, getting virtual input events from TCP connections, etc. It is plain wrong and inflexible for the kernel to dictate how it the input ports (e.g. PS2 mouse port) should be used.
The Driver
This driver, named ``psaux'' creates a device node with major number 10, minor 1 in Linux kernel 2.6. This device is conventionally named /dev/psaux in pre-2.6 kernels. If you're using devfs, then it appears as /dev/misc/psaux.
With this device node, mouse drivers that works on pre-2.6 kernels would work again in 2.6 without changes (subject to my bugs, of course). E.g. my home-brewed XFree86 for my Laptop works again with this psaux module. I can keep my old XFree86 configurations, and do not have to wait for someone to write a driver for it in kernel space.
New development: SERIO_USERDEV
NEWER!!!
Tuukka Toivonen took the idea further and came up with the SERIO_USERDEV patch (dated 2004-06-03), which was posted to the LKML. In this patch, my psaux code plus Tuukka's improvements has been reimplemented as linux/drivers/input/serio/serio-dev.c to provide more functionalities. In particular, it is now possible to implement keyboard and mouse drivers in user space. See my userspace atkbd and psmouse drivers for details. Tuukka and I have polished the code to remove many early bugs or undesirable behaviours. We also thank our testers, who helped us test the patch on various hardware that we do not possess.
SERIO_USERDEV provides a user-space interface to not only the PS2 mouse port (/dev/misc/isa0060/serio1), but all ports that are handled by the serio module (cat /proc/misc for a complete list after loading the patched serio module). The patch was developed for Linux 2.6.5, but I've personally tested it on 2.6.6 and 2.6.7-rc1, too.
Development of psaux has since stopped, with the time and energy devoted to SERIO_USERDEV instead. SERIO_USERDEV is a more general method of providing direct port access to PS2 mouse as well as keyboard. This patch has also been reported to work with multiplexed PS2 mouse ports, found on some recent hardwares (esp. notebooks with stocking stations).
Tuukka Toivonen's improvments on psaux
Tuukka Toivonen has taken my code and made some improvements on it. I admit that he is a better Linux kernel hacker than I am. (I'm just a beginner anyway.) His version include the following improvements:
• Some bugs were fixed, most importantly SMP bugs.
• Added a ``minor'' option, which makes the psaux module cope better with mousedev's psaux emulation.
• The module can be compiled separately without patching the kernel source code. (An intact kernel build tree is still needed — a ``feature'' of the 2.6 series of kernels.)
Some minor difference from my module (for those who have been using my version):
• If you're using devfs, the name of the device is now /dev/misc/psaux_direct instead of /dev/misc/psaux.
• The option psaux_nodebug has been replaced by debug.
My Old Code
NEW!!! Please use the SERIO_USERDEV patch, initiated by Tuukka Toivonen. I consider my own psaux deprecated from now on (2004-04-19).
The file drivers/input/misc/psaux.c contains the code. To compile it, you still need a modified drivers/input/misc/Makefile file and a modified drivers/input/misc/Kconfig file to configure the kernel to compile it. Alternatively, apply the patch file ``patch-2.6.2-psaux'' to kernel version 2.6.2. It is reported to work with 2.6.3, and it also compiles with 2.6.0, 2.6.1, 2.6.4. It may also work with other versions in the 2.6 series. However, it is still well tested on SMP kernels and systems. If you are encountering problems when you use this driver on SMP systems, please first try again with a non-SMP kernel (or boot your kernel with the option ``nosmp'' or ``maxcpus=1''). I would of course like to make it SMP-correct. However, I do not have an SMP system to try the driver with. So, your help would definitely be needed.
After applying the patch to the Linux kernel source code, or putting the above files into it directly, do a ``make config'' (or ``make menuconfig'' or ``make xconfig''). Click the configuation item ``Device Drivers/Input device support/Misc/Compatibility `/dev/psaux''' to compile it as a module (tested) or into the kernel (not tested). In addition, the existing mouse driver also emulates a /dev/psaux which conflicts with my module. You have to disable that feature. Edit .config and disable the entries INPUT_MOUSEDEV_PSAUX by commenting out that line. Now, do what you would normally do to compile the kernel (e.g. ``make'').
After booting the new kernel or loading the psaux module, you can access the mouse port again with the device node /dev/psaux. If that node is not there already, make it with the command ``mknod /dev/psaux c 10 1''. If you're using devfs, the device node /dev/misc/psaux should already be there. Now, you can start gpm or XFree86 in the old way. __{{emoticon}}__
Known issues (or bugs)
Thanks to all those who have reported bugs and helped me found fixes or workarounds.
• Gruber Bernhard found that of psaux does not work with SMP kernels. Since I have no multiprocessor machines to play with, I cannot correct this problem right now. His workaround was to disable SMP in the kernel. This is OK because his machine is actually a uniprocessor one.
• Gruber Bernhard also encounters another problem that I cannot reproduce. He gets some kernel error messages (something to do with semaphores) when the X server starts and terminates. (He runs tp4d in the background.) Despite that, the module works for him.
• Ivan Popovski has found that the psaux module does not work correctly on devices capable of multiplexing the PS/2 mouse port. You have such a device if dmesg says
• i8042.c: Detected active multiplexing controller, rev 1.1.
or something like that. Don't be disappointed. By disabling the multiplexing feature of the PS/2 port, my psaux module works again. How?
o If the psmouse is loaded as a module, use the"i8042_nomux=1" parameter when you load that module.
o Most people would have compiled-in the psmouse driver, because the i8042.c also drives the keyboard. In that case, use"i8042.nomux" as a boot parameter.
Arguments against kernel-space drivers
Finally, I'd like to conclude by presenting my arguments against the current approach of the Linux 2.6 kernel to move mouse drivers into kernel-space.
First, one important principle of a successful OS design is to separate policies from mechanism. One of the factors of the success of unix is that it follows this principle very closely. E.g. it provides a mechanism for you to name files (in the filesystem code), but doesn't impose a policy on how the files should be named (other than using ``/'' as the directory separator and ASCII NUL (0) as the name terminator. This allows flexible file naming schemes, only limited by the users' imaginations (and practical implementation limits, of course.) Contrast this with the 8.3 filename of DOS! Or the base_name.extension;version naming scheme in VMS. Now, what happens to the mouse drivers? In pre-2.6 kernels, the kernel drivers are minimal: they only provide a mechanism for userland programs to communicate with the mouse-like device. There is even no policy imposed on what protocols should be used for this communication channel. Mouse drivers such as those gpm or XFree86 use this mechanism to implement the various protocols (the policies) used by the devices. The principle of separation of policy and machenism is followed. On the other hand, kernel 2.6 now moves the drivers into kernel space. The kernel now not only provides a mechanism for programs to interact with the device, but also imposes a policy on what protocols should be used. Other protocols are not allowed. (They could be added, but not effortlessly.)
Every technical people know why Windows NT is so unstable. One (of the many many) reason is that the GUI — Graphical User Interface — runs in kernel space. (This is equivalent to implementing XFree86 and the KDE/Gnome desktop as kernel code.) Since kernel code executes in special (but dangerous) environment that allows the code to access (and abuse) many other parts of the system, bugs (such as using wrong pointers) can spread to other parts of the system easily. It is agreed (other than by Microsoft) that the kernel should be kept as simple and small as possible. Anything that can be implemented in userland without significant loss of efficiency should be implemented in userland. This keeps the kenel small and simple, making it less easy for problems to spread out. Userland programs are run in a protected environment, which does not allow the program to touch other parts of the system. So, when a process in unix crashes, it won't hang the whole system. Other processes and the kernel still keep on going without problems. Now what is with the mouse drivers in kernel 2.6? The approach is to move them from userland (e.g. gpm) into the kernel. I can't see any advantage of doing that. There is no performance problems with mouse drivers in gpm or XFree86, because the volumn of data passed between the device and the driver is very small. Yes, the new input layer in the kernel allows several mice to be used concurrently. But gpm has been able to do that for a long time. (See the -M option of ``man gpm''.) Since it can be done in userland (by gpm) without performance problems, it shouldn't be moved into the kernel. The only advantage that I can see in implementing mouse drivers in kernel space is for embedded systems. But why forgo gpm, with it dozens of already maturely implemented mouse drivers, with fresh kernel code? (It is non-trival to port the gpm drivers into kernel code. Kernel programming is different because kernel code runs in a different environment. Debugging is also more challenging when developing kernel code.)
In a nutshell, I consider it to be a backward development for the Linux kernel 2.6 to move mouse drivers from userland into the kernel.
Updates
Since Tuukka Toivonen posted his version of psaux module (which is an updated version of mine) on the Linux Kernel Mailing List (LKML), an interesting debate about the design of the Input Layer in 2.6 kernsl has started.

Last updated $Date: 2004/06/03 11:40:26 $ (UTC)

Re: Installing antix45-486 onto P166 with 64 meg EDO ram using livecd.

Some success doing so, got as far as the beginning part of icewm, ie a bluescreen with mouse cursor and the, whatever it's called, the bar at the bottom, but no icons on the desktop, as yet. This would be just before conky comes up. Also no response to Ctrl-Esc, the keyboard shortcut to invoke the menu.

Changed the CD Rom drive to"newer" one in case it has been a matter of reading the livecd better. Used Smart Boot Manager boot floppy to start up the live CD, in the boot options I chose Failsafe plus cheatcode timeout=10, and it started off. Took anti's a advice to try a HDD with a swap already on it, 1 Gig as try out, but I can't tell if any swapping was going on, but it got this far in about 20 minutes. At the start of the process, I noticed that:"memory available= 59184kB, memory available 3670kB", ie about 40M ram avail. for the install, if I understand that correctly. Am letting it run for another hour or so, need to go for bike ride.

anti, is there some way of getting to a more lightweight WM from the livecd, if it exists on the cd, enough of a gui for the installer to work? Minstall from a level 3 install option just wants a gui, it told me. Please, could a non-gui installer be made up for 8.5-486?