Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Sun 21 Sep 2014, 00:14
All times are UTC - 4
 Forum index » Taking the Puppy out for a walk » Announcements
Chihuahua Alpha6 plus Lassie_Office
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 9 of 11 [152 Posts]   Goto page: Previous 1, 2, 3, ..., 7, 8, 9, 10, 11 Next
Author Message
prehistoric


Joined: 23 Oct 2007
Posts: 1271

PostPosted: Sun 18 May 2008, 18:54    Post subject: misunderstanding  

@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.
Back to top
View user's profile Send private message 
prehistoric


Joined: 23 Oct 2007
Posts: 1271

PostPosted: Mon 19 May 2008, 03:21    Post subject: alpha 6+ solid, (where it runs at all)  

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.
Back to top
View user's profile Send private message 
prehistoric


Joined: 23 Oct 2007
Posts: 1271

PostPosted: Wed 21 May 2008, 13:46    Post subject: Wrong again  

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.
lapsnap.jpg
 Description   screenshot of "Chihuahua" alpha 6 on my Dell Latitude D600, showing gkrellm as system monitor
 Filesize   98.16 KB
 Viewed   651 Time(s)

lapsnap.jpg

Back to top
View user's profile Send private message 
ttuuxxx


Joined: 05 May 2007
Posts: 10753
Location: Ontario Canada,Sydney Australia

PostPosted: Wed 21 May 2008, 14:07    Post subject:  

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 Smile
Back to top
View user's profile Send private message Visit poster's website 
prehistoric


Joined: 23 Oct 2007
Posts: 1271

PostPosted: Thu 22 May 2008, 02:12    Post subject: Hotpup fix  

@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.
Back to top
View user's profile Send private message 
alienjeff


Joined: 08 Jul 2006
Posts: 2291
Location: Winsted, CT - USA

PostPosted: Thu 22 May 2008, 09:33    Post subject:  

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

_________________
hangout: ##b0rked on irc.freenode.net
diversion: http://alienjeff.net - visit The Fringe
quote: "The foundation of authority is based upon the consent of the people." - Thomas Hooker

Back to top
View user's profile Send private message 
prehistoric


Joined: 23 Oct 2007
Posts: 1271

PostPosted: Thu 22 May 2008, 10:49    Post subject: quantify difference between JWM and Icewm?  

@AJ,

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

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.
Back to top
View user's profile Send private message 
HairyWill


Joined: 26 May 2006
Posts: 2949
Location: Southampton, UK

PostPosted: Thu 22 May 2008, 10:58    Post subject:  

prehistoric
what do you need tested?

_________________
Will
contribute: community website, screenshots, puplets, wiki, rss
Back to top
View user's profile Send private message 
prehistoric


Joined: 23 Oct 2007
Posts: 1271

PostPosted: Fri 23 May 2008, 12:16    Post subject: testing hacks  

@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.
xfix.tar.gz
Description  hacked scripts for fixing X exit problems on "Chihuahua" alpha 6, also changes startup of Hotpup and conky
gz

 Download 
Filename  xfix.tar.gz 
Filesize  8.41 KB 
Downloaded  445 Time(s) 
Back to top
View user's profile Send private message 
WhoDo


Joined: 11 Jul 2006
Posts: 4441
Location: Lake Macquarie NSW Australia

PostPosted: Fri 23 May 2008, 18:30    Post subject: Re: testing hacks  

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

_________________
Actions speak louder than words ... and they usually work when words don't!
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com
Back to top
View user's profile Send private message 
prehistoric


Joined: 23 Oct 2007
Posts: 1271

PostPosted: Fri 23 May 2008, 20:23    Post subject:  glitches and 4.00  

@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?
Back to top
View user's profile Send private message 
WhoDo


Joined: 11 Jul 2006
Posts: 4441
Location: Lake Macquarie NSW Australia

PostPosted: Fri 23 May 2008, 22:56    Post subject: Re: glitches and 4.00  

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.

_________________
Actions speak louder than words ... and they usually work when words don't!
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com
Back to top
View user's profile Send private message 
prehistoric


Joined: 23 Oct 2007
Posts: 1271

PostPosted: Sun 25 May 2008, 12:26    Post subject: Re: glitches and 4.00  

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.
Quote:
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.
Quote:
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.
Back to top
View user's profile Send private message 
WhoDo


Joined: 11 Jul 2006
Posts: 4441
Location: Lake Macquarie NSW Australia

PostPosted: Sun 25 May 2008, 17:35    Post subject:  

Still testing as we speak. Looking promising though.
_________________
Actions speak louder than words ... and they usually work when words don't!
SIP:whodo@proxy01.sipphone.com; whodo@realsip.com
Back to top
View user's profile Send private message 
prehistoric


Joined: 23 Oct 2007
Posts: 1271

PostPosted: Mon 26 May 2008, 10:15    Post subject: looking solid  

@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:
#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:
#!/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.
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 9 of 11 [152 Posts]   Goto page: Previous 1, 2, 3, ..., 7, 8, 9, 10, 11 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Taking the Puppy out for a walk » Announcements
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1367s ][ Queries: 12 (0.0229s) ][ GZIP on ]