(old)Puppy Linux Discussion Forum

diaeresis wrote:One thing I so so miss is a unified print dialogue.
It doesn't matter what application you use in windows you get the same print dialogue and the same result.

Windows provides the print dialog as a builtin function: PrintDlg() in COMDLG32.DLL ("Common Dialog Box Library", as MSDN calls it).
POSIX systems cannot do the same, for the simple reason of not having One True GUI Toolkit or One True Printing Subsystem.
So everyone uses whatever print functionality one can implement at a "good enough" level - either toolkit-provided if it exists (say, GTK+ didn't have it before version 2.10), or custom-built.

IOW, this is a fact of life.

mtpaint needs to be set up with the right command before it will print and gives you no set up dialogue just starts printing. <...>
Today I downloaded gtklp.
Oh My God.
Could that possibly be set as a unified print dialogue that each and every application calls up when the print command is issued?

mtPaint doesn't have a printing dialog of its own precisely because using gtklp as a print command makes more sense than building a poor replica of it into mtPaint.

And that is why gtklp should be built in to puppy and mtpaint set to use it "out of the box" rather than have new users with little or no familiarity with the "Linux Way" struggle to get a decent print.

And as many other apps as possible, thereby providing "a unified print dialogue"
It's not a problem, it's a solution.

if the computer is shutdown improperly, do we still need to run the xwin again in this new release. its getting sicker everytime it happens.

Well, those of you who've been around awhile know that I felt that Puppy 4.2 was itself one big bug, and was Puppy's "Vista" moment (and indeed, it even looked like Vista, and was slow like Vista!)........and frankly, I have been leery of everything since, and using 4.1.2 exclusively. However, I stumbled across the information about Barry coming out of retirement to oversee 4.3, and a few days ago I thought, well, if Barry made it, it's got to be good.

I hafta say, I just fired it up a few minutes ago, (4.3.1) and....I'm very pleased. It has a pleasing look out-of-the-box, but isn't encumbered by widgets and sidebars and such that, try as I might, I never could get to really go away. Also, 4.3 seems to be light, which is key for usability for my purposes, as I use it primarily to refit sub-500mhz computers for the Internet Age. I'm not very comfortable with Flash 10 yet, but perhaps it will be OK.

One thing that I like is that Pnethood works again in 4.3 (it never worked for me in 4.2) and things seem to be all wonderfulness.

I did notice one minor bug: in CPU frequency scaling, the button that should say "QUIT" actually says "OUIT".....oqps

enhu wrote:if the computer is shutdown improperly, do we still need to run the xwin again in this new release. its getting sicker everytime it happens.

That's why I wrote this. (Click here)

Soon I'll be updating the top post to include a version I'll be making this afternoon for 4.3.1 (If you beat me to it, just insert my code into your files in the requisite places. See files for details.)

Hi everybody,

can you help me with hotkeys that in 4.3.1 don't work properly? When I want to set brightness, in example, I have to exit from Xorg, losting all applications running, and press on light keys to chance. In 4.2.1, this behavior was not.
Please note: in these days, I have tried only with my Acer Extensa 5620z, but not yet on my Eeepc (already seen ASUS Eee ACPI support topic by Tempestuous for 4.3.0).

Thanks, bye.

Bear with me

Desktop of 431 has a row of partition/drive icons at the bottom (unless you turn this off).

If I do this:

Right click on an icon
select any partition
and select the line App dir
select properties
-
it is always showing the size of 20K

I think this is suppose to be the partition size, but maybe not?

scsijon

The space occupied by the icon.

Hi,
only on my medion 600MHz PIII laptop 192MBRam!
after frugal installation using Puppy Universal Installer, got error «..not syncing: attempted to kill init»

No problem booting from live-cd.
No problem with the frugal instal of the «full» pup-431 instead.

problem is: only about 8MB of the 93MB sized pup-431.iso is copied on the ext3 partition /puppy431 folder upon frugal installation.
This happens only with pup-small-431 on my medion 600MHz PIII laptop - not on desktops.

Trying to copy the pup-431.sfs from live-cd to /puppy431 resulted in an «input/output error».

Then extracting pup-431.sfs from the iso and copying it to a USB stick, and afterwards from stick to /puppy431 worked.

Now pup-431-small boots OK.

Cheers, Charlie

tempestuous, et al,
Reports of unreliable handling of module preferences, as given in the BootManager Preference option, probably resulted from a bug in the pup_event_backend_modprobe script, which is responsible for the loading of appropriate hardware driver modules. The attached package, pup_event_backend_modprobe_fix_to_p43x-1.pet, resolves that bug and extends the capabilities of the Preference function to (1) provide predictable control over module preferences and (2) support some special cases of module selection and substitution.

The current implementation of preferences not only can fail to make a substitution, but may load a module other than the one specified, if more than one alternative is appropriate. Specifying the name of a module as a substitute merely results in substitution with whatever module is available for the device; if there are multiple candidates available, the one loaded may not be the one named as the preference.

This new version of the script extends the preference function by (1) allowing multiple preferences for the same module (separated by a "|" and ordered first-choice-first if needed), the selection being governed by the particular modules that identify themselves as supporting a particular device, and (2) allowing dynamic activation of a set of preferences needed when certain conditions occur. The special preferences reside in /etc/rc.d/MODULESCONFIG as assignment statements setting variables named PREF...; they are not accessible through the BootManager.

One use of these extensions is for hybrid USB storage-modem devices (e.g., wireless modems), which require two drivers but only one of them normally gets loaded. All such devices may initially require module usb-storage, then need one of several possible modem drivers. If the normally-loaded driver is usb-storage instead of the others, an internally activated preference is used if usb-storage is already loaded (which it normally is), but the modem driver must be the one(s) intended for the modem (known at load time).

Another use is for supporting ALSA modems that might instead actually be Conexant modems. The Conexant (Linuxant) driver issues an error message if the modem is not a Conexant. In this case, preferences can be activated to force use of the alternate (ALSA) driver after a reboot of Puppy. The new features could support other special module-loading situations as they become known.

This package/dotpet has been tested with all three kernel versions of Puppy 4.3.1. It should be installed by anyone experiencing a problem with preferred modules not loading (e.g., atl1e instead of atl1c). Do not use this package on Puppies 4.1.x or 4.2.x; instead, use the similar, but bugfix-only package created for those Puppies and available in the Bugs/Fixes threads for 4.1.2 and 4.2.1. Use of the HSF/ALSA reselection requires installation of the new modem "fix pack" package (to be uploaded soon in this thread). This fix can be applied to any Puppy 4.3 installation and is a candidate for inclusion in 4.4CE.
Richard

There is one "bug" tha is on 4,3,1 and other puppies..
In the beggining of the setup,where we choose the keyboard layout there is:

Brazilian,Portugal
Brazilian,Brazil

and the correct is:

Portuguese,Portugal (PT-PT)
Portuguese,Brazil (PT-BR)

Recently I did a frugal install of Puppy 4.3.1 onto a 10 year-old PC with 192 mb RAM and 2 small HDDS. As i'm new to Linux and Puppy (but really loving it !!! ) i had no idea whether to go for an ext2 or ext3 partition. I literally flipped a coin and for that reason formatted the smaller HDD as ext2.

So I've got the following -
2 gb HDD ext2 Puppy 4.3.1 (frugal)
40 gb HDD FAT 32 Windows XP

What I've found is that while Gparted can see the Windows XP drive, it lists the FAT 32 partition on that drive as "unformatted".

I ran an older version, Puppy 4.0.0, from a DVD and it's version of without any probs at all.

So I've chucked out Puppy 4.3.1 and installed the older version on the PC. I just didn't like the risk of having a powerful tool like GParted not working properly.

Hi all,

I found this rather strange. I have a pupsave on my flash drive and an identical pupsave on my HDD.

The machine is an older 750 Duron, 512MB RAM.

So I CD boot, load the HDD pupsave, and check memory usage:
used: 293580, free: 220900

I reboot, and instead load the identical pupsave from my flash drive:
used: 111332, free: 403148

Both of these were fresh boots (before running anything else, so nothing is dangling in memory).

It almost appears that booting from HDD (including the frugal install), copies all of the user and system files to memory when running from a HDD, but doesn't do this when booting from flash. I confirmed this on a couple different machines. The pup-431.sfs file is on the HDD with the pupsave (and likewise the flash).

This difference in memory usage is critical, since being a RetroTech Guy, I'm putting puppy on old, dilapidated machines... (my "toaster", with 256MB, was having trouble -- very, very sluggish...)

Any ideas? Did I miss a configuration somewhere?

Thanks!

A few days ago I persuaded a friend to try Puppy 4.3.1 on his newly configured Windows 7 system. The Live-Cd ran fine, and we had no problems configuring his display, sound, and ethernet connection. We then saved both the Puppy4.3.1.sfs file and a 512MB 2fs file to his D drive, formated ntfs.

There were no error messages, but when we rebooted the system locked up completely witha kernel panic message. He had to power down the system with the power switch in order to regain control.

Unfortunately, all of his drives were formatted ntfs, and we couldn't find a usb drive large enough to retry with fat or fat32.

The system ran Slax and TinyCore without and signs of problems. Although we didn't try to create any permanent configuration files with those distros.

Knoppix Live-DVD 6.2 ran fine the first time, but locked up the second time we booted it. No idea why.

I understand that Linux doesn't handle NTFS partions very reliably, but I didn't think it was that bad...

I've got a large ntfs partition on one of my drives, and I can't use it with Puppy, because whenever I mount it, I get a big red "ntfs warning" popup (which is hard to read and impossible to copy and paste), after which my empty partition opens up in Rox in read-only mode.

[quote="otropogo"]There were no error messages, but when we rebooted the system locked up completely witha kernel panic message. He had to power down the system with the power switch in order to regain control.
I understand that Linux doesn't handle NTFS partions very reliably, but I didn't think it was that bad...

I had the same experience, and the only thing I could do was to create an extra Linux partition and save the 2fs file onto that, if not I repeatedly had the same kernel panic message...

@RetroTechGuy: Puppy normally has a pup_xxx.sfs file that contains nearly the entire default operating system (minus the kernel and the initial ram disk, but don't worry about those). Puppy will typically load that file into ram if it can, so that access time will be faster. But there are drawbacks to doing that: it uses more ram and it takes longer to boot. If you have the file on an internal harddrive, the slowdown to booting is pretty small. On a flash drive it might be pretty significant, especially if it's an old USB v1 drive or port (USB v2 is much faster). So when it boots, Puppy tries to determine if the pup_xxx.sfs file is on a "slow" drive or not. If it is, Puppy won't load it. (Puppy also looks at the amount of free ram as a second criterion before it will attempt to load the file. The precise amount it checks for varies from release to release. I think it's currently something like 256 MB, but I could be wrong.)

There are boot options (pfix=noram and pfix=copy) that are supposed to tell Puppy to not copy or too copy the file regardless of the drive speed (but still at the mercy of available ram). However, only the pfix=copy option actually works in the latest Puppies. For some reason, Barry saw fit to have Puppy override the user's preference regarding pfix=noram. I believe I posted some code a couple months ago that lets you restore your right to choose. I don't remember where I posted it though. I can dig it up for you if you need it.

Note that your comment about HDD installs is not quite accurate: With a full-hdd install, there is no pup_xxx.sfs file for Puppy to load at all, since the data that would be in it is strewn across a harddrive partition instead. So in that case the ram isn't used much either.

Hi Pizza,

Thanks for the input.

What I'm seeing is opposite of what I would expect (i.e. a CD boot reading from a flash drive uses LESS memory than CD boot reading pupsave and .sfs from HDD). Given wear leveling concerns, I might expect the flash drive to load everything memory, and for the HDD to not load, leaving a large amount of free RAM with the HDD option (as wear leveling would not encourage loading everything to memory). Likewise with the USB1.1 versus HDD speed -- I would expect Puppy to read the sfs file from the HDD, and the flash to load into memory. I seem to be getting the opposite behavior.

BTW, my 2 install methods are CD boot and frugal install (I have grub on one of my machines, and plan to put it on the other). I didn't want a full HDD install (it makes my dual, Tri, or whatever, boot options very easy -- likewise playing with multiple Puppy versions). So I do have .sfs and pupsave files sitting on my HDDs (I still run Win98 on several machines)

My real problem was with my "toaster", which only has 256MB, and a tower with 384 MB. Perhaps the problem is that all of my machines have an available and enabled swap partition (making Puppy believe that it has more actual RAM than it does). BTW, the "toaster" only has USB 1.1 (and being a "toaster", it cannot be upgraded), but the 384MB machine has a 2.0 card inside -- however the HDD should be faster to read than the USB 1.1, so it still doesn't make sense... (and for completeness, the Duron mentioned earlier has 512MB and USB1.1)

The 111M memory usage from a CD/flash boot would probably be fine, but when it heads towards the 290M level, my machines spend a lot of time swapping, which really dogs them down (so to speak...

I think that I had no problem with Puppy 4.21 on an old laptop (P333, 128MB, using a CD boot with the files on the HDD).

Since the RAM values I gave were for a fresh boot...as soon as I open Firefox, or whatnot, I find that my free RAM drops to 5MB or so, and then pageswaps completely dominate my CPU availability... You end up with several seconds of pause after clicking a button...

If you could recall the name of your pfix code, I can probably search for it. I'll give the pfix option a try and see if that clears it up...

Thanks!

It appears that Puppy 4.31 is ignoring pfix=noram, so that didn't help.

I deleted the swap partition on the 512MB Duron, to no effect (though that machine still has lots of RAM). I'll try that on the toaster, and see if that drives the memory usage one way or another.

I'll try tinkering with the grub commands for the 384MB machine, and see if I can force a noram bootup...

I'll try to post an update tomorrow.

Found it: http://www.murga-linux.com/puppy/viewto ... 197#267197

It doesn't make a difference one way or the other regarding flash lifetime. Flash is worn out from writes, not reads.

Puppy does take measures to extend the life by limiting writes. What happens is it creates a ramdisk and any time you modify data, the modifications are held in the ramdisk instead of being written to the drive. Periodically and upon poweroff Puppy will copy the changes back to the drive. The frequency of the copies can be controlled from "Menu->System->Puppy Event Manager".

IIRC Puppy uses the default ramdisk size of half your ram. But since it uses tmpfs, it doesn't actually use up the ram immediately. It's allocated as needed. So initially it doesn't even impact the free ram.

This stuff only applies to flash media of course. Otherwise Puppy doesn't bother with it.

Thanks Pizza, I'll give that a try on my frugal install (the toaster is still being boot from a CD at the moment -- but the initrd.gz is easily available on the frugal).

Regarding flash drives -- yes, that was my understanding as well, that only writes do damage (though I notice that reading from a flash drive often produces considerable heat -- that makes me wonder if some damage also occurs during read operations).

Anyway, I was mistaken about this frugal install machine, I thought it had 384M, but I apparently used a 64M with the 2 128M, so I have 320M. It still ought to be plenty, but here is the problem (I pulled this as soon as I booted):

Mem: 286964 282380 4584 0 22700
Swap: 546200 0 546200
Total: 833164 282380 550784

That 5 M left really cramps my style.

BTW, the boot sequence does state that it loaded pup-431.sfs to ram (rather than just read from the HDD).

I'm going to try your patch, and will let you know in a bit...