Forum member ‘JustGreg’ has been doing a lot of work investigating how to get USB pen drives to boot reliably. Here are some forum threads on this topic that he has contributed:

http://murga-linux.com/puppy/viewtopic.php?t=25676
http://murga-linux.com/puppy/viewtopic.php?t=25808
http://murga-linux.com/puppy/viewtopic.php?t=25872
http://murga-linux.com/puppy/viewtopic.php?t=26591

I was reading through JustGreg’s and others posts to get up to speed on the subject, when I suddenly remembered a utility that I had looked at ages ago, and I even remembered its name: ‘makebootfat’. This is a very interesting little program: it can create a kind of universal USB pen drive that can boot from any of the BIOS settings, USB-FLOPPY, USB-HDD or USB-ZIP. It can create a drive with a partition but which also appears to the BIOS as a superfloppy for old BIOSes that can only boot with USB-FLOPPY. I tested it, so far only on a 512MB Flash drive and it worked. Note, it uses some files from Syslinux.

Anyway, I ran into a problem: my ‘probepart’ script did not recognise the filesystem of the partition, and this traces back to Jese’s ‘guess_fstype’ returning “unknown” filesystem. However, ‘fdisk -l’ and ‘disktype’ both detect the filesystem ok (it was FAT16). Perhaps the fact that it looks like both a partition and a superfloppy confuses guess_fstype, as you can see from disktype:

# disktype /dev/sda
--- /dev/sda
Block device, size 490 MiB (513802240 bytes)
DOS/MBR partition map
Partition 1: 490.0 MiB (513785856 bytes, 1003488 sectors from 32, bootable)
  Type 0x06 (FAT16)
  FAT16 file system (hints score 4 of 5)
    Volume size 489.8 MiB (513638400 bytes, 62700 clusters of 8 KiB)
    Volume name ""
FAT16 file system (hints score 3 of 5)
  Volume size 489.8 MiB (513638400 bytes, 62700 clusters of 8 KiB)
  Volume name

Jesse will no doubt figure out what the problem is, but in the meantime I have put a workaround into my probepart script. If guess_fstype fails, the script falls back to trying ‘fdisk -l’, which solves my immediate need to detect FAT12, FAT16 and FAT32 filesystems created by the makebootfat utility.

This fixed probepart is now in Dingo, but Puppy 3.02 developers may want it also. I have uploaded it here:

http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-3.02alpha1/

There is a problem that affects Dingo built with the 2.6.21.7 kernel (same kernel as used in Puppy3). For the 2.6.24 kernel I used Squashfs version 3.3 — this includes a kernel patch for the ’squashfs.ko’ module and the ‘unsquashfs’ and ”mksquashfs’ utilities.

Puppy4 (Dingo) can be built with the older 2.6.21.7 kernel, but it’s squashfs.ko module is version 3.2r2. The problem is, if a .sfs file is created with the 3.3 version of ‘mksquashfs’ then the older kernel can’t open it. This situation has occurred with the “devx” file.

I have solved the problem by repatching and recompiling the 2.6.21.7 kernel with Squashfs 3.3.

What has surprised me is I recompiled the kernel in Dingo, but all the old modules still work and load without complaint, although they were compiled in Puppy3. Normally the kernel is very sensitive that kernel and modules be compiled with the same C compiler and glibc versions.
All I did was replace the old squashfs.ko with the new one, also replaced vmlinuz.

Squashfs 3.3 creates significantly smaller .sfs files. I built the Dingo .iso live-CD file with Squashfs 3.2, which has been the situation up until now, and it was 85.08MB. After replacing the kernel and squashfs.ko, I built the .iso file and it was 84.02MB.

This fix is for Dingo only, not required for Puppy3. Although, I suppose you could, as Squashfs 3.3 kernel module can open .sfs files created with an older ‘mksquashfs’.

I have uploaded the 2.6.21.7 kernel source patched with Squashfs 3.3 to here (courtesy of Ted Dog):

http://puptrix.org/sources/kernel-2.6.21.7-dingo/

I created ‘puppy-unleashed-3.02alpha1.tar.gz’ which is my first go at the successor to Puppy 3.01. This tarball is available from ibiblio. Forum member ‘tronkel’ has been working further on this and has recently uploaded 3.02alpha2, see this forum thread:

http://murga-linux.com/puppy/viewtopic.php?t=26517

I enquired as to how he would make available his latest Unleashed, and it was suggested that it would be nice if there is some way that he could just upload the changes only. That would mean he wouldn’t have to do a huge upload, with the problem of hosting it somewhere.

Ok, I had a go at writing a couple of scripts to do the job. The first is ‘diff-create’. Tronkel can use this to create a tarball that only has the differences between his ‘puppy-unleashed’ directory and my original ‘puppy-unleashed-3.02alpha1.tar.gz’. He can then upload this, and someone else can download my original tarball, expand it, then download Tronkel’s “difference-tarball” and then merge it — and I created ‘diff-merge’ to do that.

‘diff-create’ is pretty easy to use. You need to have your development ‘puppy-unleashed’ directory, my original tarball, and the script, all at the same place, that is in the same directory. Then you just execute:

# ./diff-create puppy-unleashed-3.02alpha1.tar.gz

Voila, you get a tarball with just the differences, and with appropriate naming, for example ‘puppy-unleashed-diff-3.02alpha1-3.02alpha3.tar.gz’.

Soneone else can download my ‘puppy-unleashed-3.02alpha1.tar.gz’, expand it (tar -zxf puppy-unleashed-3.02alpha1.tar.gz), which expands into a directory ‘puppy-unleashed’. Then download Tronkels “difference-tarball”, then execute:

# ./diff-merge puppy-unleashed-diff-3.02alpha1-3.02alpha3.tar.gz

Get these scripts from here:

ftp://ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-3.02alpha1/

Note to Tronkel: backup ‘puppy-unleashed’ first, in case ‘diff-create’ has a bug! Also, you need a lot of free space in the partition, 5GB suggested.

I did the compile with T2 again. Previously, Xorg was compiled with DRI disabled, which causes a problem when we want to add a DRI PET package later. I enabled DRI and this required adding ‘xf86driproto’, ‘libdrm’ and ‘glproto’ packages to the T2 build.

I then updated the ‘xorg_base-7.3′ PET package with the recompiled files and renamed it to ‘xorg_base-7.3-1′. I then created a new package, ‘xorg_xorg_dri-7.3′ which (hopefully) has just enough extra files to add DRI and GL support. Kirk has previously created a package, ‘xorg_xorg_full_dri-7.3′ which adds DRI and GL but it also adds everything else, the full Xorg package, and is about 54MB uncompressed. The xorg_xorg_dri-7.3 package is 19MB uncompressed.

The development components of ‘xf86driproto’, ‘libdrm’ and ‘glproto’ were added to the ‘devx’ file.

I have not yet tested xorg_xorg_dri-7.3. Note that kirk also created ‘xorg_xorg_full_dri_DEV-7.3′ PET package, which can be installed to provide all the extra include/pkgconfig/la/a files needed to compile against the extra libraries provided in xorg_xorg_full_dri-7.3 (and xorg_xorg_dri-7.3). The ‘devx’ file just has the basic files for compiling against the xorg_xorg_base-7.3 package (which suits most applications).

When I backported the Dingo scripts to 3.02alpha1, I forgot about PCMCIA.

Puppy3 uses the 2.6.21.7 kernel which was configured not to support the new ‘pcmciautils’ system for handling PCMCIA and instead uses the old ‘pcmcia-cs’ package. The problem is that the bootup and shutdown scripts from Dingo did not recognise the old pcmcia-cs system. I have now fixed that.

I modified /etc/rc.d/rc.modules, /etc/rc.d/rc.shutdown and re-introduced /usr/share/pci-usb-pcmcia.ids. The first two are scriptsand these now seemlessly handle pcmcicautils or pcmcia-cs. If pcmcia-cs is used, then the pci-usb-pcmcia.ids database file is also required.

I have uploaded these files to:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-3.02alpha1/

So, presuming that you have already downloaded and expanded the ‘puppy-unleashed-3.02lpha1′ tarball, which expands in a directory ‘puppy-unleashed’, replace the rc.modules, rc.shutdown and introduce pci-usb-pcmcia.ids in the puppy-unleashed/packages/0rootfs-skeleton-3.02 package.

Note that puppy-unleashed/packages.txt has both ‘pcmcia-cs’ and ‘pcmciautils’ packages selected, however I don’t think the latter should be, as it isn’t being used.

If you’re just coming into playing with the 3.02alpha1 Unleashed tarball, please note that I have made other fixes. Read back through this blog since the announcement of the 3.02alpha1 release. Various fixed files and packages have been uploaded to ibiblio, in that same directory as the above URL.

Note also, if you have played with the Dingo alpha6 that I built with the 2.6.21.7 kernel, it has the same problem. It also requires those 3 files.
Another problem with this build, as someone noted on the forum, is that the ‘devx_396.sfs’ file does not load. This is because the 2.6.21.7 kernel has an older squashfs module (v3.2r2) whereas the ‘mksqushfs’ tool used to create the sfs file is v3.3. V3.3 achieves greater compression but isn’t backwards compatible.

This is very interesting. When I setup my Classmate laptop at the “laptop counter” at the Singapore Budget Terminal, my USB optical mouse did not work at all. This mouse was brand-new, a Logitech mouse, and I was most surprised. This is the desk that I had setup on:

Do you know what was wrong? It’s the yellow color! When I moved to the grey desk surface, the mouse worked fine:

My mouse-saga does not end there. When I moved into my accomodation in India, there was a handy little desk that I setup my laptop, but the mouse barely worked –the cursor responded in half-hearted little jerks. Here is the setup:

The cause was the brown surface! I put the mouse on a piece of white paper and it then worked fine. So, there’s a bit of an education about colors that the mouse laser beam doesn’t like.

That room looks a bit like a jail cell! Where was I? Maybe I’ll post another snapshot that prit1 will recognise.

11 Responses to “Mousepad colors”

1. disciple Says:
   February 19th, 2008 at 4:33 pm

   Sorry - posted a question about where to feedback on the Dingo alphas to a January entry by mistake somehow…

2. BarryK Says:
   February 19th, 2008 at 4:50 pm

   Scroll down this blog to where the latest Dingo alpha is announced. It will also contain links (maybe in the comments) to relevant forum threads.

3. Sage Says:
   February 19th, 2008 at 5:50 pm

   I think this ‘feature’ of optical mice is well-known? I even had a tiny slip of paper which passes for a manual included with one mouse that I bought for a client which suggested the white paper solution you discovered.

4. disciple Says:
   February 19th, 2008 at 5:51 pm

   Thanks, but it seems Windows or something must be magically hiding it from me somehow.
   I found it with Google though
   http://murga-linux.com/puppy/viewtopic.php?p=174634&sid=05bd79a5dfcb32fbdf94c395ddc055c4

5. nic2109 Says:
   February 19th, 2008 at 8:04 pm

   Hi; I’ve not had trouble with colours but have had optical mouse issues where the surface has been reflective. A piece of paper or a thin book usually does the trick, as long as it doesn’t have a glossy finish. Colour sensitivity is a new one on me - I’m tempted to say “Trust Barry to find a bug in anything……”.

   Nick

6. raffy Says:
   February 20th, 2008 at 6:45 am

   Especially using the Japanese way of life for apartment space, that room is spacious.

7. brucehohl Says:
   February 20th, 2008 at 8:19 am

   Hmmm …. the “room looks a bit like a jail cell” … and “doors in India have sliding bolts, both on inside and outside” … might make one worry about getting locked in!

8. Subito Piano Says:
   February 20th, 2008 at 9:34 am

   yeah - i read once that optical mice need some sort of patterned surface underneath them to work correctly — hence a stained wood surface will work, but a plain-colored surface requires a mousepad under it — i think just the fabric on top of them provides enough irregularity for the mice to cooperate.

9. disciple Says:
   February 20th, 2008 at 12:38 pm

   In general, my observations line up with what Subito Piano says.
   I also have a MS intellimouse explorer that doesn’t work on the mousepad that came with our computer

10. sml Says:
    February 20th, 2008 at 4:08 pm

    There is a big difference between an OPTICAL mouse and a LASER mouse.

    Ditch the optical and get a laser.

11. prit1 Says:
    February 27th, 2008 at 9:20 am

    Barry .. did you happen to get the picture that you think I will recognize?

I have uploaded these files to ibiblio:

packages.txt.gz
glibc-2.5-1.tar.gz

To be found here:
http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-3.02alpha1/

I had to go through packages.txt in Unleashed to replace a ‘-’ with a space on every line, as this is now the required format:

Was: “atk-1.18.0″ “atk-1.18.0: atk: atk” on “SLACK12 116K” \
Now: “atk-1.18.0″ “atk 1.18.0: atk: atk” on “SLACK12 116K” \

The glibc package now has the ‘zoneinfo’ directory.

There have been reports about wpa_supplicant not working in Dingo. Forum member tempestuous compiled a special patched version of 0.5.8 back in Puppy 2.16 and we used this in 3.0x (and it’s still in 3.02alpha1). However Dingo has v0.6.0. So, I’ve rolled back to the older version and the package in Dingo is now ‘wpa_supplicant-0.5.8-rt73patch-1′. Read more here:

http://www.murga-linux.com/puppy/viewtopic.php?t=25893&start=45

I stated awhile back that I would not forget the Puppy3 series, so here is 3.02alpha1. It has many features of Dingo back-ported. I have very limited time right now as I have a lot of things to do prior to my holiday (starting this coming Tuesday) so alpha1 has had only basic testing and I have added a small selection of the latest packages. Get it from here:

http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-3.02alpha1/

Some notes:

1. I have not backported the Universal Installer, and it still has the same version as in 3.01. Will do that later.
2. It has the ‘Phacile Blue’ GTK theme and the ‘Black-vg’ JWM . However I think they don’t quite match, but probably some slight mods to the GTK theme, like a less-blue-more-grey background would improve it.
3. The ‘devx_302.sfs’ file is identical to the ‘devx_301.sfs’ file.
4. This is still all Slackware-12 compatible. Mostly I have upgraded scripts plus a few executables

If you find that it works and would like to work on it, with a view to a final release version, I propose that it be the basis of a Community Edition, with the versions 3.02 - 3.09 being alpha and beta releases, final being 3.10.
The problem for me is that I’m going on holiday for 4 weeks and will be narrowly focussed on a few things, like improving the PETget package manager. Also, the main focus of my attention will continue to be Dingo. So, if anyone wants bring 3.02 to a final release, you’re welcome.

What I can do is upload the complete Unleashed tarball that I used to build 3.02alpha1, but I only have two more days broadband access. Right now it’s Friday afternoon, and my broadband access will be until Sunday morning. So let me know promptly if you want it.

I know that there are proposals for the next CE to be built on other versions, so my offer is just a suggestion.

I have built Puppy “Dingo” 4.00 alpha6 with the 2.6.21.7 kernel, the same as used in Puppy 3.01. I mean exactly the same, not recompiled. This kernel supports the /dev/hd* notation for IDE drives. Get it from here:

http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-4.00-dingo-alpha6/

If you had trouble with accessing IDE drives with the alpha6 build with 2.6.24 kernel, give this one ago. There were reports of trouble with wireless drivers with the 2.6.24 kernel, so again try this older kernel.

However, do be very cautious about one thing. As these are both the same version number, be sure that there is no pup_396.sfs or zdrv_396.sfs on the hard drive already — since they will have different kernel drivers in them. When you create a pup_save or do a frugal install, you can have these files on the hard drive, so get rid of them before testing this alternative build.

Get it from here:

http://distro.ibiblio.org/pub/linux/distributions/puppylinux/test/puppy-4.00-dingo-alpha6/

Read my blog to find out changes since alpha5.

MU created a handy little utility for displaying a file tail in a window, named gtklogfileview. I have put this into alpha6.

Plinej has updated Pcdripper to v3.4 and Pmetatagger to v1.7. These will be in alpha6.

Muggins has compiled the latest Urlgfe file downloader and created a PET package. I have made this an official PET (not in alpha6 but easily installed).

Kirk has done a great job adapting ‘asapm’, a battery monitor applet, to work in Puppy, especially to fit into the limited height of the JWM tray. Read the forum discussion:

http://murga-linux.com/puppy/viewtopic.php?t=25812

I have modified /etc/rc.d/rc.modules2 and /root/.jwmrc-tray as per Kirk’s supplied files. Note that /root/.jwmrc-tray is in the ‘jwm2-2.0.1′ package.

I have created the ‘asapm-3.1.1′ PET package which has Kirk’s applet, /usr/sbin/asapm.

This is great, as we are embracing these baby laptops, which are all about computing on-the-go. I’m going to find this applet very useful when I tote my Classmate off to India!

I have uploaded the patched 2.6.24 kernel source to here:

http://puptrix.org/sources/kernel-2.6.24-dingo/

This kernel is being used in the upcoming Dingo alpha6.

I posted yesterday that I have rewritten the theme handling for JWM and have created just two themes, Original and Citrus-cut. The former is a reasonable match with the original GTK theme, and the latter with the Citrus-cut GTK theme.

I decided to add another JWM theme and chose the dark-grey theme created by forum member ‘vg1′ at the “JWM themes exchange” thread:

http://murga-linux.com/puppy/viewtopic.php?t=23260

I played with the fonts a bit and named it ‘Black-vg’. I also created a dark-grey background image. The Black-vg, dark-grey desktop background and zigbert’s Stardust desktop icons are a good combination. But, I don’t have a really nice matching GTK theme for that combo.

Hey, now it is working! Now “uevents” are occurring.

The pcmciautils package has various utilities, including ‘lspcmcia’ (a symlink to ‘pccardctl’) and ‘pcmcia-socket-startup’. I ran this:

# lspcmcia -vv
Socket 0 Bridge:        [yenta_cardbus]         (bus ID: 0000:0a:09.0)
Configuration:  state: on       ready: no
Available IRQs: 3, 4, 5, 6, 7, 10, 11
Available ioports:      –none–
Available iomem:        0xd0000000 - 0xd00fffff

I reckon that “ready: no” is significant, so I did this:

# pcmcia-socket-startup
# lspcmcia -vv
Socket 0 Bridge:        [yenta_cardbus]         (bus ID: 0000:0a:09.0)
Configuration:  state: on       ready: yes
Voltage: 5.0V Vcc: 5.0V Vpp: 5.0V
Available IRQs: 3, 5, 6, 10, 11
Available ioports:      0×00000100 - 0×000003af
0×000003e0 - 0×000004cf
0×000004d8 - 0×000004ff
0×00000820 - 0×000008ff
0×00000a00 - 0×00000aff
0×00000c00 - 0×00000cff
Available iomem:        0×000c0000 - 0×000fffff
0xd0020000 - 0xd00fffff
Socket 0 Device 0:      [– no driver –]       (bus ID: 0.0)
Configuration:  state: on
Product Name:   Xircom CreditCard Ethernet+Modem II CEM2 1.00
Identification: manf_id: 0×0105 card_id: 0×110a
function: 2 (serial)
prod_id(1): “Xircom” (0×2e3ee845)
prod_id(2): “CreditCard Ethernet+Modem II” (0xeca401bf)
prod_id(3): “CEM2″ (0×72f0d830)
prod_id(4): “1.00″ (0×83dbf271)

Yippee, now we’re cookin’!!!

It says “no driver” above because I have not yet loaded ‘xirc2ps_cs.ko’.

2 Responses to “PCMCIA - step forward again”

1. BarryK Says:
   January 28th, 2008 at 7:20 pm

   I’ve put together a script /etc/init.d/rc.pcmia that runs ‘pcmcia_socket_startup’ and takes care of loading the correct module, for example my ‘xirc2ps.ko’.

   However, there’s a catch-22 situation, as I start with an alias and I don’t have an accurate way of finding the real module to load — my script that I uploaded yesterday is slow and not so accurate. Actually, I think I can make it more accurate, but it’s still too slow.

   This:
   # modprobe –show-depends pcmcia:m0013c0000f02fn00pfn00pa0FFC50D8pb06A97DFDpc98C5B1DBpd01DB7106

   for example, supplied with an alias, will return the actual module name, but only after it is fetched from the ‘zdrv’ file. My modprobe script cannot translate that alias to the actual module name as the aliases in ‘modules.alias.2.6.24′ contain multiple wildcards.

   If you know what module is required, say xirc2ps_cs.ko, then just running this once would do the trick:
   # modprobe xirc2ps_cs
   as it would then be fetched from the zdrv file.
   In future, if this is executed:
   # modprobe pcmcia:m0013c0000f02fn00pfn00pa0FFC50D8pb06A97DFDpc98C5B1DBpd01DB7106
   it will work.

   I really need to redesign how the zdrv file works.

2. BarryK Says:
   January 29th, 2008 at 6:34 am

   I’ve done a temporary fix in /etc/init.d/rc.pcmcia. I got a database file out of the old ‘pcmcia-cs’ package, that matched the manufacturer and product name to the required driver. The card has to be plugged in at bootup for the correct driver to load.

   It’s not perfect but hopefully will give basic PCMCIA functionality. Later I think that I’ll migrate Puppy onto udev and also redesign how the ‘zdrv’ file works to overcome the alias-with-wildcards problem. That will be after Pup 4.00.

I have started to study udev. With the ‘udevd’ daemon I was able to monitor “uvents” (kernel hotplug events) as I plugged and unplugged a USB drive. I was starting to see the usefulness of this.

Then I plugged in my PCMCIA network card. Nothing. No “uevents”. Hmmm. I then looked at /sys/bus/pcmcia/devices and found that the kernel is not responding at all to plugging and unplugging my PCMCIA card.

The kernel was registering PCMCIA events before so what is different now? The 2.6.24 kernel. I checked the ‘.config’ file, all PCMCIA-related settings are the same as for the 2.6.23.12 kernel. I booted up older test CDs built with 2.6.24-rc4 and 2.6.24-rc8, all no go.

I am pretty sure everything is the same, just different kernels. The ‘.config’ files are almost identical. With the 2.6.24 kernel, PCMCIA seems to be dead on my laptop (Acer Aspire 3681WXMi).

Just when I was thinking how wonderful alpha6 is going to be, this one comes along. Well, I’m just about to go off to bugzilla.kernel.org and see if anyone has reported this problem.

Note, I reported a bug to bugzilla.kernel.org about a week ago, as I found a bug in the configuration selection, and I was somewhat disappointed that it did not get fixed before 2.6.24 came out. I get the feeling that the decision to bring out 2.6.24-final was rather sudden. Perhaps they want wider use to get more bug reports, then they’ll bring out 2.6.24.1.

The 2.6.24 has new network drivers, replacing third-party drivers.

‘iwlwifi’ has two modules, iwl3945.ko and iwl4965.ko. The ipw3945.ko module is now retired. I have updated the firmware.

‘rt2×00′ has  rt2×00pci.ko, rt2×00usb.ko, rt61pc.ko, rt73usb.ko, rt2400pci.ko, rt2500pci.ko and rt2500usb.ko, replacing rt61.ko, rt73.ko, rt2400.ko, rt2500.ko and rt2570.ko. I have updated the firmware.

The ‘rt2×00′ homepage has this statement:

two days ago, January 24th, Linux Kernel 2.6.24 was released. This is the first mainline kernel that includes (sadly a somewhat buggy) rt2×00 release.

…hmmm.

I was hoping to use only the automatic GTK-to-JWM theme converter, but when I tested on four or five GTK themes, JWM looked awful. So, I realised that choice of custom JWM themes must be retained, however I have totally rewritten that part of the JWM Configuration tool.

The new script is /usr/local/jwmconfig2/theme_switcher, called from the main GUI window in the JWM Config tool. The script scans the contents of /root/.jwm/themes and displays found themes.

Each theme in /root/.jwm/themes consists of 4 files. For example, I created a ‘Citrus-cut’ theme to match the GTK theme,and the files are ‘Citrus-cut-colors’, ‘Citrus-cut-jwmrc’, ‘Citrus-cut-tray.png’ and ‘Citrus-cut-window.png’. They are self-explanatory when you look at them. The two images are thumbnails of the theme and are displayed in the theme_selector GUI window.

It will be very easy for anyone to add more themes. Currently I only have ‘Citrus-cut’ and ‘Original’.

Some extra notes, for anyone wishng to add new themes to Dingo alpha6 (after it is released), is:

1. the GTK themes are at /usr/share/themes,
2. sets of desktop icons are at /usr/local/lib/X11/themes,
3. and desktop background images are at /usr/share/backgrounds

The menu ‘Menu -> Desktop’ has tools for setting all of these individually. There is currently no master-theme setter, but it is pretty easy to play with the individual tools and mix-and-match to suit ones taste.

One Response to “JWM theme selection rewritten”

1. disciple Says:
   February 19th, 2008 at 4:31 pm

   Barry, is there a forum thread or something you are watching for feedback on the Dingo alphas? I can’t see one… do you just want it here?

I tested ‘gCurl’ that is in Dingo alpha5 but it doesn’t seem to work, or at least it didn’t for me. Even if it can be made to work, it should be intuitive.

So, alpha6 will not have gCurl, instead it will have Lobster’s ‘Pwget’. See forum links:

http://murga-linux.com/puppy/viewtopic.php?t=25567
http://murga-linux.com/puppy/viewtopic.php?t=25183

I have updated these:

Pbackup 3.03 (zigbert)
Pburn 0.9.3 (zigbert)
Pmetatagger 1.4 (plinej)
Pwireless 0.8 (plinej)

I also ugraded Notecase to 1.7.7pre as it has an important bugfix (hyperlinks to URLs did not work). However I don’t have the source and have used a binary compiled by muggins in Puppy 2.16 — works fine in Dingo.

The 2.6 kernel has a new system for handling PCMCIA, but Puppy up until and including Puppy3 uses the old “2.4 kernel” system. The old system took care of loading the correct kernel modules.

The are two modules to be concerned about for a PCMCIA card. Firstly, there is the bridge, or interface between the PCI bus and the PCMCIA card, and these modules are easy to determine. An example is yenta_socket.ko.

Some PCMCIA cards require another specialised kernel module. For example, PCMCIA network cards. I have a Ethernet card that requires the xirc2ps_cs.ko module. It is this second group of modules that are more tricky to determine which to load.

The second group was taken care of by the older PCMCIA sytem, but in Dingo I have gone over to the new 2.6 ‘pcmciautils’ system. All Dingo alpha releases so far only load the PCI-PCMCIA bridge driver, not the second one.

I am seriously thinking of moving to udev, which I think will make selecting and loading the second driver easy. But, I need to learn all about udev first and it won’t be in Puppy 4.00. In the meantime I have written a script that hopefully succeeds in determing the appropriate driver to load. Well, it works for my card.

Do you have a PCMCIA network card? Try the attached script, let me know if it guesses right. I have only tested this script in Dingo.

The script is rather slow. I see it as a temporary solution only, but it really should be rewritten in C if I use it in Puppy 4.00.

I have started a forum thread with this script posted to it and for feedback:

http://www.murga-linux.com/puppy/viewtopic.php?t=25782

Barely two hours after it was announced by Linus, I was downloading it.

I patched it with the usual — loglevel, dpath, squashfs and unionfs.

This kernel has a lot of new wireless drivers, so there is less work for me to compile thrid-party drivers.

I did have a problem as most of the modem drivers would not compile. One problem was missing /usr/include/linux/config.h, which was a deprecated file backabout the 2.6.18 kernel — it doesn’t do any harm to put that in, so I’ll put it into the ‘devx’ file. The problem that caused a whole heap of third-party drivers not to compile is the /usr/src/linux-2.6.24/include/linux/interrupt.h file. There is a missing symbol, ‘SA_SHIRQ’. The initerupt.h file in the 2.6.23.12 kernel states that this is deprecated and will be removed by the end of 2007. Well, I just copied the symbol definition from the interrupt.h file in the2.6.23.12 kerneland inserted into the interrupt.h file in the 2.6.24 kernel. The drivers then compiled ok.

The modem drivers that I successfully compiled: 536, 537, ltmodem, pctel, slmodem, ungrab-winmodem.
The modem driver that I  failed to compile: ess.

The wireless driver that I successfully compiled: madwifi (atheros)
The wirelss driver that I failed to compile: acx

My operation on interrupt.h allowed the 537, ltmodem, pctel, slmodem and sis7019 drivers to compile. However, I don’t yet know whether these drivers will actually work! I’ll test on a Lucent modem, if it works then probably the others are ok.

Dougal reported recently that the ‘Citrus-cut’ GTK theme used in Dingo is noticeably slower on older PCs. I reported that in this blog and suggested that zigbert’s ‘Stardust’ theme could be used as the basis for creating a more cut-down Citrus theme. Okay, I’ve just done it.

Citrus-cut is based on a theme named ‘Citrus’, that I hacked into and made it much smaller. Now, it is hacked yet again and has about the same number of icons as zigbert’s Stardust theme, yet it looks pretty much the same as before. Running ‘du’, the previous Citrus-cut package took up 400KB, now it is 172KB.

I have incremented the version number of the PET package, it is now ‘gtk_theme_citrus_cut-1.1′.

I fixed an issue with installation to a laptop with internal USB Flash storage, that is, the Intel Classmate laptop. It was running in PUPMODE 6, without any tmpfs top layer on the unionfs. I’ve got Puppy installed on my Classmate in what we call a “frugal” installation, where ‘initrd.gz’ and ‘pup_xxx.sfs’ are on the target partition. The partition is ext2 and I chose the full partition to save to.
Anyway, I fixed it so that it comes up in PUPMODE 7, with tmpfs top layer.

Béèm (forum name) reported that Zfind (file search program) crashes in Dingo. I have used it okay, but perhaps it is a question of what type of searches are chosen. Anyway, Dingo also has zigbert’s Pfind and that is very good. I had put Zfind in in addition as I found it to be very simple, but on reconsideration Pfind is also quite easy to use. Therefore Dingo alpha6 will just have Pfind (Zfind is still a PET package though).

Ecomoney (forum name) requested that Puppy should create a swap file in NTFS partitions. When Puppy starts up in PUPMODE 12 (the normal mode when the pup_save file is on the internal fast hard drive) , Puppy will use any swap file found, or if not will create one - except for NTFS. I have removed the NTFS exception. The code for this is in /etc/rc.d/rc.sysinit.

I added the correct setting of the background color for ‘absvolume’, the volume control in the tray, when the current GTK theme is applied to JWM in the JWM configuration program. ‘absvolume’ does not need the ‘-bg’ parameter in earlier puppies but does in Dingo, probably due to the version of GTK (2.12.1).

Note,  HairyWill (forum name) developed absvolume for Puppy. It is not started in /root/.jwmrc-tray like other applets, instead is started in /root/.xinitrd. Will has a later version, that has an icon that changes with audio status, that I have not yet put into Dingo. The one I have currently just has a static “loudspeaker” icon.

PupDial and PupScan had a small bug. The results-box in both of these apps displays as a monospaced font, however after either of these programs has finished, the monospaced font remains applied to certain dialog boxes and text boxes in other GTK applications. The reason for this is that /etc/gtk-2.0/gtkrc gets altered when PupDial and PupScan startup,but gtkrc was not not getting restored to its prior status, thus affecting all later applications. Fixed.

Forum member raffy now has the master username and password for the servage.net account that hosts puppylinux.org and pupweb.org.

If you have any suggestions about the site, or problems with it, please contact raffy. If you would like to see pupweb.org changed in some way, we are open to suggestions.

Thanks to Chris (cthisbear on the forum) for the donation of fifty Australian dollars. Coming just before I leave, is that for spending money on the trip Chris?

Bob (he hasn’t explicitly given me permission to use his last name, and I don’t know his forum name) has been using Linux for 10 years and now uses Puppy. He just wanted to send me something a bit unusual, a token, to say thanks for the fun he has had. It sure is unusual — he has sent me a “Herkimer diamond”, a double-teminated quartz crystal. Sure looks nice. Here is a web page with info:

http://geology.com/articles/herkimer-diamonds.shtml

The free memory applet used in Dingo is different from that used in other puppies. This one uses the Xlib libraries only, the other uses GTK.

The applet was not displaying the correct size when booted from Flash, now fixed. The package is now ‘freememapplet_xlib-0.1.2′. I’ll upload the source to puptrix.org soon.

Rerwin has been working with various people, fixing the Xorg Wizard to work with some difficult video hardware. He has now added the Trident video BIOS dated 1997 as a special case. See forum thread, discussion with Barrington:

http://www.murga-linux.com/puppy/viewtopic.php?p=166725#166725

I have added this workaround to the Xorg Wizard.

See my recent blog post about the OLPC that has been donated to me.

After 5 or 6 hours of usage, I still don’t like the Sugar environment. It is slow and to me seems primitive. The argument that it’s for kids not adults is really weak. Kids really need all the same computing environment that adults use.

A reviewer suggested that it is slow due to the extensive use of Python. Maybe. In Puppy Linux we use Bash scripting, but we use it is a “glue language”, meaning that it glues compiled applications and utilities together. We have small GUI applications written in Bash that load and respond quickly as they adhere to this “glue” philosophy. Unfortunately there is a trend to write huge applications in Python, which also use share-library-binding packages also written in Python — result, bloat and slowness.

I have my Developer Key, and I have been following some instructions to boot from USB, and I have got as far as “Loading initial ramdisk…” at which point it hangs.

OFW… I don’t like that either. The reasoning for choosing it is here:
http://www.mail-archive.com/devel@laptop.org/msg01849.html

I think it’s a bad move going to Forth. I have a lot of Forth experience, a long time ago, but decided that it is a fundamentally flawed language. I was even a member of the Forth Users Group in the USA, and wrote an article about Forth programming for an Australian computer magazine. Faster? …hah, hah, hah.

Today I saw the Asus EeePC 4G in OfficeWorks here in Australia. What a lovely machine! Selling for AU 488 dollars. It was running and I had a peek at the user interface/environment — really nice — that’s what adults and kids really need. I mean, a nice user interface, all the powerful apps like OpenOffice. Nice keyboard.

Hmmm, yes, that’s a problem — the OLPC keyboard has keys that are designed for Sugar — which is annoying if we want to dump Sugar.

My assessment so far is that OLPC is not going to succeed. Intel will be bringing out a new Classmate soon, which “ups the ante”. With standard BIOS, standard keyboard (and nice keys), uDiskOnChip internal Flash …I don’t know if I am allowed to mention the new specs so won’t. But, basically, the Classmate (and EeePC) is all standard-PC and standard-Linux right through, so wide open for the legions of PC-hardware and Linux developer nerds.

I’m having a grumble in this post. If you like Forth, fine. If you like the Sugar interface, good on you. Maybe you think that my comment about the viability of the OLPC project is off — well maybe. This is just my feeling on it so far, and I may be convinced otherwise as