I found this tiny memory applet and was wondering if you could hack it up and basically remove a few of the resources and see if we could get it to work in the taskbar, the only 2 displays needed is the amount of memory and swap remaining. I'll keep looking for others, but really aren't many memory resource monitors for taskbars.
This one shows how much memory/swap you have and how much is used. click and run.

O.K. guys, I've just gotten a $25 Puppy box working. This one was mentioned in mechmike's thread about cheap Puppy machines. It has a 500 MHz Celeron, 128 MB RAM, an 8.4 GB HD and the Intel eepro100 ethernet adapter. The video is based on the i810E chip set. Unfortunately, for AJ, I can't reproduce his problem with the video wizard or network wizard.

This machine came with no floppy or CD drive, but removing the HD and installing Puppy 3.01 (full HD) on another machine was straightforward. Once I had confirmed that basic functions worked on the new machine, I did a frugal install of 3.02 alpha 6 by hand copying from a USB flash drive.

Now, we get to the interesting stuff. This time I got the problem Lobster reported of having all hotpup drive icons piled up in the upper left corner of the screen. I ended up turning the Hotpup daemon off and restarting X. Then I found a mysterious minature window in the upper left corner. I couldn't grab this because the window bar was too small, but I was able to select move on the right click menu. After trying several things I gave up and left it sitting next to the trash. When I brought ethernet up, this window moved to the tray and I realized it was blinky. I also noticed a second scrolling display on the bar I hadn't seen on my laptop. This turned out to be eth0. What was missing was the freemem tray applet.

On the laptop, I use a wireless interface (ra0 instead of eth0) and I always see blinky and freemem applet, but not the other scrolling display. At the moment, my tray icon for Opera is sitting where that was on the other machine. With both blinky and conky, I can't see justification for another internet display on the bar. I also suspect timing problems are connected with some combination of changing built-in displays and tasks like conky. The installation on the new machine has the same black screen on shutdown as the laptop. Once again, I was able to get around this by killing the Hotpup daemon and freemem tray applet, then exiting to prompt before doing a reboot. This gave me a console displaying the save dialogues so I could create the first pup_save file.

I think it fair to say this problem will turn up on many relatively slow machines. The clue about non-deterministic behavior at start up, as well as shutdown, suggests it is tied to processes run by Icewm and the changing displays on the bar.

<snip>...the only 2 displays needed is the amount of memory and swap remaining...<snip>...This one shows how much memory/swap you have and how much is used. click and run.<snip>

So I started writing an uncharacteristically constructive reply with Geany. As the day wore on and the rain wouldn't seem to let up, I decided to take a nap. Whilst I was unconscious:

prehistoric wrote:

<snip>With both blinky and conky, I can't see justification for another internet display on the bar.<snip>

...which dovetails nicely with what I had started writing about before falling into the arms of Morpheus. But first remember the key words in ttuuxxx's and prehistoric's posts are needed and justification, respectively.

I've been happily married to Puppy v2.12 for just shy of 18-months -- a veritable eon in the world that is Puppy Linux. In that time, my desktop has gone through a number of changes. And being a faithful adherent of JWM suggests spartan leanings. JWM does what I need with a minimum of system overhead, does so better with some personal tweaks, and has remained my WM of choice. I've tried half a dozen other WMs and always come running back to JWM.

I don't sit down at the computer to be dazzled to orgasm by desktop themes or such eye candy. I'm either surfing the Internet, doing some email, writing an editorial or article, managing my website, or fiddling with some configuration settings. Please note the verbs in that last sentence. They are action verbs. The computer is a tool to accomplish, and hopefully expedite, tasks. Work. The jobs at hand. The computer -- this tool -- should make the tasks/work/jobs easier to accomplish than by using its non-electronic and analog counterparts.

But I don't give a rat's ass about a hammer with a decorative handle or a screwdriver that audibly announces how many rotations and in which direction I've turned a screw.

Oh, we can fit all manner of fanciful functions electronically into the computer tool. With SMT (surface mount technology) and LSI (large scale integration), the size of the home computer tool has gone from a suitcase size box down to the diminutive dimensions of the Mac Mini.

Putting widesreen LCDs aside for a moment, what has generally remained constant in size, though, are desktop monitors. With nimble Linux operating systems and enough RAM, our computer tools are multitasking monsters from which we feed all the video output to a single monitor screen with a finite amount of real estate.

Virtual desktops "spread out" the work by "virtually" providing more desktop space. However, the taskbar is the constant, and there's just so much room to stuff information on said taskbar. Other than the remaining space for active app panes, here's what's crammed into the stock v2.12 taskbar (from left to right): menu button, show/hide desktop button, two virtual desktop panes, blinky's active network traffic icons, freememapplet's memory amount display, mini-volume.tcl's speaker icon, xload's active CPU graph, and minixcal's clock digital display. Whew! Talk about a blivet!

My own taskbar is quite simple. Since assigning a hotkey for the menu function, I've been able to remove the menu button from the taskbar. I found little use for the show/hide desktop button, so it was also removed. And since adding Conky, I've removed blinky, freememapplet and xload from the taskbar. These changes leave my virtual desktop panes, the mini-volume speaker icon, minixcal's clock -- and more room for active app panes.

Before someone jumps up and screams, "but you can't see the Conky display when you're running an app full screen," I'll admit that's true. However, one has to ask oneself just how important is it to see "Blinky" or "freememapplet" or "xload" in the taskbar 100% of the time?

In that I have five virtual window panes, which works well for my computing tasks, there's usually one free virtual window that makes access to Conky's display a simple hotkey away.

There's a tipping point where the desktop stops being a utilitarian workplace that is pleasing to the eye and turns into some sort of ostentatious cluster of clutter. Know where the tipping point is and design accordingly._________________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

Last night I gave alpha6 a grueling workout on that small machine, displaying YouTube videos of various weather angels. (This is enough to keep my eyes on the display for a significant length of time without totally shutting down higher mental function. It's a tough job, but somebody has to do it.)

There were a couple of instances where the video hung, (cause undetermined,) but, overall, the Big_Bass Flash Player 9.0.124.pet seems to be working with Firefox 3b5 and Chihuahua alpha 6. What became clear was that 128 MB RAM was not enough for video on a frugal install even with the 500 MB swap partition to hold inactive pages. I've had better luck with 3.01 on a full install and I'll try a full install of 3.02 to another partition so I can directly compare performance. I also intend to install 512 MB RAM to see the difference in performance. If there is a huge change, we'll need to reexamine the memory footprint.

A new problem on this machine was the volume control. It was very slow to launch, probably because the code was swapped out. This led me to click repeatedly, launching several instances. Not good, we need a check for a running instance.

There was no quick and simple way to adjust master volume, which is important when changing videos with uncertain audio. The pre-existing volume control on JWM takes care of the basics without a lot of overhead. We need an equivalent under Icewm.

The black/frozen screen on exit continues to show up on slower machines. It is non-deterministic. Even on the 500 MHz machine, I occasionally get a shutdown with a console I can read. Various hacks done to bypass problems are not the same as solving concurrency problems. Mysterious problems will keep cropping up until we find and address the cause. The way forward is not to make problems less likely, but more likely, so they are easier to find. (I've done consulting where months of effort by clever people dedicated to hiding problems was the most serious obstacle. Fortunately, you can use the same people to solve this. Here's an old professional's secret weapon: when everyone screams, "Don't touch that piece of code!" you are getting close.)

Overall, I think testing on low-end machines is vital to discover unacceptable overhead before we get committed to a program. A 500 MHz machine with 128 MB RAM and a swap partition on HD is not yet described as minimal. Running on machines with different speeds also reveals hidden assumptions about timing which produce bugs that are really hard to reproduce and fix.

That's what my problem is, my slowest machine is 2000MHz hmmm I might have an older motherboard in the garage, funny I'm going to rip apart a 2000MHZ machine just to downgrade it to 400MHZ to try and fix this shutdown/reboot problem, LOL

Gave Chihuahua a bit of a workout last night - for an Alpha release it shows great promise. My test machine is based on an Intel D201GLY board with 1Gb of RAM and a salvaged 30GB laptop IDE hard drive. Boot was from an external DVD RW drive connected via USB. Monitor is a 15" generic LCD running at 1024x768x24.

Getting the proper refresh rate for this monitor took a bit of fiddling with the tweaking controls in Xorg - it needs a 56Hz refresh rate to work properly - once set it works OK for the session but for some reason the settings aren't being retained in the save file. Had to redo them with each reboot. And not all of the reboots were due to the problems with Gxine described below.

Network setup worked well and the SIS chipset was recognized OK. Firefox in its new form looks good and appears to work OK. I'll try downloading a package or two later.

Gxine works OK for playing a music CD - had to play with it some to play a movie DVD though - and once in full screen mode any attempt to go back to "normal" results in a hang that forces a shutdown to resolve. Haven't tried running music files (WMA and MP3 mixed) yet from a separate hard drive - I'll wait on that.

Overall I'm impressed - its been awhile since we had a good community edition of Puppy and I really prefer one with Firefox over Seamonkey. I'm looking forward to the Beta releases._________________Always give without remembering - always receive without forgetting.
Alice

Gxine has not been working well in Puppy for a long time. On the hardware I have here, it won't play DVDs at all! Shows that there are still hardware compatibility issues to be resolved - but that's on old story with Puppy as well. For reasons of its small size I have stayed with Gxine for the CE edtion. The alternatives to Gxine are a lot bigger and also have their own problems anyway - different from those in Gxine, but problems nevertheless.

There are also Xorg issues that need fixing as well. I believe Barry will be revisiting the Xorg package at some point in relation to Puppy 4 - so I'll try out any solution in Puppy 3 that becomes available.

These outstanding issues apart, Chihuahua is starting to look as if it is going in the right direction. It will get to a stable version eventually, but needs lots of TLC - but that's computing for you.

In the meantime enjoy.

Tronkel_________________Life is too short to spend it in front of a computer

Yours and slvrldy's posts above are making me think that the kernel version is critical on older hardware. If I get a mo over the next few days, I'll build a retro version of the current Chihuahua Alpha 6 using the 2.6.18.1 kernel, and see what gives. Might just help with your shutdown problem and slvrldy's Xorg bug.

I managed a compile of the current stable icewin version yesterday so that's not a problem if it turns out that a hacked icewin is necessary.

Real-time systems are programmed using semaphores and monitors to control process threads. That's what might really be needed here. At the moment I don't know how to implement a semaphore within Bash, but I'd imagine it's possible. Have to research that one.

In the meantime, thanks for all the input._________________Life is too short to spend it in front of a computer

Tried both NOP and wNOP with same video issues. However, at least wNOP network configuration worked (eePro100 driver) - which wasn't the case with Chihuahua alpha 6.

Same video woes: after using xvidtune and it writing changes, or supposedly so, the new settings were not persistent after rebooting.

Interesting you're not experiencing the same issues with your Celeron/i810 box.

I remain in blissful ignorance with Puppy v2.12,

Jeff_________________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

The problem with xvidtune has been reported repeatedly on earlier versions. It comes down to Xorg ignoring the modeline xvidtune produces, for reasons I still don't understand. I can add this to the configuration file by hand, but it still doesn't have any effect.

Gxine has issues, no question.

@tronkel,

prehistoric ranting wrote:

Unix/Linux has some peculiarities in the way it handles concurrency. Someone is certain to take issue with me, but here's my view. The kernel has rock-solid concurrency control based on the idea of coroutines which pass zero-length messages. (A process waiting on a message wakes up knowing only that the message arrived. Any other information must be passed through shared memory or the file system.) Outside the kernel things are considerably different. Hard real time requirements are not normally part of the design, which was modeled on time-sharing systems shared by many people doing different things. Somebody, somewhere, has implemented just about every means of concurrency control you can think of. This doesn't mean you can rely on it in a particular distro. Synchronization generally takes place through the file system, as indicated by the command which brings RAM and disk memory into synchronization, because ordering writes is critical to avoiding corruption of file systems when concurrency is involved.

Graphical interfaces came along after the fundamental characteristics were pretty well settled. This is one reason video problems are notorious for producing a hung system, as you are reminded every time you test an Xorg configuration. User processes don't always meet the hard real-time requirements of video adapters. Time-sharing behavior emphasizes mean latency, with good behavior having a small variance in latency. There is no absolute bound on latency.

(Puppy's strategy of running from RAM produces great improvements in both mean latency and variance, giving the impression of a very solid and responsive system because it is unlikely to exceed bounds people will accept. Other systems are still operating by old rules.)

You can tell there is less than perfect control of processes outside the kernel when you see hacks like this:

The fix for our problems is likely to be as simple as finding where undesirable non-determinism starts and making the scheduling for those operations deterministic by running them sequentially in a script. Sticking in a sleep at a few places is an inelegant but simple hack which is likely to keep working (once debugged on a range of systems), because the sleep stays the same as future processor speeds increase. (Don't ask me about multiple processors.)

Trying to bring all processes in a Linux system under solid concurrency control is almost a lost cause. Too many people have hacked on common programs, and are still hacking away as I write. Once we know exactly where the problem starts, minor changes will probably be enough.

On that 500 MHz machine, I have confirmed the suspicion of a race condition at wm startup between conky, blinky and freemem tray applet. I've been disabling HotPup, but its daemon probably gets into the act when it runs. The order in which these processes are launched depends on details of timing which vary from one machine to another. Even the icons have disappeared on some startups, once again indicating a race at that time.

Also found nondeterminism outside the X window system when I exited to a console to get around screen blanking and typed "reboot". It always checks to see if the session is saved, but sometimes fails to reboot. Rerunning the command solves the problem, but leaves a question in mind. Why? (I've been through this before with PCs, Linux and reboot/shutdown.)

Network stop/restart works for eth0, but not for my wireless interface, ra0.

@AJ,

The video remains inscrutable. (BTW: How many scrutable things do you know of?) Same limited choice of resolutions? What could you acheive with xvidtune, before a reboot? Did you get anywhere when wNOP tried to use the proprietary Intel driver? It sounds like the answer is "No, Compiz-Fusion never came up." but I like to be sure. That puplet has routines to dump information which I've seen tombh use to get video working for others. It could be a window into general video problems.

I'm bothered by the failure of network configuration with the Intel eepro100 driver as that is exactly what I'm using. I thought it was exactly the same in wNOP, but will compare the two. If I find a difference, this kind of clue can be like gold.Last edited by prehistoric on Tue 29 Apr 2008, 17:24; edited 1 time in total

That's what my problem is, my slowest machine is 2000MHz hmmm I might have an older motherboard in the garage, funny I'm going to rip apart a 2000MHZ machine just to downgrade it to 400MHZ to try and fix this shutdown/reboot problem, LOL

Heaven forbid that I should cause anyone to rip apart a working 2000 MHz machine to downgrade. If you lived closer I could send you a test machine in that class, (or maybe three, I need to count.)

It's almost reached the point around here where leaving my car unlocked is an invitation for someone to gift me with a Pentium II. (And, I'm careful when I open the house door, there may be foundlings on the step.) Check a thrift store. I have a 450 MHz system still displaying a $4.95 price tag and passed up a chance at another a few days ago.

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