Chihuahua Alpha6 plus Lassie_Office

News, happenings
Message
Author
User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

misunderstanding

#121 Post by prehistoric »

@alienjeff,

I must have misunderstood something here. I thought he was causing the machine to use an existing kernel module for driving the i810, which should work the same way as in the past. I suspect your install has misconfigured things so it uses the wrong intel driver. There are also probably issues with the xorgwizard which could be resolved by editing that xorg.conf file. If we had an example of what the wizard should be doing, life would be simpler.

On your HP kayak, I don't think scsi support has to be particularly hard, for a single special case. Slackware supported scsi last time I looked. If you have the ARO-1130A RAID controller card, pull it. It costs you too much PCI bus bandwidth to be worth using. That's why nobody wrote a Linux driver for it. The machine can run the drives using the other controller card(s) and do software RAID under Linux just as well. If you have trouble finding a driver, (for the Symbios card?) consider using a cheap, standard Adaptec controller pulled from a working machine. Every major Linux distribution supports AHA-2940. Your biggest problem may be connectors and cables for your drives.

If you want an example of sheer bloody-mindedness, my (successful) attempt to put SuSE Linux on an old NCR box with Microchannel architecture and scsi disks should qualify. Compared to that, most Puppy boxes are pure vanilla.

In practical terms, it should be easy to put in a PCI card IDE controller and connect it to a modest-sized IDE drive which will be plenty big for Puppy. There was a time when every Maxtor 100 MB/s IDE drive came with a controller card. New IDE controller cards can be had for less than $20. Even an external IDE enclosure with a USB 2.0 interface and a USB interface card is reasonable. Here's a snappy little number which takes a notebook drive.

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

alpha 6+ solid, (where it runs at all)

#122 Post by prehistoric »

I can't talk about problems I was never able to reproduce, but the ones I saw before have disappeared - and stayed gone - with the changes mentioned. I have been testing with the HotPup daemon disabled, because that could have its own problems.

Alpha 6, with the changes I've made, has been used for hours on machines with 350 MHz to 500 MHz processors and memory from 128 MB up. I've also left it running all day on a former problem machine, to check for that disappearing cursor trick, or other video weirdness. No problems to report there. It has also been stable on the laptop for the last few days.

I have tried not to get into testing more applications, as I was looking for extremely rare events in the base system and didn't want to confuse the issues.

The changes I've tried are simple: change every script that exits or restarts the wm, and modify xwin to avoid ever having two processes fighting over video; launch all processes under wm control from Startup or (better) MU's autostart. The only process which can be outside this is the X window background, which Icewm expects to inherit from X.

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

Wrong again

#123 Post by prehistoric »

My last statement was incorrect. The process which sets the background image should be launched under control of the window manager. Icewm inherits the root window from X, but the background is separate, as you can sometimes see at startup and shutdown. I've been setting the background today and encountered a glitch which lost one of my Choices, probably another concurrency problem. If so, this one gets into a conflict which bothers unionfs.

Here's a screenshot of the installation I've been using on my laptop, with gkrellm replacing conky. I've removed the button to stop the internet because the interface name on the gkrellm display is now the button I wanted. There are other aspects to the customization this system monitor offers, without editing configuration files. Notice that it shows two batteries and no DVD. At the moment, the DVD is out of the drive bay and a second battery is in, and gkrellm caught this. I have also removed the swap display because I'm running without swap. There is an incredible amount of relevant information packed in a small amount of screen space, and all these changing displays only require one process.
Attachments
lapsnap.jpg
screenshot of "Chihuahua" alpha 6 on my Dell Latitude D600, showing gkrellm as system monitor
(98.16 KiB) Downloaded 694 times

User avatar
ttuuxxx
Posts: 11171
Joined: Sat 05 May 2007, 10:00
Location: Ontario Canada,Sydney Australia
Contact:

#124 Post by ttuuxxx »

wow that looks like a nice desktop, And as conky goes well I'm not much for system monitors but some like them very much.
you can actually use icewm as the background and not rox, I haven't figured it out yet but its part of the program, /usr/local/bin/icewmbg
great work
ttuuxxxx
http://audio.online-convert.com/ <-- excellent site
http://samples.mplayerhq.hu/A-codecs/ <-- Codec Test Files
http://html5games.com/ <-- excellent HTML5 games :)

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

Hotpup fix

#125 Post by prehistoric »

@tronkel, ttuuxxx,

I've tested Dougal's new hotpup and, so far, found no problems. Resource consumption will be significantly less on slow machines.

I suspect the sleep he stuck in the rox startup is a cludge which hides a potential race with wm startup. If rox was launched by the wm this could never be a problem. I like to move things out of .xinitrc whenever possible, with something as complicated as Icewm. The difference MU saw in icon pileups with nvidia cards might be solely due to an extra delay introduced in using the special driver. Adjusting specific delays in several places is a great way to create obscure nondeterministic problems.

@ttuuxxx,

I'll wait to test your experimental Icewm after I've done a sleep myself.

User avatar
alienjeff
Posts: 2265
Joined: Sat 08 Jul 2006, 20:19
Location: Winsted, CT - USA

#126 Post by alienjeff »

Seeing how the first word in this thread's subject line is Chihuahua, which according to the quasi-mission statement/spec of this CE, was supposed to be the small, light, fast, blah, blah on which sfs bloatage was to be heaped; and the apparent mania to flush JWM down the toilet in favor of some mongoloid iceWM, I thought I'd share this linkage with y'all:

http://www.gilesorr.com/wm/memory.html
[size=84][i]hangout:[/i] ##b0rked on irc.freenode.net
[i]diversion:[/i] [url]http://alienjeff.net[/url] - visit The Fringe
[i]quote:[/i] "The foundation of authority is based upon the consent of the people." - Thomas Hooker[/size]

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

quantify difference between JWM and Icewm?

#127 Post by prehistoric »

@AJ,

Let's see if I understand. You're recommending we switch to WeeWM to go with "Chihuahua"? :lol:

The problem with these comparisons is that many window managers with limited functionality end up in systems where the applications need libraries to compensate for missing function. Because the change took place along with several other big changes, I don't have a good way to compare system sizes with JWM or Icewm.

The version of Icewm I'm running right now seems pretty solid and responsive on this machine. On slower machines, I would definitely prefer JWM. Our problem now is how to maintain JWM when the developer has apparently lost interest.

There has been no evidence of activity on the well-reported full-screen problems with video players. This doesn't bother me particularly, but it does suggest we either need to take over maintenance for our version of JWM or switch. I have not felt strongly enough to volunteer for the job. Others seem willing to work with Icewm, and there is a larger community outside Puppy which actively develops and maintains the code.

This alpha is, by designation, an experiment. For a time it looked like a failure. At the moment, I think I can live with Icewm. The problems I found were deep in Puppy's handling of the X window system and in the way Hotpup got information by polling. We now have patches for X window scripts and a redesign of Hotpup. These fixes should apply to versions using JWM as well. I've found the problems were not absent, simply rarer, with JWM. This exercise has forced some bugs into the open.

I'm still mucking around in the code of xwin, (where I have suspicions about the source of your particular i810 trouble,) but that shouldn't hold up others. The patched version I'm using to post this is pretty solid.

What I need at the moment is confirmation that the changes I've made don't break something that was working for other people. I've tried them in 3.01, NOP 3.01, Muppy 008.3 and some 4.00 puplets on several of my machines. This is a far cry from extensive testing.

User avatar
HairyWill
Posts: 2928
Joined: Fri 26 May 2006, 23:29
Location: Southampton, UK

#128 Post by HairyWill »

prehistoric
what do you need tested?
Will
contribute: [url=http://www.puppylinux.org]community website[/url], [url=http://tinyurl.com/6c3nm6]screenshots[/url], [url=http://tinyurl.com/6j2gbz]puplets[/url], [url=http://tinyurl.com/57gykn]wiki[/url], [url=http://tinyurl.com/5dgr83]rss[/url]

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

testing hacks

#129 Post by prehistoric »

@HairyWill,

Glad you asked! I hadn't fooled with these scripts for a while and needed to look at them again.

The problem the hacks address is the black/frozen screen which appears on some machines under some conditions on some exits from X. It was caused by several process fighting over one display and/or keyboard.

The entire set of scripts applies only to "Chihuahua" alpha 6. Changes to .xinitrc and a new autostart.sh to be placed in the Startup directory are concerned only with starting Hotpup and conky. If you aren't using these you can ignore them.

Modified scripts for xwin, restartwm, wmpoweroff and wmreboot apply to all puplets I've looked at recently. You will have to take some care to edit in only the changes I've made, as different puplets have slightly different scripts for use under X. Place these in a directory in your PATH where they will be found before the commands in /usr/X11R7/bin, or back up those commands and place them in that directory. The important parts are only two lines near the beginning of xwin and removing the last "killall" command in the others.

I've checked repeatedly and never found a case in which that command was doing any good. I don't doubt it had an effect at one time, it may still be of use in rare cases. What I've done is to move that to the beginning of xwin, casting a wider net for concurrency problems between the execution of commands that exit X and the actual exit itself.

If you haven't been seeing the problems described above on exit from X, the thing I would hope to hear is that it had no perceptible effect. (Nothing else was broken.)

I've gone over the scripts in question again and attached a tar.gz file. The .xinitrc file has been renamed merely so you can see it if you are not viewing hidden files.
Attachments
xfix.tar.gz
hacked scripts for fixing X exit problems on &quot;Chihuahua&quot; alpha 6, also changes startup of Hotpup and conky
(8.41 KiB) Downloaded 631 times

User avatar
WhoDo
Posts: 4428
Joined: Wed 12 Jul 2006, 01:58
Location: Lake Macquarie NSW Australia

Re: testing hacks

#130 Post by WhoDo »

prehistoric wrote:The entire set of scripts applies only to "Chihuahua" alpha 6. Changes to .xinitrc and a new autostart.sh to be placed in the Startup directory are concerned only with starting Hotpup and conky. If you aren't using these you can ignore them.
The "killall" command was a hangover cludge from Puppy 1.07 and has no negative effect that I can discern on other puppy's when removed. MU knows more about that issue than me.

I have downloaded your tarball to try on Dingo 4.0, because I repeatedly suffer the black screen of death on that installation with my laptop. I suspect the reason it turns up in CA6 is because of the backporting of scripts from Dingo.

I'll let you know how it goes. I would hope that any satisfactory resolution will push this CE into Beta. Six alphas is not encouraging widespread user testing in the community IMHO. I'm very glad you and Will are involved in the effort to get this release out there for the community.

Cheers
[i]Actions speak louder than words ... and they usually work when words don't![/i]
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

glitches and 4.00

#131 Post by prehistoric »

@WhoDo,

I've seen some cases where the black screen made an appearance on 4.00 and also tried the patches. Haven't done anything like the testing I've done on this, so didn't claim success there. Let me know your results.

All the time I've spent on alpha 6, and a paranoid attitude toward mysterious glitches, has caused me to notice three cases in which a configuration file in frequent use by Sylpheed, which I use constantly, reverted to an earlier, unmodified state. If this isn't due to a bug in unionfs, I am at a loss to explain it.

Could this same bug be present in all 3.xx? Have we done anything to make "Chihuahua" different in this respect?

User avatar
WhoDo
Posts: 4428
Joined: Wed 12 Jul 2006, 01:58
Location: Lake Macquarie NSW Australia

Re: glitches and 4.00

#132 Post by WhoDo »

prehistoric wrote:All the time I've spent on alpha 6, and a paranoid attitude toward mysterious glitches, has caused me to notice three cases in which a configuration file in frequent use by Sylpheed, which I use constantly, reverted to an earlier, unmodified state. If this isn't due to a bug in unionfs, I am at a loss to explain it.

Could this same bug be present in all 3.xx? Have we done anything to make "Chihuahua" different in this respect?
Could be a bug in Sylpheed itself, too. 3.xx series doesn't use Sylpheed by default. That first appeared in 4.00b, if memory serves. 3.01 doesn't have the level of backporting from Dingo that 3.02alpha does. That is the significant difference from all other 3.xx series Puppies.

Have you checked the status of the config file on shutting down Sylpheed, but before rebooting into either Sylpheed or Puppy? My guess would be the file is going AWOL altogether and Sylpheed is creating a new "blank" one when restarted, but I don't know what your testing protocol has been.

I have only ever had one instance of any configuration file disappearing in any 2.xx or 3.xx series of Puppy - xorg.conf being corrupted by a misbehaving WM and being replaced by a fresh copy on using xorgwizard. In every case the old xorg.conf was still there as a backup copy, thanks to the xorgwizard script. I'm only just now starting to look at Dingo.
[i]Actions speak louder than words ... and they usually work when words don't![/i]
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

Re: glitches and 4.00

#133 Post by prehistoric »

WhoDo wrote:...Could be a bug in Sylpheed itself, too. 3.xx series doesn't use Sylpheed by default. That first appeared in 4.00b, if memory serves. 3.01 doesn't have the level of backporting from Dingo that 3.02alpha does. That is the significant difference from all other 3.xx series Puppies.
I've been using Sylpheed for some time with 3.01, at least with ttuuxxx's Fire Hydrant JWMc version. I have to admit a prejudice against the idea of major bugs in Slypheed because this is one application that gets a great deal of testing. The problem would mostly likely result from an error in configuring it for Puppy.
Have you checked the status of the config file on shutting down Sylpheed, but before rebooting into either Sylpheed or Puppy? My guess would be the file is going AWOL altogether and Sylpheed is creating a new "blank" one when restarted, but I don't know what your testing protocol has been.
My "testing protocol", for this particular example, is simply to spend a lot of time using the system like an ordinary user and keep a sharp lookout for glitches (anything completely unexpected.) When I have more information, as with the black/frozen screen problem, I systematically try to make it worse until I can reproduce it at will. That's what I've been doing with slow machines and limited memory. I noticed the black screen was more likely on slower machines and pushed further in that direction.

This is a little like checking that the light in the refrigerator goes off when the door is closed. When I check I don't see this change. It is only after I get a message asking me where my Mail is kept that I know it has happened. One reason I don't suspect Sylpheed, per se, is that it does not forget everything, only the contents of one file.
I have only ever had one instance of any configuration file disappearing in any 2.xx or 3.xx series of Puppy - xorg.conf being corrupted by a misbehaving WM and being replaced by a fresh copy on using xorgwizard. ...
I've seen the same thing. One reason for this to happen is that xorg.conf is accessed on every start, when a lot is happening. Another possibility would be the kind of rare race conditions resulting from more than one family of X processes I have been chasing with "Chihuahua".

Which brings me back to a subject near and dear to my heart. Has anyone tried the patches (to xwin, restartwm, wmpoweroff, wmreboot) I've suggested? If you weren't experiencing the problem these were intended to correct and the changes didn't seem to make any difference on your system that is relevant information. I've tried these changes on the machines and puplets within reach. What I need to know is if this has undesirable effects on other machines or puplets.

If you measure programming output in lines of code (or, worse, in kLOCs) I must seem abysmally slow - all this fuss about a couple of lines, really. These are critical pieces of code which could affect large numbers of people. I want to be sure the gain, in terms of people able to use Puppy because of the patches, is greater than the loss, of people who have no problems now suddenly having trouble.

If anyone turns up an example of misbehavior, that means we haven't reached the end of the trail of this beast after all. In that case, I'll need all the clues I can get.

User avatar
WhoDo
Posts: 4428
Joined: Wed 12 Jul 2006, 01:58
Location: Lake Macquarie NSW Australia

#134 Post by WhoDo »

Still testing as we speak. Looking promising though.
[i]Actions speak louder than words ... and they usually work when words don't![/i]
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

looking solid

#135 Post by prehistoric »

@tronkel,

Are you out there? I've been testing and feel confident enough about changes to go to beta 1. My own tiny patches to xwin, restartwm, wmpoweroff and wmreboot hold up here, and have just been tested on 4.1 alpha 1, from which I'm posting. Dougal's redesigned Hotpup looks acceptable, any further tweaks can go into betas.

I've added a sync at the start of .xinitrc, (which probably is not necessary,) and placed one immediately after the pinboard fix.

Code: Select all

#relocates right-side icons to actual right-side of screen...
/usr/sbin/fixPuppyPin /root/Choices/ROX-Filer/PuppyPin #v1.0.7
sync
This is needed because I've moved the actual start of ROX-filer to my autostart.sh script in the Startup directory to avoid pileups of icons at wm start.

Code: Select all

#!/bin/sh
#start daemons under wm now that wm is running
rox -p /root/Choices/ROX-Filer/PuppyPin &
gkrellm &
Your version of this script would have "conky -d" instead of "gkrellm". I've detached the process to eliminate an unnecessary task in the taskbar or tray.

I may well move Hotpup's daemon startup here from .xinitrc when it appears to be stable. The reasoning is to start these after the wm is running, instead of after a fixed delay. This should eliminate pileups due to concurrency, (I hope,) but hasn't been tested as much.

Trivial change: our standard console is rxvt, but the ROX filer menu brings up xterm when you select new-> terminal.

@ttuuxxx,

I haven't forgotten your Icewm code. I'm just trying to keep issues separate. I'll test that on a clean installation in the next day. So far, all the bugs have been elsewhere. Icewm, or the way we were using it, was merely exposing bugs already present. Some of these show up in MU's Muppy, if you look for them.

nic2109
Posts: 405
Joined: Mon 01 Jan 2007, 20:24
Location: Hayslope, near Middlemarch, Midlands, England

Firefox & Flash

#136 Post by nic2109 »

Hello; I've just started to try Chihuahua A6 and want to say how nice it looks.

Please forgive me if this is known already but something in the build of Firefox isn't quite right as some websites don't think like the Flash installation.

I assume that it IS Flash 9, but the BBC's website isn't interpreting it correctly. See screenshot where you will see that instead of the chance to play a video clip (below the picture of Andrew Strauss) there is the message 'Cannot play media. You do not have the correct version of the flash player.....'.

I have had the same problem with Opera in Muppy so I would think it more likely to be the Flash plug-in than the actual browser.
[color=darkblue][b][size=150]Nick[/size][/b][/color]

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

Flash under alpha 6

#137 Post by prehistoric »

Hi Nic,

The Beeb was right, as it comes from the ISO there is no Flash with alpha 6. This was caused by changing browsers and questions about which version to install by default. I'm currently using Flash 9.0.124, which you can find packaged as a pet here:

flashplayer-9.0.124.0.pet
flashplayer-9.0.124.0.pet.md5.txt

Any sites where Flash was working without being installed should be reported immediately. :wink:

jonyo

#138 Post by jonyo »

I'm using FF 2.0.0.14 with the flash pkdge in xvesa & i get skips (or slight hangs..) with u tube stuff.

User avatar
prehistoric
Posts: 1744
Joined: Tue 23 Oct 2007, 17:34

glitches

#139 Post by prehistoric »

@jonyo,

I suspect the problem stems from both xvesa and flash requiring service, with substantial overhead, at regular fixed intervals. Anything more to report on the cursor and xorg?

@tronkel,

Jack, are you there? Ready to move on to Firefox 3rc1 and beta status?

General problem: I've seen one more glitch where a file went missing. This time most of the main menu, except for the "settings" entry, disappeared. (Could one of our Icewm experts tell me what is different about "settings" and its submenu?) Restarting X had no effect. (This also restarts Icewm.) Rebooting restored the missing menu. What is different? Rebooting rebuilds unionfs.

I have to emphasize that these are extremely rare events, around once a week under heavy use. Most people would simply reboot and assume it was some mysterious "computer" problem. They've been conditioned to accept this as normal in the Windoze world. Because it is not easily reproducible, this kind of report tends to be lost in the noise.

User avatar
tronkel
Posts: 1116
Joined: Fri 30 Sep 2005, 11:27
Location: Vienna Austria
Contact:

#140 Post by tronkel »

@prehistoric

As regards the disappearing menus, this could well be the result of having to cludge the initial startup of icewm. I had to insert a fixmenus & command into the icewin startup script in order to work around some problem that occured when I converted tttuuxx's icewm pet package into a tar.gz that I can use in Unleashed. There is also a menu config file that I have to manually add to rootfs-complete in Unleashed in order to get the menu icons to be displayed.

I have never managed to suss out why converting a dotpet to a directory has caused this.

I'd like to try to wait for Firefox 3 Final before going beta. This should appear sometime in June according to Mozilla. I am testing Firefox 3RC1 at the moment and am a little wary of it as regards the old problem of stability. Its not quite there as yet, but will hopefully get sorted for the final release. It will be a terrific version if they can manage to stablise it. It is very fast.

All I need now is time to concentrate on building it. I don't have a great deal of time to even sit down at the computer at the moment. An incidental benefit with this though, is that it leaves a wider time-frame for incorporation of further packages if required. Things do not stand still in Puppyland. For, example someone has asked me to put back Dougal's enhanced remaster script. So that will need a bit of testing as well.

I'm still here as you can see!
Life is too short to spend it in front of a computer

Post Reply